A daily work queue for a relationship practice: who needs attention today, and why
A relationship practice sells a high-touch service to a small circle of clients, so attrition is the number that matters. Every household that drifts away takes years of trust with it, and the practice usually finds out afterwards. A founding team wanted a short list each morning: who needs attention today, why, and what to do next. NoArt Systems wrote the PR/FAQ, the requirements and the design, then built the system to them: a rules-first decision engine with its evidence attached, a multi-tenant platform whose guarantees are tested, and AI held to the record.
The pattern holds wherever one person owns many relationships and the system of record already knows who is slipping. The list is only worth having if every item on it can be explained, and the practitioner stays in control of every contact.
Generalized from one product build. The venture, its product name, its vendors and every figure are removed.
Situation
The list that was never written down.
A relationship practice earns its keep on attention: who was called, who was not, which follow-up slipped. It cannot grow its way out of attrition, because it sells to a few hundred households rather than to a market, and the households that leave are the ones that were quietly under-served. One practitioner looks after a hundred or more clients, with little support, and decides whom to contact from memory, intuition and a last-contacted column in the CRM.
The founding team's thesis was plain. The relationship context already sits in the CRM, in notes, dates, open tasks and family links, and nobody reads it in time. A tool that read it every day, applied the judgement an experienced practitioner would apply, and returned a short ranked list with reasons would change the morning, and the retention numbers with it. The PR/FAQ also named the risk: a list the practitioner does not trust goes unread, and then so does the tool.
That set the question the work had to answer first: can a system produce recommendations the practitioner trusts enough to act on as part of the daily routine? Everything else, from how the score is built to what the AI is allowed to say, follows from that one question.
The requirements state two constraints as tenets. The practice is regulated, so every message to a client stays in the practitioner's hands, and the tool must never send anything itself. And the CRM stays the system of record: the tool reads it, and writes back only what the practitioner has approved. The tests hold the code to both lines.
Approach
Define the product before the system, decide with rules before models, and keep the AI on a short leash.
The work rests on a PR/FAQ, not a backlog: the press release for the pilot, and the answers to the questions a skeptical practitioner, a compliance officer and a buyer would ask. It says what the product is, who it is for and what it is not. The requirements answer to that definition, and the design and the tests answer to the requirements.
The decision engine is rules first, and the rules come in three layers. The industry sets the first: a review that must happen on schedule, a contact that must not lapse. The firm sets the second: which rules run, with what urgency and what weight. The practitioner sets the third: their own weights, tuned by what they act on and what they dismiss. Every rule fires on evidence in the record: a contact overdue for the client's expected cadence, a task past due, a review or a birthday approaching, a life event mentioned in notes, activity in the family without a follow-up. Every recommendation carries that evidence. A weighted priority score orders what fires, and relationship risk is one of its factors, so a household drifting toward the exit rises before it is gone. A learned ranking model was deliberately not used: a practitioner can read a rule and an evidence list, and a compliance reviewer can audit one.
Before it recommends anything, the engine scores each client's record on the fields present, and the score sets a tier. A thin record limits which rules may fire and discounts the confidence of whatever does; only a record too thin to score at all drops out. A record that scores at all still surfaces a client who has had no contact in a long time.
Fixed-order checks remove noise before the list appears: already handled, duplicate, too little confidence, stale evidence, dismissed too often, no evidence behind it, contacted too recently. A recommendation resting on AI inference alone cannot rise above a priority cap. One resting on stale evidence cannot claim high confidence. The practitioner's decisions reach the next list directly. The rule weights, by contrast, learn slowly on purpose: only after enough decisions, by bounded steps, within a floor and a ceiling, so the list does not lurch after one bad week.
The AI is a preparation aid, not the product. A synopsis before a call may use only the evidence in the record of that one practice. The validator removes, rather than flags, any sentence it cannot trace to a source. What the record says and what the model inferred sit in separately labelled sections. Drafting of outreach is off by default, behind a review step, and routed to compliance when the content is sensitive. There is no code path that sends anything to a client.
The platform treats isolation and auditability as properties to be tested, not conventions to be remembered; § 06 lists what it guarantees, and a test pins each statement or the database itself enforces it. The infrastructure is code, and the pipeline runs lint, an architecture check, a security scan, tests, build and deployment on every merge.
From record to ranked list
Eight steps, each with the rule that keeps the list trustworthy, and the learning loop that runs across them.
-
Source record
The practice's CRM, read on a schedule or loaded from a structured file. The CRM stays the system of record; raw copies are a short-lived working cache.
-
Readiness
The engine scores each client's record on what it contains. The score sets a tier that limits which rules may fire and discounts confidence; only a record too thin to score at all drops out.
-
Rules and evidence
Rules in three layers fire on evidence in the record: what the industry requires, what the firm decides, and what each practitioner has learned to do. Every trigger carries its evidence, with source and date.
-
Priority score
Weighted factors (urgency, importance, actionability, confidence, freshness and more), bounded, with a missing factor counting as nothing rather than re-weighted.
-
Noise gates
Fixed-order checks remove what is handled, duplicated, under-evidenced, stale, over-dismissed or too recent. Items from inference alone, or on stale evidence, meet a cap, never a boost.
-
Ranked list
A short queue for the day: client, reason, evidence, confidence and a suggested next step. The item shows every factor behind its order.
-
Practitioner action
Act, prepare, snooze, dismiss, mark handled or mark wrong. The record of every action names who took it, and a dismissal also records why; preparing never counts as acting.
-
Write-back and learning
Approved notes, tasks and activities return to the CRM at most once. Decisions feed the next list directly; rule weights move slowly, within bounds.
The tool records each decision → the same client and trigger are suppressed or re-ranked for the next list → a rule's weight moves only after enough decisions, by bounded steps → the next morning's list reflects both.
Figure W3. The one loop the first version delivers, and nothing outside it. Generalized from the product's design.
Terms used on this page
- Practice
- One firm or team using the tool. The database itself keeps its data apart from every other practice's, not only application code.
- Practitioner
- The person who owns a set of client relationships and decides on every contact; the tool prepares, the practitioner acts.
- Record
- The practice's CRM: clients, households, notes, activities, tasks and key dates. The tool reads it and writes back only approved items.
- Household
- A group of related clients handled as one relationship; activity in one member without a follow-up with another is itself a signal.
- Readiness tier
- A band of a client's readiness score. It decides which rules may fire for that client and how much to discount their confidence; it limits and discounts rather than excludes, except for a record too thin to score at all.
- Rule
- One condition, set by the industry, the firm or the practitioner, that turns evidence in the record into a candidate recommendation with an urgency and a confidence.
- Evidence
- The specific records a recommendation rests on. Each line names its source and its date and carries a verification status the practitioner can set; a recommendation with none is removed.
- Priority score
- The weighted, bounded number that orders the list; its factors are shown with every item, and a missing factor counts as nothing.
- Noise gate
- One of the checks, run in a fixed order, that remove or cap a candidate before it is shown.
- Write-back
- A note, task or activity returned to the CRM after the practitioner approves it, attempted at most once and reconciled afterwards.
Where this sits in the scope of practice
The work mapped to the services it drew on.
-
05
Architecture, Requirements & Technical Due Diligence
A PR/FAQ held above design: what the product claims, for whom, and what it is not, with the hard questions answered up front. Requirements that answer to it, numbered and testable, and a design and tests that answer to the requirements. Then a multi-tenant platform that states its guarantees and tests them. A repeated request has one effect. Lifecycle state machines are explicit, and decision records cover the persistence choice and the compliance posture. Infrastructure as code, and a pipeline that lints, checks the architecture, scans, tests, builds and deploys.
-
04
Data Products & Decision Systems
The core of the work: a decision engine that scores each record's readiness, fires rules on evidence, orders what fires with a weighted and bounded score, removes noise in a fixed order, and learns from the practitioner's decisions slowly on purpose. A reviewer can explain every recommendation from its rule and its evidence, and audit it.
-
03
AI Evaluation, Guardrails & Governance
A deliberate decision to put rules first and keep the model as a preparation aid. Every generated sentence must trace to evidence, or the validator removes it. The output labels what the record says apart from what the model inferred. A cap holds down output from inference alone. Drafting is off by default and routed to review. No path sends anything to a client.
Deliverables
What NoArt Systems handed over.
- D1 PR/FAQ The press release for the pilot and the answers to the questions a skeptical practitioner, a compliance officer and a buyer would ask; the people it serves, the non-goals and the product tenets.
- D2 Requirements Numbered, testable requirements that answer to the PR/FAQ; the scope of the first version and what it excludes; the open questions; a definition of done.
- D3 Technical design and decision records Architecture, data model, lifecycle state machines, API standards, and the correctness properties the implementation must uphold; decision records for the single system-of-record database and for the compliance posture.
- D4 Decision engine Readiness scoring with tiers, the rules library, the priority score, the noise gates and caps, and the conservative feedback loop; pinned by golden tests and unit tests.
- D5 Working platform Multi-tenant API and worker; a connector port with one CRM implementation and a structured-file import as fallback; a review workspace with evidence and factor breakdown; actions with a lifecycle; write-back with preview, at-most-once delivery and reconciliation; pipeline, sync-health, compliance review and export, digest and pilot analytics.
- D6 AI guardrails Pre-generation checks, evidence grounding with claim removal, labelled verified and inferred sections, compliance classification, personal-data minimisation, prompt-injection sanitising, a prompt registry and per-user rate limits; drafting shipped dark behind a flag.
- D7 Infrastructure, pipeline and tests Cloud infrastructure as code, one stack per concern; a pipeline of lint, architecture check, security scan, tests, build and a rolling deployment with automatic rollback; unit and integration suites with a traceability matrix back to the requirements.
What the structure guarantees
One recommendation, opened: the evidence, the score, the gates it passed, and what the practitioner's action changes.
A review is approaching, the last contact is past this client's usual interval, and a recent note mentions a change of job.
- Key datesA review scheduled within the coming windowunverified
- Contact logLast contact past the expected intervalunverified
- NoteA recent note mentions a new jobunverified
Strong tier: every rule may fire; no discount on confidence.
Bars show relative contribution; the number itself is not shown here.
- Already handled
- Duplicate
- Low confidence
- Stale evidence
- Dismissed too often
- No evidence
- Recent contact
Caps checked first: inference-only, not applied; stale evidence, not applied.
- Act
- Snooze
- Dismiss
- Already handled
- Mark incorrect
Once prepared: mark contacted.
The next list re-ranks or suppresses this client and trigger; the rule's weight moves only after enough decisions.
Step 1 of 6: Everything the practitioner sees
Illustration. One recommendation as the practitioner sees it, with a walk-through of where each part comes from. The household and its records are invented for the page; the trigger, the order of the bars, the gate outcomes and the actions are what the product's own engine produced for them, with every number removed.
All six steps as text
- The whole card
Everything the practitioner sees
One item from the morning list, opened: the reason, the evidence, the score, the gates it passed and the actions. Nothing on it is unexplained.
Step through to see how each part is produced and what keeps it honest.
- Why now
Three rules fired on one record
A review approaching, a contact gap and a life event in a note each fired as a rule; the most urgent sets the reason, and all three carry their evidence.
Every line of evidence starts unverified; the practitioner can confirm a line or mark it wrong, and a line marked wrong drops out of the confidence. A recommendation with no evidence behind it never reaches the list; the pipeline removes it rather than showing it low.
- What the record allows
Readiness decides which rules may fire
This record is complete enough for every rule, and for no discount on confidence.
A thinner record would have limited the rules to the basic pair and discounted the confidence of whatever fired. A thin record is not hidden: as long as it can be scored at all, a long silence surfaces from the last-contact date alone, even while the other rules stay withheld.
- How it was ordered
Weighted factors, bounded
The widest bars moved this item up the list; the score itself stays within fixed bounds whatever the inputs.
A missing factor counts as nothing, and the rest keep their weights, so a sparse record cannot inflate a score. The item shows every factor, so the practitioner can see what moved it.
- What it had to pass
Every gate, in a fixed order
A duplicate, a stale item or one dismissed too often would have dropped out here rather than shown low.
Two caps run first: an item resting on AI inference alone cannot score above the middle of the range, and one resting on stale evidence cannot claim high confidence. The order is fixed and tested, so the same input always meets the same gate first.
- What the action changes
One decision, two speeds of learning
A tap records the decision and who made it; the next list reflects it directly.
The rule’s weight learns from it only later: after enough decisions, by bounded steps, within a floor and a ceiling. Preparing a draft or a synopsis never counts as having acted; only a confirmed contact does.
The structure states what it guarantees, and a test pins each statement or the database itself enforces it. No request from one practice can reach another's data, by any path. The score stays within its bounds whatever the inputs. The gates run in a fixed order, and an item they remove never appears. The lifecycle accepts only the transitions it allows, and generating a synopsis or a draft never counts as having acted. The tool attempts a confirmed write-back at most once, then reconciles its state with the CRM's. Every sentence the AI produces traces to evidence, or the validator removes it. Weights move only after enough decisions and within bounds. The audit trail accepts additions only. There is no path that sends a message to a client.
What the structure cannot show is the answer to the work's own validation question: whether practitioners act on the list day after day. A pilot would measure that against a baseline taken first, and this page makes no claim about it.
Tell us what you are building — or what you are trying to figure out.
In your note, include the initiative, the decision point, the timeline, and whether you need advisory, architecture review, a hands-on build, vendor oversight, or roadmap support. We respond directly.