Institutional intelligence
Turn operational decisions into institutional intelligence.
Most organisations automate the work and lose the reasoning. Nexus records the data, the rule result, the model proposal, the human decision and the outcome as one structured record, so the judgment your people apply becomes an asset the organisation owns rather than knowledge that leaves with them.
Every run produces the same shape of evidence
Because the decision happens inside the execution, the reasoning and the action belong to the same record. That is what makes the data usable later.
- per execution, end to end
- One recordper execution, end to end
- decisions and reason codes
- Structureddecisions and reason codes
- improvement, not silent retraining
- Governedimprovement, not silent retraining
- across cases and periods
- Queryableacross cases and periods
The problem
Automation that keeps no reasoning cannot be improved, only replaced.
When a process runs across a ticketing tool, three inboxes and a spreadsheet, the decisions are real but the record is not. Nobody can answer why an exception was approved in March, and nobody can measure whether the rule written in April helped.
What normally survives
- A final status field on a record
- An email thread nobody can find
- A ticket comment with no structure
- The memory of the person who decided
What Nexus retains
- The exact inputs the decision was made against
- Which deterministic checks passed and failed
- What the self-hosted model proposed, and its confidence
- The decision, the role, the reason and the resulting action
The decision record
Six things captured on every reviewed case.
Institutional intelligence is not a dashboard. It is the discipline of storing the six things that let somebody reconstruct a decision without asking the person who made it.
The inputs the decision was made against
Values retrieved from each system at the moment of execution, not a later re-read that may have changed.
Deterministic rule results
Which policy checks passed, which failed and the threshold each one used, so the reasoning is reconstructable.
The model proposal and its confidence
Where a self-hosted model classified, extracted or summarised, the proposal is stored as a proposal, separate from the decision.
The human decision
Approve, correct, reject, escalate or request more data, with the identity and role of the person who made it.
The reason
Structured reason capture is what turns a click into evidence a reviewer can defend eighteen months later.
The resulting action and its outcome
What was written back to which system, whether it succeeded, and any downstream correction that followed.
Decision review, credit exposure workflow
Illustrative view of captured decisions across one case type
- EXC-4821Model proposal acceptedApproved
- EXC-4822Extracted limit corrected by reviewerCorrected
- EXC-4823Outside reviewer mandateEscalated
- EXC-4824Arrears threshold breachedRejected by rule
- EXC-4825Supporting document missingReturned for rework
Illustrative interface, not a customer deployment. Values are examples used to show the shape of the captured record.
The learning loop
Automate the known. Apply AI to the ambiguous. Keep people in control.
The loop below is the operating model, not an aspiration. Each stage is a real step in the execution, and the last stage is a human activity supported by data rather than an automatic behaviour of the system.
- 01
Event
A trigger arrives from one of the supported trigger sources: file, webhook, schedule, queue or system event.
- 02
Deterministic rules
Policy checks, thresholds and validation run first. Clear cases resolve without a model and without a person.
- 03
AI recommendation
A self-hosted model classifies, extracts or summarises what rules cannot read. Output is a proposal.
- 04
Policy and confidence check
Routing logic decides whether the proposal may proceed automatically or requires review, based on policy and confidence thresholds you set.
- 05
Human review where required
The reviewer sees assembled data, rule results and the proposal in one place, inside the paused execution.
- 06
Approve, reject or correct
The decision is structured, attributed and reasoned. A correction replaces the proposal as the value the workflow uses.
- 07
Operational action
The authorised action is written back to the systems of record and confirmed.
- 08
Capture and improve
The decision and outcome are captured, reviewed as a set, and used to author governed changes to rules, prompts, retrieval, evaluation and policy.
The loop repeats. Improvements to prompts, retrieval, evaluation, policy and thresholds are authored, tested and published by people who own the process.
Signals
What the captured decisions actually tell you.
Raw decision logs are not intelligence. These six patterns are the ones that reliably point at a specific, fixable cause.
Signal 01
Repeated correction of the same field
When reviewers keep fixing the same extracted value, the extraction prompt, the source document handling or the retrieval scope is wrong. The correction rate for that field is the measurement.
Signal 02
Escalations clustered on one case type
A case type that always escalates is usually missing a rule, not missing a reviewer. The escalation reason codes tell you which rule to write.
Signal 03
High-confidence proposals that get rejected
Confidence that does not predict acceptance means the threshold is set on the wrong signal. That is a policy change, made deliberately.
Signal 04
Approvals with no discretion
A review step where every case is approved unchanged is a candidate for a deterministic rule, subject to an explicit human decision to change the control.
Signal 05
Downstream corrections after write-back
Actions that get reversed later point at a validation gap earlier in the run, before the write-back rather than after it.
Signal 06
Time spent waiting, by stage
Execution records show where runs wait. Queue time attributable to one role or one system is an operational finding, not a guess.
Governed improvement
Changes are authored, tested and published by people.
Improvement in Nexus is a change-controlled activity. The system supplies the evidence; your teams decide what to change and take responsibility for publishing it.
- Stage 01
Review
Look at decisions as a set, not as tickets
Captured decisions are queryable. Process owners examine correction rates, escalation reasons and rejection patterns across a period rather than reacting to individual complaints.
- Stage 02
Author
Change the thing that was actually wrong
The change might be a threshold, a rule, a prompt, a retrieval source, an evaluation set, a routing policy or the reviewer interface. Each is edited in a draft revision of the workflow.
- Stage 03
Test
Run the change against recorded cases
Recorded inputs and decisions provide the material to check whether a change would have produced better outcomes before it is published.
- Stage 04
Publish
Promote through the same governance as any change
Publishing a revision is a governed action with an approver, a timestamp and a record. Rollback is a published revision as well, not a manual repair.
- Stage 05
Observe
Watch the same measures after the change
The measures that identified the problem are the measures that confirm the fix. If correction rate does not move, the change addressed the wrong cause.
What can be changed
Deterministic rules and thresholds, routing and escalation policy, prompts and system instructions, retrieval scope and knowledge sources, evaluation sets used to check a change, reviewer interface fields, and where your governance permits it, approved fine-tuning of a self-hosted model.
Who is allowed to change it
Authoring, approving and publishing are separate permissions under role-based access control, so the person who proposes a threshold change is not necessarily the person who puts it into production.
How a change is tied back to evidence
Published revisions are recorded with the identity of the approver and the time they went live, so any decision can be read alongside the exact configuration that was active when it was made.
Knowledge and retrieval
Reviewed decisions become retrievable context, under your control.
Captured decisions and the documents behind them can be curated into knowledge bases that self-hosted models retrieve from, so the organisation's own precedent informs the next proposal instead of a general model's assumptions.
Curated, not automatic
Content enters a knowledge base because somebody with the right role put it there. Nothing is absorbed silently because it appeared in a run.
Scoped to the workflow
Retrieval scope is configured per workflow and per model endpoint, so a process only sees the sources it is entitled to see.
Inside your boundary
Knowledge bases, embeddings and model endpoints run in the environment you control, including networks with no external connectivity.
Measurement
The evidence that makes this auditable.
The same records that support improvement support assurance. An auditor asking why a case was approved and a process owner asking why correction rates rose are reading the same data.
Execution record
One record covering trigger, retrieved data, rule results, model output, decision and write-back.
Decision dataset
Structured decisions with reason codes, reviewer role and timestamps, queryable across cases.
Change history
Which revision was live when a decision was made, and who published it.
Improvement trail
The link between an observed pattern, the change authored in response, and the measured effect.
Operation
Operating responsibilities.
Teams use recorded cases to evaluate proposed changes, then approve each revision before production use.
What the platform does
- Captures inputs, rule results, model proposals, decisions, reasons and outcomes as structured data
- Makes those records queryable across cases, periods, roles and case types
- Provides recorded cases as test material for a proposed change
- Records which workflow revision was live for any given decision
- Keeps every record inside the environment you control
Responsibilities retained by your teams
- Model training and retraining remain deliberately managed by model owners
- Model evaluation and acceptance criteria are defined per workload
- Rule changes require an accountable owner and approval
- Process owners retain the review steps required by policy
- Dedicated case management tools retain their system-of-record role
Improvement is a human activity with system support
Nexus records inputs, decisions and outcomes so your teams can identify changes, test them against recorded cases and publish each revision under the same governance as any other production change.
Architecture session
Bring a process where the reasoning keeps getting lost.
Pick one review-heavy process and we will map what its decision record should contain, which measures would show whether it is improving, and how the improvement would be governed once it is live.