Each system in the close computes its own part of a figure correctly. The reasoning that connects those parts into one defensible position is performed manually every period and retained in no record as complete as the figures themselves.
The same body of work carries two distinct implications: a control exposure for the CFO, and a capacity constraint for finance operations.
The records show which figures moved and which steps ran. What they were never built to hold is the basis on which each judgment was made.
Across all six frictions, the judgment is a fraction of the elapsed work. The rest is retrieval, transcription, and re-applying rules that already exist in writing.
Which component closes which friction. The six frictions are not six separate problems requiring six separate fixes; they share one shape, and the same small set of components covers all of them in different combinations.
Every case writes to the evidence log regardless of the marks above. The log is marked only where it is the component that closes the friction, as with a calculation that has no system of record behind it today.
Basis. These six reflect patterns common to project and contract-driven finance operations of this profile, built from the modules already relevant here, not from a review of this company's own systems or data. Presence, scale, and priority would be confirmed with the finance team during discovery, ahead of any pilot.
Each friction below sits inside a specific module and produces a specific cost, but that cost lands differently depending on where a person sits. What a CFO is exposed to and what finance operations absorbs day to day are related but distinct, and both are worth stating plainly rather than folded into one generic description of inefficiency.
Module: MM · FI-AP
Match quality on payables is one of the more commonly tested controls in an internal or external audit cycle, and inconsistency in how a variance gets judged, one reviewer accepting an amendment as sufficient explanation, another requiring further documentation for a materially similar case, is exactly the kind of control weakness that surfaces in a walkthrough. The exposure is not that invoices go unmatched. It is that the judgment behind a match cannot currently be shown to have been applied the same way twice.
A three-way match that resists a clean data pull, because a receipt was split across two deliveries or a purchase order was amended after the fact, currently takes anywhere from forty five minutes to three hours of a person moving between the purchasing history, the receipt record, and the invoice itself, then forming a judgment about whether the amendment on file actually accounts for the variance in front of them.
Module: FI-GL
A residual break carried forward across a reporting cycle without a documented cause is a direct threat to the reliability of a consolidated position, and it is the specific finding that tends to draw the most attention in an audit committee review, because it raises the question of what else might be sitting unreconciled beneath a number that otherwise looks clean.
Tracing a break across entities means pulling postings and exchange movement from each entity in turn, checking timing differences and intercompany eliminations by hand, and this typically stretches the cycle from two to five days before a residual can be explained with any confidence, longer if the entities involved use different charts of accounts.
Module: SD/PS · FI-AR
Claimed, certified, recognized, and collected are computed on four different timelines by design, and a CFO's real exposure is not the divergence itself, which is expected, but the possibility that revenue recognized on a percentage of completion basis is running ahead of what the client has actually certified, without that gap being tracked, explained, and escalated in time to matter for the period it belongs to.
Reaching one explained position on a single contract means moving through the project system, a client-issued inspection or certification document that usually has to be read by hand, the revenue recognition calculation, and the cash ledger, then applying retention terms specific to that contract before assembling all four into one reconciled figure, a process that runs from half a day to well over two days per contract, every period.
Module: Cross-module
Cross-entity reporting quality degrades in a way that is difficult to notice until it is already material, because no single case is ever urgent on its own; the same counterparty or cost center carrying three different codes across three systems quietly erodes confidence in a rolled-up figure long before anyone flags it as a defect.
Reconciling entity identity by hand, matching a vendor or project code in one system against its equivalent in another, is unglamorous, constant, low-grade work that never shows up as a single costly incident but consumes real capacity across every reporting cycle.
Module: FI-GL · CO
Close timelines slip for reasons that are almost never visible in a post-close review, a cost center waiting on a freight accrual or an inter-project charge that another team simply had not posted yet, and the slippage reads as a process failure when it is really an unmanaged dependency.
Once the dependency is identified, the only available response today is to check back periodically, by memory or by calendar reminder, until the prerequisite posts, an idle wait that adds real hours to the close without adding any value to the number itself.
Module: Off-system
A material calculation that exists only as one analyst's spreadsheet, with no version history and no independent record of the assumptions behind it, is a single point of failure sitting inside numbers the business reports externally, and it is the kind of finding that, once identified, is difficult to defend as anything other than a control gap.
When the person who built that calculation is unavailable, reconstructing it under time pressure at period end falls to whoever is left, working from whatever documentation happens to exist, which is often none.
Basis for this list. These six points reflect patterns common to project and contract-driven finance operations of this kind, built from the modules already relevant to this business, not from a review of this company's own systems or data. Their specific presence, scale, and priority would need to be confirmed directly with the finance team during a discovery phase, ahead of any pilot. One rating sits differently from where a time-based reading would put it: calculations living outside any system of record is rated Severe rather than High, because under the basis stated at the top of this tab it touches numbers reported externally, and no amount of it being quiet permits calling it anything else.
Deferral reads as the cautious option and is priced as free. It is neither. The market's own answer to all six frictions above, one closed vendor runtime per function, is already shipping, and it increasingly arrives bundled inside routine platform upgrades rather than selected through deliberate evaluation. The realistic alternative to deciding this is not the status quo. It is inheriting someone else's decision, unbudgeted, through a maintenance release.
Once the reasoning layer sits inside a vendor's own record, the decision layer is locked to that vendor, not just the data. Migrating later means losing the automated layer along with the transaction history, and that cost lands in a year nobody provisioned for it.
Each function's point solution brings a separate model, a separate access pattern, and its own private interpretation of what counts as valid. No shared definition carries from one to the next, and reconciling them afterwards is a project nobody scoped.
Deterministic audit logging is moving from leading practice toward requirement across several regulatory regimes. Building it in costs less than retrofitting it, and retrofitting it into someone else's closed runtime may not be available at any price.
Each friction above shares one shape: systems that compute their own part correctly, and a person doing the reasoning and assembly work between them, by hand, every time. The architecture below is built to carry that reasoning work without changing where accountability for the final number sits.
Four working parts, operating over the existing system of record, inside one control frame that supplies two things neither the parts nor the record supply on their own: state that persists across a case, and an independent evidence log. Four parts, one record, two properties of the frame. Nothing else.
Holds the objective for a single case, a contract's reconciliation or a cost allocation, from the moment it is raised until a person signs off on the result. A case file held by one owner from end to end, rather than passed hand to hand between four systems and whoever is available.
Brought in where a task falls outside structured data retrieval, reading a certified inspection document being the clearest example. Scoped narrowly to that one task, granted only the access that task requires, and released the moment it reports back.
Holds the business's own definitions, what counts as a valid match, a valid variance, a valid retention calculation under this specific clause, queried live at the moment a case needs them rather than inferred fresh, or recalled from memory, case by case.
Sits between every agent and every system it touches. Checks each request twice, once that it is a defined, pre-approved kind of request, once that this specific agent is permitted to make it here, before anything proceeds. There is no second route.
The architecture reads. It does not post. Nothing here writes to a ledger. Every figure it uses is requested and returned exactly as the source system already computed it, never recalculated in transit. Every action that would change a record, an escalation, an allocation, a payment release, is executed by the existing approved process, by the people who execute it today, after a person has confirmed it.
This is the boundary that makes the rest of the document checkable. What is being proposed is not a new way to post. It is a way to assemble, evidence, and explain the case before someone posts it. Accountability for the final number does not move.
The layer diagram an architect would want for this sits in the Technical Annex. The view below is the same architecture drawn as a segregation-of-duties flow, because that is the form in which its actual claim can be tested: who may originate a figure, who may propose, who may never approve, and where the record of all three is written.
The six points of friction in the previous tab are not six separate problems requiring six separate fixes. They are one shape, reasoning work stranded between systems, and the same four components, drawing on the two properties of the frame, close all six in different combinations depending on what each case actually requires.
The relevant question is not whether automated reasoning can be applied to these six frictions, tooling that claims to do so already exists across the market. The relevant question is whether that reasoning carries a shared definition of what the business means by a valid match or a valid variance, and a governed boundary between reasoning and the record, independently of any single vendor's runtime. Most current approaches leave one or both of those out, which is why the friction gets automated unevenly rather than closed, one closed tool per function, each forming its own interpretation of what counts as valid, none of them reconciled against each other.
A scripted tool executes a fixed sequence exactly as written and holds its reliability only within the boundaries that sequence anticipated. It fails silently the moment a case falls outside that path, which is precisely the class of case, a document that needs reading, a contract clause that needs interpreting, that drives most of the six frictions above.
A copilot puts a person in direct command of a single output, one session at a time, and is built to accelerate a person's own judgment rather than carry a case forward on its own. A coordinating agent is built to hold the objective for a case from invocation to conclusion, retaining what it has already found without needing to be told again.
An agent can propose an action. It cannot approve its own work, or another agent's. That separation is enforced at the control boundary itself, not asserted as a policy, which is the same standard already applied to every other maker-checker control in the business.
Every entry in the evidence log is pinned to the exact inputs an agent used, the exact model version that reasoned over them, and the exact approval that authorized any resulting action. A past conclusion can be reconstructed and checked directly, without re-running the reasoning that produced it and without asking anyone to vouch for it.
None of this depends on unproven infrastructure, and the standards it runs on have names rather than descriptions. Agents reach tools through the Model Context Protocol (MCP), an open standard for connecting a reasoning system to a tool without wiring it directly into that tool's internals, and hand work to one another through Agent2Agent (A2A), its companion standard for delegation between agents. Both are open, both are published, and neither is ours. That matters commercially as much as technically: the interface between this architecture and your estate is not a proprietary asset we hold over you, which is precisely the position a closed vendor runtime puts you in and the reason this document keeps returning to it.
The system of record underneath, whichever ERP or ledger the business runs today, is read from and never written to. That is also what allows the architecture to survive a future change to that system intact: the control boundary, the semantic layer, and the evidence log move with the business, not with any one system beneath them. The Technical Annex sets out the full layer architecture and maps every plain term used in this document to its exact technical equivalent.
Every figure that appears in a completed case can be traced back to where it came from, what rule was applied to it, and who ultimately approved what happened next. This is not a summary claim. It is a specific, structured record, and this section sets out exactly what it contains.
Two distinct kinds of provenance are captured, and both matter for different reasons. Data provenance covers where a figure came from: the source system, the exact query made, the timestamp, and the fact that the figure was returned exactly as the source system computed it rather than recalculated along the way. Rule provenance covers which definition was applied to reach a judgment: which retention clause, which variation or rework treatment, which recognition timing rule, and the version of that definition in force at the moment it was used. A conclusion without both is an assertion. A conclusion with both is a position that can be independently checked, line by line, by someone who was not in the room when it was reached.
The practical test of a lineage claim is not whether it sounds thorough today, it is whether the same case can be reconstructed independently after enough time has passed that nobody involved remembers the specifics. Under this architecture, reopening Contract PC-118's reconciliation from six months prior means querying the log directly for that case, which returns the same six-field record for every figure it used, the exact definition of the rework treatment in force at the time, and the identity of the person who approved the escalation, all without re-running the coordinating agent or asking anyone to reconstruct their reasoning from memory. The log is queried independently of the agents themselves, so verifying a past decision never requires repeating the work that produced it.
The log is queried directly by the business's own systems and people. Reconstructing a past conclusion does not depend on trusting a vendor's word that governance was applied correctly somewhere inside a closed runtime.
An entry is appended at the moment a request, a return, or an approval occurs. Nothing revises a past entry, which is what makes the log usable as evidence rather than as a running commentary that could be adjusted later.
If the underlying reasoning capability is later updated, past entries still show exactly which version reasoned over which inputs, so a later change never retroactively alters what a prior decision is understood to have relied on.
Most audit trails capture what a system did. This captures which definition of valid was in force at the time a judgment was made, which is usually the harder thing to reconstruct after the fact and the more consequential one in a dispute.
Provenance and lineage describe how a conclusion can be checked after the fact. This section addresses a different question: what specifically makes the conclusion itself likely to be correct in the first place, as opposed to merely well documented.
| Design decision | Failure mode it closes | Present in the manual process today |
|---|---|---|
| Figures are requested, never recalculated | Transcription error introduced while moving a number from one system into a spreadsheet or another document | Present. Every manual pull and re-entry is a point where a figure can be copied, rounded, or mistyped incorrectly. |
| Definitions are queried live from one shared source | The same variance judged differently depending on which person, or which precedent they happen to recall, is doing the judging | Present. Retention and variance treatment are currently applied from memory or from whichever prior case a reviewer happens to remember. |
| A specialist is scoped to exactly one task | An error in one part of a case quietly propagating into unrelated parts of the same analysis | Present. One person handling all nine steps in sequence means an early mistake compounds into everything built on top of it. |
| A person confirms before anything is final | An incorrect or outdated conclusion reaching a decision-maker without a check that catches it in time | Partially present. Sign-off happens today, but it happens after all four positions are already assembled, not at each individual step. |
The highest-fidelity part of the manual process today is also, not coincidentally, the part already handled by the source systems themselves: a ledger balance, a posted journal entry, a recognized revenue figure, none of these are usually wrong in isolation. Fidelity is lost in the seams between systems, in the step where a person reads a number off a screen and types it into a spreadsheet, in the step where a retention percentage is applied from memory rather than from the actual clause, in the step where a variance is judged sufficient by one reviewer and insufficient by another for reasons that were never written down. Every one of the four design decisions above targets one of those specific seams, not the systems on either side of it, which is why the architecture increases fidelity without needing to touch, or trust less, any of the source systems already in place.
A boundary worth stating plainly. This does not claim that automated reasoning is infallible, or that judgment calls become mechanical. A specialist reading a document can still misread it, which is exactly why its output is a proposal returned to the coordinating agent, not a final figure, and why the case still ends at a person before anything is acted on. What the four design decisions above remove is the class of error that comes from manual transcription, inconsistent recall of a rule, and undetected propagation, not the possibility of a wrong read on a genuinely ambiguous document.
Note on the figures below. This contract and its figures are a constructed illustration, built from the friction pattern described in the modules above, not this company's own contract data. It is offered as a working example to react to and correct, not a claim about how a specific contract here actually runs.
Recognised $2.74M. Certified $2.58M. Recognition is $160K ahead of what the client has actually certified.
That gap on its own is expected and not, by itself, a finding. Recognition runs on stages completed; certification runs on an inspector's visit. They are not built to agree mid-period. The finding is what sits inside it: $268K of the work already recognised is under rework order RW-07, failed at initial holiday testing, and has not been re-inspected. Recognition is currently carrying work the client has not accepted and may not accept in this period.
This is knowable today. It is knowable by one person, spending most of a day, on one contract, if they get to it before the period closes. The question this example exists to answer is what has to be true for it to be knowable on every contract, every period, without depending on that.
| Position | Amount | Basis |
|---|---|---|
| Claimed | $2.91M | Coated joint count, field production log |
| Certified | $2.58M | Client third-party inspection sign-off |
| Recognized | $2.74M | Percentage of coating stages completed |
| Collected | $2.35M | Cash received, net of retention |
None of the four systems producing these figures is wrong. Each answers a different question on a different timeline, exactly as designed. What follows is the decomposition of both gaps, because a reconciliation that produces a total and calls it explained has not explained anything. The test of the work is whether every dollar of divergence is attributed to a named cause, and whether the dollars that cannot be are declared rather than absorbed.
| Component | Amount | Cause, and where it was established |
|---|---|---|
| RW-07 rework | $268K | Joints failed initial holiday testing, re-inspection not yet scheduled. Established from the inspection certificate itself, not from the project system, which shows only that the joints were produced. |
| Cut-off timing | $37K | Claimed after the inspector's cut-off date for this visit. Certifies next period on the ordinary cycle. Not an exception, and not escalated. |
| Unexplained | $25K | Attributable to no cause found in any of the four systems or the certificate. Flagged as unexplained and carried as unexplained. Not absorbed into RW-07 to make the reconciliation close. |
| Total | $330K | Claimed $2.91M less certified $2.58M. |
The $25K is the point of this example, not a blemish on it. A reconciliation that always closes is not evidence that the reasoning is good. It is evidence that something is absorbing the residual, and in the manual process that something is a person under time pressure at period end, deciding a small number is not worth chasing and rolling it into the nearest plausible cause. The architecture's claim is not that it explains everything. It is that what it cannot explain arrives labelled as unexplained, in the period it arose, at a size someone can still decide about.
| Component | Amount | Cause, and where it was established |
|---|---|---|
| Retention held | $129K | 5% of certified, under this contract's clause 14.3. Read from the clause, not applied from memory or from whichever prior contract a reviewer last worked on. |
| Within terms | $101K | Certified inside the last 30 days, invoiced, not yet due. Ordinary timing, no action required. |
| Total | $230K | Certified $2.58M less collected $2.35M. |
Retention is the clearest case for the shared semantic layer in the whole document, and it is worth being explicit about why. This contract retains at 5%. The one before it may retain at 10%, or at 5% stepping to 2.5% on practical completion, or at 10% capped at a fixed sum. The clause is not hard to read. It is hard to consistently read, on the fortieth contract, in the last week of a close, when a reviewer who has read thirty-nine others is applying the one they remember rather than the one in front of them. That is not a competence problem, and it will not be fixed by a reviewer trying harder. It is what a definition queried live from one source exists to remove.
What reaches the reviewer is not an open question. It is a completed case file: the four positions, both gaps decomposed to named causes, the $25K declared unexplained, and a recommendation, here, to escalate RW-07 for re-inspection status ahead of period end. Three ways to respond, and all three are genuine:
The reviewer reads the case and stops at RW-07. She was on the client call last Thursday. RW-07 cleared re-inspection nine days ago. The inspector signed it in the field, the certificate went to the client's document controller, and it has not been loaded into the document store. The agent read the most recent certificate available to it, and the most recent certificate available to it was stale.
She rejects the proposal and returns it with that single fact. The coordinating agent re-requests the certified position against the client's issued register rather than the local store, finds the updated certificate, and reassembles the case: certified moves to $2.85M, and the exposure inverts. Recognition at $2.74M now sits $110K behind certification rather than $160K ahead of it, which is the conservative direction and not an exposure at all. The escalation is withdrawn, because there is nothing to escalate. The $25K remains unexplained, because it was never RW-07's to explain. Total elapsed, from her correction to the reassembled case: under an hour.
Read what this example is actually doing. The agent was not wrong about the document. It was wrong because the document was wrong, which is the failure mode this class of system genuinely has, and it is the reason the review step is not decoration. Every part of the recovery is only possible because the case named its source: she could see which certificate it read, which is the one thing a spreadsheet arriving at her desk has never been able to tell her.
Why this outcome, and not the clean one. An illustration that ends in confirm-as-proposed demonstrates speed and nothing else, and anyone who has closed a period knows it is not the honest case. This one ends with a person catching the machine, using knowledge that exists nowhere in any system, and the machine recovering in under an hour because every figure it used carries its source. If finance operations reads one section of this document, it should be this one. The proposition is not that the agent is more reliable than the reviewer. It is that the reviewer stops spending her day assembling what she should be spending it judging.
What this collapses. What today takes the better part of a day, sometimes over two, and depends on one person moving through four systems and a document folder, becomes one reviewed pass the same day, including the correction above, with the full trail available if it is ever needed again.
A pilot or a proof of concept is only useful insofar as it answers what the steady state actually looks like. This section describes the resulting workflow directly, for a CFO's periodic review and for finance operations' day-to-day work, rather than leaving that picture implicit.
Everything above concerns PC-118. The only question that follows from it is what happens at forty, or eighty, and that is arithmetic rather than argument. It is also the one calculation in this document we cannot perform, because two of its three inputs are yours and we have not seen them. The table is laid out so it can be completed in the meeting rather than taken away.
| Input | Value | Where it comes from |
|---|---|---|
| Active contracts per period | [ ] | Yours. The count subject to a billing reconciliation each period, not the total on the books. |
| Days per contract, today | 0.5 – 2+ | Ours, and estimated. Stage one replaces this with your own measured figure, which is the main reason stage one exists. |
| Person-days per period | [ ] | The two rows above, multiplied. At forty contracts this lands between 20 and 80+ person-days on contract billing reconciliation alone. |
| Blended daily cost | [ ] | Yours. Fully loaded, for the people actually doing this work. |
| Annual, at 12 periods | [ ] | The recurring figure. This is the number the decision is actually made against. |
Two honest notes on this arithmetic. First, the recovered time is not recovered headcount and we are not going to present it as such. It is the same people, on the judgment half of their work instead of the assembly half, which is worth having on its own terms and is a different claim from a saving. Second, this table deliberately omits the thing a savings case usually leads with, the cost of the $25K residual absorbed quietly, the recognition gap found in the wrong month, the audit finding that lands. We omit it because it cannot be honestly estimated from outside, not because it is small. In our experience it is the larger number, and it is the one stage one is designed to let you size for yourself.
Reconciliation queues are worked continuously through the period rather than assembled entirely at close, because a coordinating agent flags a divergent position, a contract billing gap, an unexplained cross-entity break, as soon as the underlying figures are available, not only when someone opens the file at month end. By the time close activities formally begin, the majority of routine cases have already reached a reviewed, evidenced conclusion, and what remains for the close window itself is the smaller set of genuinely judgment-heavy exceptions, the ones a person needed to weigh in on regardless of how the supporting figures were assembled.
An internal or external audit walkthrough of a reconciliation no longer depends on reconstructing what a specific reviewer was thinking on a specific date. The evidence log holds the inputs used, the definition applied, and the approval given, independently queryable without re-running the case itself, which converts a walkthrough from an exercise in trusting recollection into one of retrieving a record that already exists.
The work that remains is the work that was always genuinely theirs: deciding what a finding means and what should happen next, not assembling the finding in the first place. A completed, sourced case arrives for review rather than requiring construction from four systems and a document folder, and where something in that case looks wrong, the full trail behind it is available to check directly, not reconstructed from memory or a saved spreadsheet.
Two stages, deliberately separated, because they ask for different things and carry different risk. An earlier draft of this document collapsed them into one and claimed both that real contracts would be tested and that no system would be touched. Those cannot both be true, and the distinction below is what resolves it. The only decision in front of you today is stage one.
| Term | Detail |
|---|---|
| Duration | Five working days, fixed. Not five days that become eight. |
| Fee | [FEE], fixed, invoiced on completion regardless of what we find. |
| System access | None. No connection, no credentials, no read access, nothing installed. |
| Security review | Not applicable, and that claim is true here specifically because no system is touched. |
| Procurement | Not started, and not started by this. |
| Asked of you | Roughly six to eight hours of finance team time across the week, scheduled around the close, plus sight of two or three real contracts and their reconciliation working papers, in whatever form they already exist. |
| Produces | Every estimated figure in this document replaced with yours. The multiplier table completed. A written statement of which of the six frictions are actually present here and at what scale, including any that are not. A scoped, priced definition of stage two, or a recommendation not to run one. |
| Exit | It ends on day five with a document. There is nothing to unwind and nothing to cancel. |
Stage two is where real cases are worked, and it is therefore where the honest terms change. Read-only access to the relevant systems is required. A security review does apply, and should. This is stated here rather than discovered in week three.
| Term | Detail |
|---|---|
| Duration | [N] weeks, with a stated stop date agreed before it begins. |
| Scope | One friction, one entity, an agreed set of contracts. Not six frictions. |
| Access | Read-only, scoped to the agreed contracts, subject to your security review on your timetable. Nothing is written to any ledger at any point. |
| Runs | Alongside the existing close, never instead of it. Today's close does not depend on the pilot succeeding and is not paused, redirected, or altered while it runs. |
| Exit criteria | Agreed in writing at the end of stage one, before any build begins. The criteria include what would constitute failure, and we would rather write those with you than be marked against ones invented afterwards. |
Sign-off on stage one, at [FEE], for five days. That is the whole decision. It is reversible, it is timeboxed, it commits nothing to stage two, and it produces a document you own whether or not you ever speak to us again.
Six to eight hours across a week, and candour about where this document is wrong. No new system to learn, no change to the close calendar, and nothing to feed. In stage two, time to review output against work already being done and to flag where it is wrong, which is the same reviewing muscle used on PC-118.
Stage one. Five working days. [FEE], fixed. No access, no security review, no procurement.
We would ask for a decision by [DATE], so that stage one runs inside the [PERIOD] close window. That timing is not a sales device. The frictions in this document are only observable while the close is actually happening; run it in a quiet week and we will be looking at last month's working papers and your team's recollection, which is precisely the evidentiary problem the rest of this document is about.
If stage one says the pattern is not here at this scale, that is a valid and useful outcome, it is written up as such, and there is no stage two.
A precise entry for each working part, for anyone who wants one level deeper than the sections above. Written for lookup, not for reading start to finish.
The part that holds one case, such as a contract's reconciliation, from invocation to conclusion.
Requests exactly the figures and definitions the case needs, builds the explanation once everything is in hand, and hands it to a person before anything is finalized.
The manual movement between systems that currently falls to one person, doing every step in sequence.
Brought in for one narrow task the coordinating agent cannot do itself, such as reading an inspection document.
Performs exactly that task, reports the result back, and stops existing the moment it does.
Unstructured work, like reading a document, that a structured data request cannot reach on its own.
The single route between any agent and every system it touches.
Checks every request twice: once that it is a real, pre-approved kind of request, once that this specific agent is permitted to make it here. Returns figures exactly as computed, never recalculated.
The absence of any independent checkpoint on what an automated step is doing, and the risk of it acting outside its intended scope.
One place holding what counts as a valid match, claim, or variance, for this business.
Gives every case the same answer to the same question, regardless of which case is asking or which entity's coding scheme applies.
The same question producing a different answer depending on who, or what, is answering it.
The existing ledger and source systems, unchanged.
Remains the sole source of every figure used anywhere in this architecture.
Any concern that this introduces a second, competing version of the truth.
A record of every request made, every figure returned, and every approval given, held by the business directly.
Lets a past case be reconstructed and checked after the fact, without taking anyone's word for it.
A trail that exists only inside someone else's system, and has to be trusted rather than checked directly.
Everything in this document is written in plain terms. Nothing in it has been simplified away to achieve that, and this annex exists so that claim can be checked rather than accepted. Every term used in the body maps to an exact technical equivalent below, the open standards are named, and the full layer architecture is set out as an architect would draw it. This section is written to be detached and handed to a CTO or an enterprise architect without amendment.
The left column is the language used throughout this document. The right column is the same thing, named as it would be in an architecture review. They are the same components. The translation is one of vocabulary, not of substance, and where a plain term is narrower than its technical equivalent, that is stated rather than glossed.
| Term used here | Technical equivalent | What the technical form adds that the plain term does not carry |
|---|---|---|
| Coordinating agent | Coordinator, provisioned per workload | Provisioned per workload rather than per case, and persists the way a role on an org chart persists. The coordinator catalog grows deliberately, one workload at a time. It holds no standing access beyond what its current objective requires. |
| Specialist agent | Spawned specialist, provisioned per task | Provisioned per task, holds no state after returning its result, and is released on completion. The specialist catalog can grow as new task types are identified without touching how any coordinator operates. |
| Control boundary | Membrane : action catalog plus scope validation | The two checks have names. The action catalog is the fixed, pre-approved set of everything an agent may request, with exact names and exact inputs defined in advance, which is what makes every call checkable before it runs. Scope validation is the per-call check of whether this agent may take this action on this object. It is the only path to the record by construction, not by policy: no direct database access, no alternate route. |
| Shared semantic layer | Semantic layer : queried live, with entity resolution | Queried live per request rather than compiled into agent logic, so a renegotiated retention clause propagates to every agent immediately with no retraining. Entity resolution sits above however many inconsistent coding schemes exist and reconciles at query time. It does not require one clean source first, which is the assumption that makes most master-data programmes multi-year. |
| Independent evidence log | Evidence & lineage rail | Append-only. Each entry pins three things: exact inputs, exact model version, exact authorising approval. Queried independently of the agents, so verifying a past decision never requires re-running the reasoning that produced it. Held by the enterprise, not asserted by a vendor. |
| System of record | System of record, unmodified | Deliberately the least interesting layer. The membrane changes; the record does not. This is what allows the stack to survive an ERP migration intact: agent plane, semantic layer, membrane and evidence log all carry over, and only the connector configuration beneath the membrane changes. |
| State carried across a case | Persistent state, across task and session | State survives session boundaries. A case reopened next month resumes from where it stopped rather than from zero, which is the specific property most closed vendor runtimes lack and the reason an investigation reopened later starts cold. |
| "A defined way for an agent to reach a tool" | Model Context Protocol (MCP) | Named, open, published, already in production inside financial institutions. Not ours. Stateful tool access without wiring the agent into the tool's internals. |
| "A companion standard for handing work between agents" | Agent2Agent (A2A) | Named, open, published. Delegation between agents. Also not ours, which is the commercial point as much as the technical one: the interface between this architecture and your estate is not an asset we hold over you. |
The controls flow in the architecture tab shows who may do what. This shows what sits on what. Both describe the same system; neither is a simplification of the other.
Four things below are stated as design principles, true regardless of which business runs this. Where the answer is genuinely specific to an environment we have not seen, that is named as such rather than assumed.
Every agent carries its own identity inside the existing maker-checker model. An agent may propose; it may never approve its own work or another agent's.
The specific identity provider and permission schema this business already runs.
Every log entry is pinned to the exact model version that produced it, so a later change in reasoning capability never retroactively alters what a past decision is understood to have relied on.
The specific versioning and rollback tooling.
The agent plane and the membrane are logically separate from the record regardless of where each physically runs.
Cloud, on-premise, or hybrid, whatever this business already operates.
A spawned specialist runs with access to exactly the tool catalog its task requires and nothing else. That access ends when the specialist does.
The specific runtime isolation mechanism.
On what this annex is for. A document written in plain language invites the suspicion that complexity has been hidden rather than translated. This annex exists to make that suspicion testable. If any term in the body reads as vaguer than the thing it names, the row above is the thing it names, and the two should be compared rather than trusted.