Explore the architecture

Decision Infrastructure

Architecture

How Inversiq turns data, models, AI reasoning, policy, software execution and human authority into one governed decision system.

This document describes the architecture Inversiq is building toward. It is an architecture, not a delivery roadmap. Commercial real estate, the first proving domain, supplies the examples. Nothing in the architecture depends on it.

Start readingNew to the category? Start with the overview
A consequential decision passes through seven strata: data and context, models, AI reasoning, software execution, policy, human authority and the decision record.
Chapter 01

Overview

What Decision Infrastructure is, and why the decision is the unit.

  1. 01.1The decision is the unit
  2. 01.2Three claims

01.1The primary object

The decision is the unit.

Most enterprise software is organised around a record, a process, a document or a conversation. Decision Infrastructure is organised around the decision itself: the question, the options, who may approve it, and what follows. The acquisition below keeps the same identity for years, long after the vote.
DecisionD-0417

Acquire logistics portfolio A

Identity
kept for years, across every view
Lifecycle
framed, authorised, active, closed

Basiswhat it rests on

  • Question & frameWhat is decided, for which scope, by whom, by when.
  • BasisData, facts and assumptions, each with its source and standing.
  • RelationshipsEntities, other decisions, shared assumptions.

Analysiswhat follows from it

  • AlternativesEvery option considered, including doing nothing.
  • AnalysisRuns, scenarios and experiments on one kernel.
  • UncertaintyRanges, distributions and what would reduce them.

Authoritywho may, and what it licenses

  • ChallengeFindings, formal challenges and recorded dissent.
  • AuthorityWho may decide, under which grant and policy.
  • ActionsWhat it authorises elsewhere, and on what terms.

Consequenceswhat it leaves behind

  • MonitoringThe conditions it must keep meeting, and the monitors that watch them.
  • OutcomesWhat happened, against what was expected at the time.
  • MemoryWhat the institution can recall from it, years later.
Fig. 01.1One decision and everything bound to it, in four groups. Each part of this page explains one of them.Illustrative

Views onto the decision, or work around it. None of them is it.

  • DocumentsA memo is at most an output of the decision.
  • TasksTasks organise the work around a decision.
  • ChatA conversation can propose. It cannot commit.
  • WorkflowsWorkflow serves the lifecycle. It is not decision state.
  • DashboardsDashboards describe metrics, not commitments.

01.2The thesis

Three claims the architecture rests on.

Ask an institution which live decisions rest on an assumption it now believes wrong, which approvals relied on data later corrected, or whether the approver's mandate was still valid on the day. Most need an investigation to answer. Each is a question about institutional state. Today a consequential decision spans data, models, people and systems, and no single system holds that state.
  1. CLAIM 01

    Decisions have persistent state.

    A decision has a basis, an analysis, challenges, an authority path and consequences. That state does not stop at approval. It links to other decisions and entities, and it is still there years later, when someone needs to know why.

  2. CLAIM 02

    Authority becomes the bottleneck.

    Models already draft analysis, extract data and propose actions faster than institutions can check them, and they keep improving. The scarce thing is knowing where things stand: what is established, what is only assumed, who may decide and what may be done. In a form that survives audit.

  3. CLAIM 03

    Governed history compounds.

    Every governed decision leaves structure behind: a sealed record, links to entities and assumptions, and an expectation that outcomes are later judged against. Over time that becomes institutional memory, and with outcomes, calibration. Only governed use creates it, and it belongs to the institution.

Definition

Decision Infrastructure is the governed layer through which an institution frames, assembles, computes, challenges, authorises, records, executes, monitors and learns from its consequential decisions, such that every decision is reconstructable, every authority is explicit, and every change to institutional state or to the outside world passes through controlled boundaries.

  1. frames
  2. assembles
  3. computes
  4. challenges
  5. authorises
  6. records
  7. executes
  8. monitors
  9. learns

  • Authority is structure, not a login

    Who may decide or act, for what and within which limits, is data the system evaluates at every change.

  • Reconstruction is a query

    What was known, assumed, computed, challenged, authorised and done, as of any moment, can be answered without an investigation.

Chapter 02

The system

How it is structured: seven responsibilities kept apart, what surrounds the system, what it does, and how a decision moves.

  1. 02.1Seven responsibilities
  2. 02.2Context
  3. 02.3Functional architecture
  4. 02.4Decision lifecycle

02.1Seven responsibilities

One decision, seven responsibilities.None of them may do another's job.

Most systems blur interpretation, calculation, rules, approval and memory into one workflow. The architecture separates them on purpose, because each has a different standard of truth: what may be probabilistic, what must be exact, what must be explicit, who must be named, and what must be kept.

May be probabilistic

Interpretation and preparation

01

Data & context

Source documents, structured data, connected systems, models and the institution's own context, each with its source, rights and time.

ProducesLocated, attributed sources
RuleReceived is not relied on.
02

Decision intelligence

Interpretation, research, comparison and recommendation over the decision's own governed context.

ProducesInterpretations and recommendations
RuleProposes. Never decides.
03

Agents & reasoning

Agents prepare work inside the decision context, through one runtime, with a delegated scope, a budget and a journal.

ProducesPrepared work and proposals
RuleNo shortcut around a boundary.
Commit BoundaryNothing above this line becomes institutional state without crossing it.

Must be exact

Calculation

04

Deterministic execution

Exact calculation on pinned models and versioned methodology: reproducible runs, validation and reconciliation.

ProducesExact, reproducible results
RuleNo language model in the calculation path.

Must be explicit

Conditions

05

Governance & policy

Rules, limits, exceptions and approval conditions, held as versioned data and evaluated at one decision point.

ProducesConditions and findings
RuleFails closed.

Must be named

Authority

06

Human authority

Named people hold the authority to make consequential decisions, under grants and delegations that are themselves data.

ProducesNamed authorisations
RulePlatform access is not authority.

Must be kept

Record and memory

07

Decision record & learning

Inputs, assumptions, execution, authority, rationale and outcomes, recorded at the time and compounding into institutional memory.

ProducesRecords, outcomes, calibration
RuleWritten at the time. Never rewritten.
proposal or inputexact resultcondition held as datanamed authorityrecorded state
Fig. 02.1Seven responsibilities, grouped by the standard each must meet. What may be probabilistic reaches institutional state only through the Commit Boundary: validated, checked against policy and, where it matters, authorised by a named person.

The same system, drawn seven ways.

A single stacked diagram would hide most of what matters. Each view answers one question about the same system, and the views agree with one another.

  1. 01ContextWhat is outside the system, and how does the system relate to it?02.2
  2. 02FunctionalWhat does the system do, and where does each capability live?02.3
  3. 03InformationWhat state does it hold, and what kind of state is it?03.4
  4. 04ControlWho may change what, and how is that enforced?05.2
  5. 05LifecycleHow does a decision move, and through which loops?02.4
  6. 06PlatformHow is it built so it can carry many domains and institutions?08.1
  7. 07EvolutionWhich capabilities depend on which, and what does maturity mean?10.1

02.2View 01 · Context

Read broadly.Write narrowly.

Decision Infrastructure sits beside the systems that run the business. It reads from them and records where every value came from. It writes back only when an authorised decision calls for it, through governed actions. It keeps the record of the decision, not of every business object.

Read broadly

  • Systems of recordProperty, accounting, loan servicing, identity
  • Documents & data roomsData rooms, archives, document stores
  • Market dataTransactions, rents, yields and indices, under licence
  • PeopleJudgement, review, dissent and authority
reads, with provenance
Model suppliers behind a gateway and registry; replaceable. Proposals only.

Inversiq

Decision Infrastructure

Commit Boundary
State CoreStorethe presentLedgerthe historyGraphthe connectionsRecordsthe proofs
Execution Boundary

Fourteen engines around the State Core. Holds the decision; never the business's own books.

writes only through the Execution Boundary

Write narrowly

  • Systems of recordGoverned actions only, through the Execution Boundary, confirmed on effect

Read-only projections, access and events

  • CounterpartiesLenders and co-investors receive attested projections, never raw state
  • Auditors & supervisorsFull, logged, read-only access the first line cannot revoke
  • SubscribersTreasury and reporting systems subscribe to decision events
Fig. 02.2Many sources come in, each with its provenance. Only one path writes back, through the Execution Boundary. Model suppliers contribute proposals, never authority.

The system of record for the decision, beside the systems of record for the business.

Inversiq does not replace ERP, CRM, property management, accounting or document stores. Not owning the business's books is what lets it outlast any one of them.

Stays in its own system of record

  • Leases and tenancy schedules
  • Balances and ledgers
  • Loans and covenants as booked
  • Documents and data rooms
  • Customer and counterparty records

Held by Decision Infrastructure

  • The decision and its lifecycle
  • Its basis: facts, assumptions, evidence links
  • Its analysis, challenges and dissent
  • Its authority path and sealed record
  • Its actions, monitors and outcomes

02.3View 02 · Functional

One State Core.Fourteen engines. Three enforcement points.

Every engine reads from one State Core. Three enforcement points control change: the Commit Boundary for anything that becomes institutional state, the Execution Boundary for anything that leaves for the outside world, and the Governed Agent Runtime for anything a machine actor does. All three ask the same policy decision point.

One logistics acquisition of three warehouses, in six steps. Machine actors take part throughout, but only through the Governed Agent Runtime.

  1. 01

    Data and context enter

    The data room is imported: leases, rent rolls, the information memorandum. Each version is hashed and attributed to its source. Tenants, assets and the seller resolve to persistent entities, and NOI means the institution's own definition.

    Data & ContextKnowledge & Semantics
  2. 02

    The engines work on the decision

    Models extract lease terms with clause references and draft a first brief, all as proposals. One pinned kernel run computes cash flows, DSCR and returns. A registered forecast proposes an ERV range. Decision Science finds the breakevens and a maximum bid.

    ReasoningComputationPredictionDecision Science
  3. 03

    Assurance attacks the case, governance decides

    A GLA mismatch becomes a finding, and a risk officer challenges the void assumption. Readiness is computed, not declared. The committee, holding a grant from the fund documents, authorises with a condition precedent and a validity envelope.

    Verification & AssurancePolicyAuthorityDeliberation
  4. 04

    Authoritative state persists

    Accepted rents, the adopted exit yield and the authorisation each cross the Commit Boundary with a named actor. The State Core records every change with a ledger event, and the authorisation seals a record of everything it relied on.

    Commit BoundaryState Core
  5. 05

    Action is controlled

    The letter of intent and the deposit instruction each pass the Execution Boundary's nine checks. Treasury keeps its own release authority and dual control. An action is complete only when its effect is observed.

    Execution BoundaryControlled Execution
  6. 06

    Feedback comes back

    Two years later the anchor tenant is downgraded. A monitor opens reconsideration and the committee reaffirms with a new condition. Outcomes are judged against the recorded expectation, learning proposes a wider exit-yield range, and the next acquisition recalls this one.

    ObservationLearningMemory
Core services.
Orchestration of cases and tasks, the model gateway and registry, the connector framework, and the Workspace, Console, SDK and API.
Rails through everything.
identity tenancy security & keys provenance time versioning reconstructability observability

02.4View 05 · Lifecycle

Authority sits in the middle of the lifecycle.

Every decision follows one lifecycle, and every sequence on this page is a view of it. Authority is a transition inside it. Before it, the case is prepared and challenged. After it, the decision stays active, and goes back to authority when the conditions it relied on change.

Before authority

  1. Framed
  2. In preparation
  3. In assurance
  4. Ready for authority

Authority transition

Commits the institution; requires authority; seals a record.

Authorise · Authorise with conditions · Decline · Defer · Reaffirm · Amend · Supersede · Revoke

After authority

  1. Authorised
  2. In execution
  3. Active
  4. Reconsideration required
  5. Closed

The validity loop: when conditions change, a monitor triggers reconsideration, which returns to authority to reaffirm, amend, supersede or revoke.

Terminal or side states

  1. DeclinedThe institution decided not to proceed. A decline is a decision, recorded like any other.
  2. DeferredThe institution decided not to decide yet, with a review date.
  3. WithdrawnThe proposer abandoned the question before authority.
  4. Superseded or revokedA later decision replaced or cancelled it.
  5. VoidableThe authority behind an authorisation is later found invalid or conflicted.
Fig. 02.4The lifecycle as a state machine. Green is the validity loop: when an active decision's conditions change, it goes back to authority. Declined, deferred and withdrawn are recorded endings, not gaps.

Before authority

The question is framed with its alternatives, the case is prepared, and assurance tries to break it. It moves on only when readiness, recomputed on the current state, is satisfied.

The authority transition

Every transition that commits the institution needs authority and writes a sealed record in the same step. Declining and deferring are decisions too.

After authority

Actions leave through the Execution Boundary. The decision then stays in force and watched until it is closed, superseded or revoked. Outcomes are still judged after closure.

Workflow software

  1. Task
  2. Review
  3. Approve
  4. Done

The process ends at approval. What was approved, on which assumptions, and whether it still holds, belongs to nobody.

Decision infrastructure

  1. Framed
  2. Assured
  3. Authorised
  4. Active
  5. Monitored
  6. Reconsidered
  7. Closed
  8. Outcome judged

The decision persists after approval, with its conditions and monitors, until it is closed or superseded. Workflow still organises the work around it.

Changing the system itself is a decision too. Adopting a methodology, raising a threshold, approving a model or granting a delegation follows the same lifecycle and passes the same boundaries, so no configuration change goes unaudited.

Chapter 03

State & knowledge

What the system holds: data, meaning, the standing of every value, and one State Core.

  1. 03.1State, not a search index
  2. 03.2Data, context, evidence
  3. 03.3Knowledge & semantics
  4. 03.4The value envelope
  5. 03.5What we knew, and when
  6. 03.6Provenance & lineage
  7. 03.7The State Core

03.1Decision context

Decision context is state.Not a search index.

A search index can find every document that mentions an exit yield. It cannot say whether 5.50% is a fact or an assumption, who adopted it, which run used it, which policy it was tested against, or whether the committee relied on it. The architecture holds decision context as typed state: each kind with its own writer, its own standing and its own rules.

A search index · what mentions it

exit yield logistics portfolio A
  • IC_memo_draft_v4.docx0.91… the exit yield of 5.50% reflects current pricing …
  • Broker_opinion_September.pdf0.88… we would expect exit yields between …
  • Valuation_2023_Warehouse_A.pdf0.84… exit yield 5.25% applied to year seven …
  • Email: re exit assumptions0.79… can we hold the exit flat if the …
  • Market_report_Q2.pdf0.71… prime logistics yields moved out by …

Five documents, ranked by similarity. No standing, no owner, no time, no authority.

Decision state · what it is

D-0417 · Acquire logistics portfolio A · as of 12 September

  1. Source dataWhat arrivedRent roll v3, received 14 August from the vendor's data roomsha256 7f3a…c21·Data & ContextReceived, not yet relied on
  2. Derived stateWhat follows from accepted factsNet operating income €4.3m, from rent roll v3 and fourteen leasesderived · 3 inputs·Computation, from accepted factsAs firm as its weakest input
  3. Model stateHow it was computedCash flows, debt metrics and returns under methodology v7run r_812 · pinned·The deterministic kernelImmutable, reproducible
  4. AssumptionsWhat is adopted, not establishedExit yield 5.50%, plausible range 5.00 to 6.25%v2 · replaces 5.25%·Proposed by a model, adopted by the head of researchAuthoritative, adopted
  5. PolicyWhich conditions applyMaximum LTV 55%; committee approval above €25mfund policy v4·Policy, held as versioned dataIn force on 12 September
  6. Review stateWhat was challengedTwo findings waived with rationale; one challenge answeredbound to snapshot·Assurance and deliberationGoverned, append-only
  7. Decision stateWhat was decided, by whomAuthorised with a condition precedent by the investment committeerecord R-17·Named authority, through the Commit BoundaryAuthoritative, sealed
Fig. 03.1The same question asked of two systems. A search index returns what mentions the exit yield, all on one level. Decision state says what each piece of context is, who wrote it and how far the institution may rely on it.Illustrative

The rest of this chapter takes the kinds apart: data and evidence, meaning, the envelope every value travels in, time, lineage, and the State Core that holds them all.

03.2Data & Context

Data is what arrives.Evidence is a relation.

Most of what enters the system is never evidence for anything. Evidence is data judged relevant to a specific claim, and that judgement is worth recording. So the architecture keeps data, context and evidence apart.
Data
Everything that arrives: documents and their versions, feeds from systems of record, licensed market data, and what people say, attributed to them.
Context
What the institution brings: mandates, policies, committee terms and methodology. It applies across decisions and changes only under governance.
Evidence
A link between data and one claim in one decision: it supports, contradicts or qualifies that claim. What was relied on is recorded at approval.

One data object, three relations

Data object

Rent roll v3

From the vendor's data room. Received 14 August.

sha256 7f3a…c21

  • supportsNOI of €4.3m in decision D-0417
  • contradictsThe broker's 98% occupancy in the same decision
  • no relationTenant covenant strength judged from other data
Fig. 03.2One rent roll, three claims. It supports the NOI figure, contradicts the broker's occupancy figure, and says nothing about the tenant's covenant. Evidence is decided per claim, per decision.Illustrative

From data to institutional claim.

A document yields located statements. A statement linked to a claim becomes evidence. Only after crossing the Commit Boundary does a value gain a standing the institution relies on, and each standing asks for different proof.

Working state: proposed, not yet relied on

  1. Data objectA document or feed, received with a fingerprint and a time.
  2. AssertionA statement located in it: page, clause or cell.
  3. EvidenceThe assertion linked to a claim in one decision.
Commit Boundary

A standing the institution relies on

  • FactAccepted as true for the institution's purposes.
  • AssumptionAdopted for analysis, not established. Most decision risk lives here.
  • DerivedComputed by the kernel; as firm as its weakest input.
  • HypothesisUnder test, with what would confirm or refute it.
  • JudgementA named person's assessment. Never written by AI in their name.
Fig. 03.2bBefore the Commit Boundary, everything is still a proposal. How a value was produced (observed extracted computed estimated elicited) is recorded separately from its standing: a forecast can be adopted as an Assumption, a rent under a signed lease accepted as a Fact.

03.3Knowledge & Semantics

Meaning is read by every stage.

Knowledge & Semantics turns information into meaning: what things are, which things are the same, and what the institution means by its own measures. Every stage reads it. It changes more slowly than data and under different governance, so it is its own engine.

  • Domain ontology

    Typed entities, attributes and relationships, so every engine means the same thing by “lease”, “unit” or “passing rent”.

  • Measure definitions

    What NOI means in this institution's methodology. Comparing decisions requires knowing it meant the same computation.

  • Units & currencies

    Explicit units, area standards and FX with a recorded source and date. Silent unit errors are among the most common material errors.

  • Methodology

    The institution's versioned way of analysing a decision class. It is the customer's intellectual property: expressed, never supplied or shared.

  • Thresholds: discard below 0.40, review queue between, match under policy from 0.85.
  • DHL Supply Chain (Netherlands) BVLease L-17, parties clause0.97 · matched under policy
  • DHLBroker memorandum, p.40.90 · matched under policy
  • D.H.L. Logistics NLRent roll v3, row 220.71 · review queue
  • DHL Express IberiaMarket comparables0.22 · discarded
Fig. 03.3Four mentions of one tenant group, scored against the resolved entity. High scores merge under policy, middling scores wait for a person, low scores are discarded. Without this, the same tenant in two deals is two strangers.Illustrative

Resolved: Tenant group T, one persistent entity across leases, memos, decisions and time. It returns in chapter 07, where one tenant touches three decisions.

Every merge is recorded with its score and threshold, and can be reversed.

03.4View 03 · Information

Every material value travels in an envelope.

A memo shows 5.50% and moves on. The architecture keeps what kind of claim that number is, its unit, how sure anyone is about it, where it came from, and when. Much decision risk hides in assumptions presented as facts. The envelope makes the difference part of the state.
Exit yield, year 75.50%Capitalisation rate · unit: percent

What kind of claim it is

Standing · how the institution relies on it
Assumption
Origin · how it was produced
Elicited from an expert
Value state · where it is in review
Adopted; challenged and answered
Uncertainty · how sure, and why
Plausible range 5.00 to 6.25%Cannot be settled now: it depends on the market in year seven

Where it came from, and when

Provenance · what it rests on
12 comparables, 2 broker opinions, head of research
Version · what it replaced
v2, replaces 5.25% after a broker opinion
Valid time · when it is true in the world
At exit, year 7
Recorded time · when the institution learned it
9 September, 16:05

Who it belongs to

Owner · who answers for it
Head of research
Tenant · whose state it is
Institution A
Fig. 03.4One value and the fields recorded around it. Each field carries a short plain-English name beside its technical one.Illustrative
Passing rent, Warehouse A€4.10mFact
Standing · how the institution relies on the value
Accepted as true, by a named analyst
Basis · what the value rests on
The signed lease, clause 4.1, and rent roll v3
Uncertainty · how sure, and what would change that
None to speak of: the lease settles it
Exit yield, year 75.50%Assumption
Standing · how the institution relies on the value
Adopted for analysis; challenged and answered
Basis · what the value rests on
12 comparables and 2 broker opinions
Uncertainty · how sure, and what would change that
5.00 to 6.25%; only the year-seven market will settle it
Fig. 03.4bA Fact and an Assumption, on the three fields where they differ most. The fact is settled by its source. The assumption carries its range and its reasons, and a committee should see both.Illustrative

03.5Temporal state

What we knew when we decided.

Every material value carries two dates: when it was true in the world, and when the institution learned it. A correction is a new version, never an edit. So a decision can be reconstructed years later exactly as it looked on the day it was made.

As of Now: the institution believed 39,850 m². The committee relied on 41,200 m².

Decision basiswhat the committee relied on, 12 Sep

41,200 m²

rent roll v3, bound into its record
Institutional knowledgewhat it believed, as of now

39,850 m²

1,350 m² lower · 3.3% · a finding

A corrected rent roll arrived on 3 October. The institution now believes 39,850 m²; the committee's record still shows 41,200 m². The gap is a fact the system can query, and every decision that relied on the old figure gets a finding.

  1. 14 AugRecorded: v1 · 41,200 m² (rent roll v3), valid from 1 July
  2. 12 SepKnowledge horizon: the committee decides on v1
  3. 3 OctRecorded: v2 · 39,850 m² (corrected), also valid from 1 July
Fig. 03.5The floor area (GLA) of Warehouse A, as recorded over time. Both versions are true from 1 July; the correction was simply learned later. Nothing is overwritten, so the committee's view survives.Illustrative

What did the committee know?

Asked of recorded time, up to the moment fixed in its record.

What was actually true?

Asked of valid time. Both answers stay available for years.

Staleness is computed

Against policy (a valuation older than six months, say) or against newer knowledge. Readiness and the Execution Boundary both check it.

03.6Provenance & lineage

From source to consequence.

A citation says where one value came from. Decision lineage links every value, calculation, recommendation, approval, action and outcome to what came before it, with who and when, as the work happens. Nothing has to be pieced together from a narrative afterwards.
  1. 01Source dataRent roll v3content hash
  2. 02AssertionPassing rent, p.2 row 14span locator, extractor v4
  3. 03AssumptionExit yield 5.50%value envelope
  4. 04CalculationKernel run r_812pinned engine, input hash
  5. 05ScenarioDownside grid, 400 cellsspecification, seed
  6. 06RecommendationProceed, bid up to €76.5mcontext hash
  7. 07ApprovalCommittee, four to one, after the void assumption was challengedsnapshot s_41, authority path

    Decision Record R-17 is sealed here: the record binds everything above at the moment of authority.

  8. 08ActionLetter of intent issuedcontract, outbox
  9. 09OutcomeYear-2 NOI 9% below expectationfrom accounting, against the sealed expectation
Fig. 03.6Read back from any step and you reach the source data. Read forward from a source and you reach everything that relied on it, which is how a corrected rent roll finds every approval it touched.Illustrative

A citation

“Source: rent roll, p.2.”

Says where one value came from. Nothing about how it was used, who accepted it, or what else depends on it.

Decision lineage

Year-2 NOI shortfall expectation in record R-17 run r_812 exit yield v2 twelve comparables two broker reports, by hash

Explanations, impact checks, corrections and learning all read this chain. A value without lineage is marked as such, and carries less weight.

03.7The State Core

At the centre: one State Core.

The State Core holds what the institution knows and assumes, what it has computed and challenged, and what it has authorised and done, with the history, the connections and the sealed proofs. Every engine reads from it. Nothing enters it except through the Commit Boundary.

Outside the core

  • Chatephemeral conversation
  • Agent memoryprivate to one actor
  • Documentsfile history, not claims
  • Telemetryoperations, not the record

May only propose, through the boundary.

Commit Boundary
State CoreStoreThe present. Typed values in envelopes, with bitemporal versions; written only through the Commit Boundary.LedgerThe history. One append-only event for every change, in the same transaction as the store.GraphThe connections. Typed relations between what the store holds, across decisions, entities and outcomes.RecordsThe proofs. Sealed from the store at each authority transition, referencing its ledger events.Authoritative decision state: the governed view of one decision, as of any recorded time.

Every engine

Reads
any state it is authorised to see, as of any time
Writes
only as proposals that cross the Commit Boundary
Subscribes
to ledger events, purpose-limited
Fig. 03.7Four parts, one object, drawn the same way everywhere on this page. Anything outside may propose; only what crosses the Commit Boundary becomes authoritative.

Nothing becomes institutional truth because

a model generated itan agent proposed ita source imported ita calculation produced it

It becomes institutional truth because it crossed the Commit Boundary.

AuthoritativeAccepted facts, adopted assumptions, decisions and their lifecycle states, grants, policies, authorised actionsWritten byThe Commit Boundary only, with a ledger eventRead asThe institution's position
Governed working stateReceived data objects, runs and experiments, findings, proposals awaiting obligations, inferred edges, agent run journalsWritten byTyped engine interfaces; append-only, tenant-scoped, with lineageRead asEvidence and work in progress, never the institution's position
EphemeralChat, caches, interface state, agent scratch memoryWritten byAnything, under tenancyRead asNothing outside its owner

Authoritative decision state is one decision, as of one moment.

Everything that bears on the decision: its basis, including disputed facts and uncertain assumptions; its analysis and alternatives; its open findings and answered challenges; its authority path; and its consequences so far. These are the four groups of the decision object in 01.1, now held as state.

Chapter 04

Intelligence & analysis

Four kinds of analysis, kept apart, around one deterministic kernel.

  1. 04.1Four engines, five kinds of model
  2. 04.2Quantitative methods
  3. 04.3Beyond the base case
  4. 04.4Optimisation
  5. 04.5Uncertainty
  6. 04.6Multi-model systems

04.1The Analysis plane

Four kinds of analysis, kept apart.

Reading a lease, calculating a return, forecasting a rent and choosing between options are different kinds of work, and each produces a different kind of claim. Merge two of them and nobody can tell what an output really is. So there are four engines, and each writes only through the Commit Boundary.
  1. ReasoningUses registered models

    What might be true, what should be asked, and how is it explained?

    Produces. Proposals: assertions with locators, hypotheses, challenges, drafted criteria, briefs and explanations from lineage.

    Never. Computes a material number, routes an approval, gates readiness or decides that a challenge is answered.

  2. ComputationDeterministic

    What follows exactly from these inputs?

    Produces. Exact, reproducible results from one versioned kernel, recorded as immutable runs.

    Never. Estimates an unknown or reasons about meaning. No language model sits in its path.

  3. PredictionUses registered models

    What is our calibrated estimate of an unknown quantity?

    Produces. Estimates with calibration evidence and applicability limits, entered as proposed assumptions.

    Never. Decides. An estimate is an origin, not a standing.

  4. Decision ScienceDeterministic

    What are we choosing between, against which criteria, and under which conditions does the choice hold?

    Produces. Breakevens, robustness regions, alternative comparisons, validity envelopes and computed proposals.

    Never. Adopts a result on its own, or supplies the institution's objective.

“Model” is not one thing.

Five kinds of model can influence a decision. They differ in what they produce, how they are checked and what their output is allowed to become. All sit in one registry, and none of them holds authority.

  • Language model

    Output
    Interpretation, drafts, hypotheses, explanations
    Validated by
    Contract checks and evaluation against a reviewed corpus
    Role in the decision
    A proposal. Numbers are quoted, never computed

  • Calculation model

    Output
    Exact figures, reproducible bit for bit
    Validated by
    Property tests, independent recalculation, reconciliation to the institution's workbook
    Role in the decision
    A run, cited by identifier

  • Predictive model

    Output
    Estimates with calibrated intervals
    Validated by
    Backtesting and calibration against outcomes
    Role in the decision
    A proposed estimate, adopted only as an assumption

  • Causal model

    Output
    The effect of an intervention, under stated assumptions
    Validated by
    Named identifying assumptions and an owner
    Role in the decision
    An assumption, never a fact

  • Solver

    Output
    Feasible or optimal combinations, with a certificate
    Validated by
    Binding constraints, shadow prices, re-solves
    Role in the decision
    A proposal, adopted by authority with the rejected alternatives recorded
Fig. 04.1Five kinds of model on the three questions that matter. Only the kernel's runs are exact and reproducible; every other output enters a decision as a proposal or an assumption. Every Decision Record lists the models that contributed.

04.2Quantitative methods

Language models interpret.Software computes.

When the answer can be computed, Inversiq computes it. AI may interpret a document or propose an assumption; deterministic software calculates its consequence; governance decides whether the result becomes authoritative. The reason is accountability, not model weakness: a committee must be able to reproduce a figure exactly, years later, under audit.

Interpretation · may be probabilistic

Broker_opinion_September.pdf · p. 3

… we would expect exit yields of around 5.50% for this quality …

Language model, registered version, via the gateway

Proposed: exit yield 5.50%

was 5.25% · cites p. 3

Levered IRR 8.9%Refused: a model may
not state the figure

No language model past this line

Execution · must be exact

Typed request

exit_yield 5.50% · assumption set v2 · schema v12

Deterministic kernel

engine 3.9 · methodology v7 · pure: no I/O, no clock, no model

Run r_812
Levered IRR 8.9%
60 bp lower
Re-run
8.9%
identical
Criterion
Holds
Commit Boundary

Authority · must be named

  • The head of research adopts the exit yield of 5.50%
  • Recorded in decision state, bound to run r_812

The IRR enters the decision by reference to its run. It is never retyped.

Fig. 04.2One changed assumption, three zones of responsibility. Interpretation may be probabilistic and ends in a proposal. Only a typed request crosses into execution, where the pinned kernel computes the consequence the same way every time. Only an adopted result, bound to its run, crosses the Commit Boundary.Illustrative

  • Reasoning may vary

    Two readings of the same opinion can be phrased differently. For an interpretation that is acceptable, because a person reviews it before anything relies on it.

  • Financial outputs may not

    The same inputs give the same IRR on every recomputation, years later, under audit. A figure that changes when asked twice is not a figure.

  • Versions are part of the answer

    Every run pins its kernel, methodology and schema. Changing a model is a registry change, evaluated before use, never a silent upgrade.

  • AI never composes financial truth

    A model may quote a computed figure and cite its run. It may not produce one, and nothing it writes becomes authoritative on its own.

An assumption can be uncertain while the calculation based on it is deterministic.

The assumption is uncertain
Exit yield 5.50%, held as a plausible range of 5.00 to 6.25% (03.4). Only the market in year seven will settle it.
Its consequence is exact
Each exit yield in that range gives one levered IRR, the same on every recomputation. Across the range, the kernel shows exactly where the case fails: above 6.1%, if rental growth also stays below 0.5% (04.3c).

  • One calculation truth

    No second expression of the domain mathematics anywhere: not in a solver formulation, a report template or a spreadsheet export. Experiments, optimisation and monitoring all call the kernel.

  • Runs are the unit of reproducibility

    Every record binds to runs by identifier and hash. A run reproduces bit for bit under its pinned versions, years later, under audit.

  • Workbooks are data

    An institution's own model is imported as data and reconciled against the kernel line by line, within tolerances, with differences explained. It is never executed as the engine.

  • Rules are data, mechanisms are code

    Checks are versioned, hashed data with a closed operator set and explicit outcome states. The mechanism is shared; the rule content is the institution's.

The methods, all over the one kernel

Deterministic financial computation
Cash flows, rent and debt schedules, covenant ratios, exit values, levered and unlevered returns.
This section
Sensitivity and stress testing
Which assumptions dominate, a breakeven per criterion, reverse stress on joint scenarios.
04.3 →
Uncertainty
Ranges through the kernel first; Monte Carlo only where distributions can be evidenced.
04.5 →
Decision science
Criteria as governed data, robustness regions, regret across alternatives, value of information.
04.3 →
Optimisation
The highest price at which every criterion holds. The answer is a computed proposal.
04.4 →
Prediction
Registered, calibrated estimators. A forecast enters as a proposed assumption, never as a figure.
04.1 →

04.3Decision Science

Beyond the base case.

A base case says what happens if everything goes to plan. A committee needs to know which assumptions matter, what breaks first and when the choice still holds. Each answer is a different computation over the one kernel, and none is adopted without authority.

Which assumptions dominate?

Exit yield dominates levered IRR; rental growth and the void period follow. Capex barely moves it.

Levered IRR, base 8.9%: change in percentage points

Fig. 04.3aSensitivity profile. Tornado and screening over evidenced ranges. Most committee questions need no probability distribution at all.Illustrative

What breaks first?

NOI can fall 18.75% before the DSCR covenant of 1.25x breaches, the first criterion to break. Breakevens are not forecasts, and are labelled so.

Fall in NOI from base at which each criterion breaches

Fig. 04.3bBreach boundary per criterion. One breakeven per criterion, computed on the kernel.Illustrative

Under which conditions does the decision hold?

The case fails only if exit yield exceeds 6.1% while rental growth stays below 0.5%. This region becomes the decision's validity envelope.

failsholds5.0%5.5%6.5%6.1%−1%0%1%2%3%0.5%Exit yield →Rental growth, % a yearbase case
Fig. 04.3cRobustness region. Ensemble search and scenario discovery, with the sampling design stated.Illustrative

Illustrative figures from a three-warehouse logistics acquisition.

Three more questions a committee asks

  • What is the distribution of outcomes?

    Monte Carlo with evidenced distributions and approved dependence. Needs a distribution.

    P10 to P90 levered IRR, reproducible from the recorded seed. Used only where distributions can be evidenced; the share of failing cases is never presented as a probability otherwise.

  • Which alternative is robust?

    Every alternative on one approved scenario set, compared by regret.

    Bidding up to the robust maximum never misses the hurdle by more than 40 basis points across the approved set. The set is fixed before comparison.

  • What information would change the decision?

    A decision-relevance screen, then value of information.

    A roof survey could move the maximum bid by €2.1m and is worth commissioning; a further rent review sits entirely inside the envelope and is not.

Criteria are policy, written as data.

A criterion states a test on computed results, the scenarios in which it must pass, and the policy or covenant it comes from. Written once, it serves four purposes, which is why it pays off before any solver exists.

A criterion, as governed data

DSCR ≥ 1.25x in every approved downside

Metric
DSCR
Comparator
≥ 1.25x
Scenario scope
Approved downside set
Kind
Hard
Provenance
Fund policy v4 · §3.2
Owner
Risk
One criterion definition
  • ReadinessIs the case within policy?
  • BreakevenWhat breaks first?
  • OptimisationWhich constraints bind?
  • MonitoringIs the decision still valid?
Fig. 04.3dOne definition of a criterion is read by readiness, breakeven analysis, optimisation and monitoring alike.

The same discipline covers the whole decision: a frame, alternatives including doing nothing, information, criteria, reasoning and a commitment. A missing element is a readiness finding. Rejected alternatives and lost bids are recorded too, so the institution can later learn from the choices it did not make.

04.4Optimisation

Searching for better options, within approved limits.

Solvers are commodities. What institutions lack is their objectives and constraints written down as approved data. With those in place, the system can do more than evaluate the option in front of it: it can search for a better one, inside explicit limits. The domain mathematics still lives only in the kernel.

Inputs

  • ObjectiveThe institution's own. Choosing it is an act of authority; Inversiq never supplies one.
  • ConstraintsDecision criteria as governed data: hurdles, covenants, limits, mandate tests.
  • PolicyExposure and concentration limits, evaluated by the decision point.
  • Decision statePer-decision kernel outputs as coefficients, each carrying the run that produced it.
Solver or inverse searchA driver over the one kernel. Deterministic and certifiable.

Reaches the committee

  • Binding constraints
  • How the solution moves with each
  • The price of robustness
  • Non-dominated alternatives
A governed recommendationStill a proposal. Adoption is authorised and records the alternatives rejected.
Fig. 04.4Approved inputs in, one solver over the kernel, and what reaches the committee. The recommendation is dashed because it is still only a proposal.
Decision level: inverse solving

Maximum bid €76.5m

The highest price at which every approved criterion holds in every approved scenario. Binding constraint: DSCR in the downside set.

Portfolio level: a solver

Four of nine pipeline deals

Chosen under a €150m equity budget and a 30% cap on any one city. Solutions return as proposals to the individual decisions.

LTV ≤ 55%DSCR ≥ 1.25xbindingcity capfeasible underevery criterionoptimumprice or allocation →
Fig. 04.4bA lone “optimal” answer never reaches a committee. Language models may draft a formulation; it is validated deterministically and approved by a named person before anything is solved.Illustrative

04.5Uncertainty

Uncertainty is state, not a footnote.

Uncertainty travels with each value, from the assumption through the calculation into the recommendation and the record. Because the record keeps the uncertainty as it stood, a later review can tell a bad call apart from an honest range that the outcome happened to fall outside.

  1. 1. Representation

    Plausible range

    Exit yield 5.00% to 6.25%, base 5.50%. Evidenced bounds; no probability is claimed.

  2. 2. Uncertainty type

    Irreducible

    No diligence can settle the market in year seven. The institution's own bias on exit yields can be reduced over time, by learning from outcomes.

  3. 3. Propagation

    Deterministic

    The range goes through the kernel as one experiment: a 400-cell exit yield by rental growth grid of pinned runs. No distribution is needed.

  4. 4. Implication

    The decision holds inside a region

    It fails only if exit yield exceeds 6.1% while rental growth stays below 0.5%. That region becomes the validity envelope, and the record keeps the range as it stood.

Fig. 04.5One value followed through, the exit yield, from how it is held to what it means for the decision. The region it ends in is what the decision is watched against after approval (06.5).Illustrative

What could reduce it

Reducible now by diligence
A roof survey, a legal review, a tenant covenant check. These go into the diligence plan.
Reducible over time by learning from outcomes
The institution's habit of setting exit yields too low. This goes to institutional learning (07.6).
Irreducible no one can know yet
The market at exit, in year seven. This is what scenarios and robustness analysis are for.

How it is held. As a point, a plausible range, a distribution where one can be evidenced, a set of scenarios, or an attributed confidence.

How it is carried forward. Ranges go through the kernel first, as breakevens and robustness regions. Probabilities come only with evidenced distributions.

Fluency is not calibration. A model's stated confidence is not treated as uncertainty; only calibrated estimators and evidenced ranges are.

04.6Multi-model systems

When models disagree, the disagreement is information.

Frontier language models, specialised extractors, forecasting models, the kernel, solvers and causal models all work on the same decision. One gateway and one registry govern them all. Where they disagree, the disagreement is kept, not averaged away.
Extraction model A

Break date 30 June 2028

lease L-17 p.14 · config v7

Extraction model B

Break date 30 June 2029

lease L-17 p.14 · config v2

Finding: both lineages kept

The analyst decides against clause 7.2 and the decision is recorded. The finding is acknowledged, never quietly “resolved”.

a silent average a majority vote deference to the senior model

Fig. 04.6An extraction disagreement. Two model proposals (dashed) become one finding that keeps both lineages.Illustrative

Two language models reviewing each other are not two controls.

Their failures correlate through shared training data, conventions and blind spots. Independence in the assurance sense comes from a different method, different data, or a person. More models increase coverage; they do not by themselves increase assurance.

Different method
Direct capitalisation as the independent check on a discounted cash flow value.
Different data
A second source, reconciled under source authority.
A person
A named reviewer whose challenge is attributed.
Chapter 05

Trust & authority

Where authority enters: challenge before approval, authority as data, one path into state.

  1. 05.1Challenge before approval
  2. 05.2Authority, policy, deliberation
  3. 05.3The authority graph
  4. 05.4The Commit Boundary

05.1Verification & Assurance

Challenge the case before approval.

Analysis that nobody attacks tends to fail all at once. So checks run where each thing is created, not in one review at the end, and every problem found stays attached to the decision. Before any approval, a computed readiness check reads them all. The system has to be able to say no.

  1. 01Intake

    Required documents present, source consistency, freshness

  2. 02Admission

    Type, unit and range; cross-source reconciliation; entity conflicts

  3. 03Computation

    Independent recalculation within a materiality-based tolerance, workbook reconciliation, kernel properties, invariants

  4. 04Reasoning

    Proposal contracts, adversarial challenge, hypothesis tests

  5. Readiness gate

    Before every authority transition

    Open findings, challenges, completeness, coverage, freshness and obligations. It can refuse; it never grants.

Findings accumulate on the decision. Snapshot-bound and materiality-weighted; answered by acknowledgement, waiver with rationale, escalation or challenge.

Fig. 05.1Four checkpoints, then one gate. Each check runs where its subject is created; every finding stays on the decision until the gate reads it.

Authority should see the contradiction before approval, not after closing.

Every material value is compared across every source that states it. Source authority decides which prevails; the gap itself becomes a finding with a computed materiality.

Tenant count as stated by each source
SourceStates
Rent roll v314 tenants
IC memo draft 613 tenants
Leasing model14 leases
Reconciled14 tenants
The rent roll prevails by source authority; the one-tenant gap becomes the finding.

Finding · contradiction · material

Tenant count differs across sources. The memo omits the Unit 7 tenant.

Affects NOI by 2.1%. It must be acknowledged, waived with a reason or escalated before the case is ready. A waiver never rewrites the result: a waived failure still reads as a failure.

Fig. 05.1bOne value, three sources, one finding.Illustrative

The readiness assessment: computed, not declared.

Readiness is calculated from the current state and the policy in force, every time someone asks for a decision, and the result goes into the record. Nobody ticks a box. Below, the acquisition before and after its open issues were dealt with.

Open findings by materiality
Fails: 1 material, unansweredthen Passes: 1 waived with rationale
Unanswered challenges
Fails: Void assumption, openthen Passes: Answered with letting evidence
Decision-quality chain
Passes: Complete
Scenario coverage required by policy
Passes: Complete
Freshness of relied-on state
Fails: Valuation 9 months old; policy allows 6then Passes: Updated valuation, 3 weeks old
Policy obligations
Fails: Environmental report pendingthen Passes: Report as a condition precedent

Not ready

Four checks fail against the policy in force, so a request for approval is refused.

Ready for authority

The committee may now be asked. That does not mean the answer is yes.

Fig. 05.1cThe same decision, before and after its issues were dealt with. Readiness can refuse an approval; it can never grant one.Illustrative

05.2View 04 · Control

One decision point.Three enforcement points.

Governance is three different questions, and most systems blur them into one approval button. Here each has its own engine. Their answers feed a single policy decision point, and every enforcement point asks it the same question, against the same state the approver saw.
AuthorityWho may?
The investment committee may approve acquisitions for the fund up to €50m. The grant comes from the fund documents.
PolicyUnder which conditions?
This acquisition needs an environmental report, and above a set size an independent review.
DeliberationHow do people decide together?
The committee approves four to one, with the dissent and a condition precedent recorded.

Governance plane

  • Authority

    Grants, delegations, limits

  • Policy

    Rules held as versioned data

  • Deliberation

    Reviews, challenges, dissent, votes

One decision

Readiness assessment · an input, never an enforcement point

Policy decision point

Permit Deny Permit with obligations Exception required

Deny by default · forbid overrides · fails closed

Evaluation log · every evaluation; those attached to commits enter the ledger

Enforcement points

  • Governed Agent Runtime

    Every tool call of every machine actor.

  • Commit Boundary

    Every change to authoritative state, including every authority transition.

  • Execution Boundary

    Every external action.

Fig. 05.2Authority, policy and deliberation inform one policy decision point, and the three enforcement points ask it before anything changes. Whichever point asks, the question and the answer are the same, and every evaluation is logged.

Where authority enters

Approval fails closed.Authority is never assumed.

Policy is explicit
Conditions are versioned data evaluated at a point in time, never prose in a memo that someone has to remember.
Exceptions are surfaced
A breach neither blocks silently nor passes quietly. It becomes an exception request that someone with authority has to answer.
Required review cannot be skipped
If policy requires a review, the transition is not permitted until that review exists, bound to the snapshot being decided.
Authority is named
Every authorisation names a person or a committee, the grant it acted under and the limits of that grant.
Approval fails closed
A missing grant, an expired delegation, a stale snapshot or an unreachable policy all give the same answer: not permitted.
Platform access is not authority
Administering the platform, managing users or configuring connectors confers no right to decide. Authority comes only from grants.

D-0417 · authority transition requestedAuthorise with conditions

Exception required
Actor
Investment committee, under grant G1
in force
Limit
€30m, within G1's limit of €50m
satisfied
Snapshot
The same state the committee reviewed
satisfied
Required review
Independent review, recorded on the snapshot
satisfied
Required evidence
Environmental report, fund policy v4
missing

Not permitted until the report is attached, or an exception is granted by an authority above G1.

Same request by a platform administrator: admin role, no authority grant

Deny
Fig. 05.2bOne authority transition, evaluated before it can commit. The grant is in force and the amount is within its limit, but the policy's required evidence is missing, so the answer is “exception required”. An administrator without a grant is not permitted at all.Illustrative

05.3The authority graph

Authority, held as data.

Institutions already write down who may decide what: in mandates, committee terms and delegation letters. The authority graph turns those documents into data. It is checked before every approval and every action, and the path that justified each one is recorded.
  1. Fund documentsSource instrument

  2. Grant G1 grants

    Scope
    Fund F
    Decision class
    Acquisitions and lease renewals
    Limit
    Up to €50m
    Conditions
    Quorum of four
    Validity
    Standing; recertified yearly
    Delegation
    Renewal authority delegable to the CIO
  3. Investment committeeBody with procedures
  4. delegates renewal authority, as G1 allows
  5. Chief investment officerPrincipal

  6. Delegation D1 narrows

    Scope
    Benelux assets
    Decision class
    Lease renewals
    Limit
    Under €500k
    Conditions
    Within fund policy v4
    Validity
    Twelve months
    Delegation
    Delegable once
  7. Asset manager MPrincipal holding D1
  8. approves, under D1

    A €300k Benelux lease renewal, approved

    Within D1's scope, class and limit, and inside its twelve months. The recorded path: fund documents → G1 → investment committee → CIO → D1 → M.

Fig. 05.3One authority chain, from the source instrument to the approval it justifies. Each link may narrow authority, never widen it.Illustrative

Revocation, before and after.

An agent's effective authority at every call is the intersection of its own grant and its principal's current authority.

Before: D1 in force

M may approve the renewal. M's agent a_19 may draft lender notices for decision 88 under D2, within what M may do.

After: D1 revoked

The revocation is recorded. M no longer holds renewal authority, so the agent's effective authority, the intersection of D2 and M's current authority, is now empty. Both lose it at the next evaluation. Renewals M approved earlier keep the recorded path that justified them at the time.

The rest of the model

Six dimensions
Every grant has a scope, a decision class, a limit, conditions, a validity and a delegability. Each link may narrow them, never widen them.
Bounded delegation
A delegation is bounded, attenuating, expiring, revocable, non-escalating, recorded as a decision, and voidable when found invalid.
Beyond a limit
A €60m acquisition exceeds G1's €50m limit. No one on this chain may approve it: the decision point returns “exception required” and routes it to a higher grant, with scope and expiry.
Segregation of duties
Any change that widens machine scope needs approval independent of the grantees.
Machine delegation
M's agent a_19 holds delegation D2: draft lender notices and tasks for decision 88, internal recipients only, for seven days, with no further delegation. It cannot approve the renewal. Material decision classes are never delegable to machine actors: a floor in Core that configuration cannot lower.

Recorded at authorisation

“Approved by the committee chair under fund mandate v3, clause 4.2. Quorum of four met; one dissent recorded.” Before the vote, anyone can ask who may approve. Afterwards, the record shows who did, and under what.

05.4The Commit Boundary

Generated is not authoritative.

There is one path by which anything becomes institutional state. An extracted rent, an AI-proposed range, an imported figure, a solver's answer and a committee's authorisation all cross it. The requirements vary with what changes and how much it matters. The boundary does not.
  1. 01ProposalExit yield range 5.00 to 6.25%, citing twelve comparables. Proposed by a model, against a snapshot of the decision.Carries its proposer, basis, lineage and an idempotency key.
  2. 02ValidationProposal contract: every citation in context, no computed numbers.
  3. 03AssuranceComparables checked for date and rate regime.
  4. 04Policy & authorityPermit with obligations.
  5. 05ObligationsMaterial: a named reviewer must adopt it.
Commit Boundary

Committed

Assumption adopted by a named reviewer, with one ledger event.

State change, ledger event and, at authority transitions, the sealed record: written together or not at all.

Refused

If a citation falls outside the context, or the proposal carries a number the model computed, the contract is violated and the proposal is refused. Without a named reviewer, it stays a proposal.

Fig. 05.4One crossing, end to end: a model proposes an exit-yield range. State change and ledger event are written together or not at all.Illustrative

What each kind of proposal needs to cross.

An extracted valuePassing rent €4.1m, from lease L-17 cl. 4.1
Type, unit and range; the clause locator resolves; reconciled with rent roll v3 and the memorandum. A named analyst accepts; acceptances are sampled for review quality.
Commits as: Fact accepted
An AI-proposed rangeExit yield 5.00 to 6.25%, twelve comparables
The proposal contract; comparables checked for date and rate regime. Material, so a named reviewer must adopt it.
Commits as: Assumption adopted
An imported figureValuation €71.8m, valid from 30 June, from the valuer's system
Source registered, content hash, backdated valid time. A conflict with an accepted value becomes a finding with materiality. No obligation to record it.
Commits as: New version; dependent decisions flagged
A solver's answerMaximum bid €76.5m; binding constraint DSCR in the downside set
Solution status and certificate; kernel runs referenced; re-run against the approved scenario set. Adoption by named authority; rejected alternatives recorded.
Commits as: Recommendation adopted
A committee's authorisationAuthorise with conditions, against the current snapshot
The snapshot still matches the relied-on state; readiness recomputed; an authority path found. Quorum of four, independent review, dissent window.
Commits as: Authorised; Decision Record R-17 sealed
Fig. 05.4bThe requirements vary with what changes and how much it matters. The boundary does not.Illustrative

Made against a snapshot

Every proposal names the decision, the ledger sequence and a hash of the state it relied on. If that state moved materially, the proposal is re-evaluated, and approvals gathered for it lapse.

Idempotent

A repeated commit with the same key and content replays the original result; different content under the same key is refused.

A verdict is not permission to act

Authorising an acquisition sends nothing. Each consequential action is separately checked at the Execution Boundary against the authorised terms.

Chapter 06

Action

How approved decisions change the world, and why they stay active afterwards.

  1. 06.1From preparing to acting
  2. 06.2Governed Agent Runtime
  3. 06.3The Execution Boundary
  4. 06.4Actions as contracts
  5. 06.5Decisions stay alive

06.1Controlled action

Preparing is not proposing.Approving is not acting.

Agents can do a great deal of useful work before anyone decides anything. The architecture keeps apart five things that are easy to blur: preparing work, recommending an action, proposing it, authorising it, and executing what was authorised. Each has a different actor and a different limit.

  1. 01Prepare

    Gather data, extract terms, run analyses, draft the brief.

    Who
    Agents and analysts
    Produces
    Working state
    Never
    Changes authoritative state

  2. 02Recommend

    Say which option the analysis favours, and why.

    Who
    Agents, models and analysts
    Produces
    A recommendation with its basis
    Never
    Commits the institution

  3. 03Propose

    Submit one specific change or action for decision, against a snapshot.

    Who
    Any actor with a propose tool
    Produces
    A proposal or an action request
    Never
    Approves its own proposal
  4. Commit Boundary · authority transition

    04Authorise

    Commit the institution, with conditions where policy requires them.

    Who
    Named people, under a grant
    Produces
    An authorised decision, sealed
    Never
    Sends anything by itself
  5. Execution Boundary · per action

    05Execute

    Carry out an authorised action once, and confirm its effect.

    Who
    Controlled Execution
    Produces
    One effect, confirmed
    Never
    Acts beyond the authorised terms

One outbound action that requires approval

  1. Prepared

    Agent a_19 drafts the notice to lender B

  2. Requested

    Action request: send notice, under its contract

  3. Held

    Waits for a named approver other than the requester

  4. Checked

    Execution Boundary: authorised, current, within terms

  5. Sent once

    Dispatched through the outbox; confirmed on effect

The approval licenses this action on these terms. If the relied-on state moves before dispatch, the Execution Boundary refuses it and nothing is sent. Illustrative

Fig. 06.1Five rungs, from preparation to effect. Machine actors work on the first three. Authority is a separate transition through the Commit Boundary, and every action that follows is checked again, on its own, at the Execution Boundary.

06.2The Governed Agent Runtime

Machine actors get no shortcut around the architecture.

Agents are used only where the path cannot be laid out in advance, and even then they work through one runtime. It gives each machine actor its own identity, a delegated slice of authority, a fixed set of tools, a budget and a record of everything it did.

Intelligence decides what it would like to do. Authority decides what it may do. The runtime decides how it is permitted to do it.

Governed Agent Runtime
  1. 1

    Observe

    A monitor, event or request opens a run under a short-lived machine identity bound to a delegation.

  2. 2

    Plan

    A privileged model turns the trusted request into a plan of tool calls. Untrusted content never shapes the plan.

  3. 3

    Retrieve

    Read tools reach the State Core as authorised. Documents, web pages and emails are read in quarantine and return typed data.

  4. 4

    Invoke typed tools

    Read, compute, propose or request action. Every call is evaluated by the policy decision point against the agent's effective authority.

    Authority

    Authority checked on every call

  5. 5

    Propose

    Propose tools create proposals at the Commit Boundary. No tool writes authoritative state.

    Commit Boundary

    The only way state is written

  6. 6

    Validate

    Proposals meet the typed contract: closed schemas, cited support, quoted numbers. A violation is a refusal.

    Validation

    Validation against the contract

  7. 7

    Request authority

    Obligations route to named people. Budgets and uncertainty escalate to them too.

    Authority

    Named people decide

  8. 8

    Execute governed action

    Request-action tools reach the Execution Boundary, which checks the action against authorised terms.

    Execution Boundary

    The only way action is taken

  9. 9

    Record

    Every step lands in the durable run journal as it happens: recoverable after a crash, never repeated on replay.

    Recorded

    Durable run journal

  10. Back to Observe. Every step is recorded in the run journal.
Fig. 06.2The run loop inside the runtime. Proposals meet the Commit Boundary, actions meet the Execution Boundary, and every step is recorded in the run journal.

Every machine actor has

Identity
Its own short-lived identity, tied to the person and delegation it acts for. Never a borrowed login.
Authority
Never more than its grant, and never more than its principal may do right now.
Typed tools
Read, compute, propose or request action, each with a scope and a cost.
Budgets and a halt switch
Limits on time, cost and steps, with escalation to named people. Halting is always allowed; resuming needs authority.
A durable record
A run journal of its plan, calls, evidence, proposals and results.

Four tool types, and nothing else

The four tool types, an example of each, and what each reaches
Readread_decision_stateState Core, as authorised
Computerun_kernelThe deterministic kernel
Proposelink_evidenceCommit Boundary
Request actionrequest_lender_noticeExecution Boundary

Because no tool writes authoritative state, a prompt injection cannot write state or act directly. A malicious clause in a data-room PDF cannot make an agent email a counterparty.

06.3The Execution Boundary

An approved decision is not permission to act.

Approving an acquisition sends nothing. Each action that follows (a letter of intent, a deposit, a notice to a lender) is checked on its own at the moment it would leave, and refused unless it is authorised, current and within its terms. The Execution Boundary is the only way out.

Valuation corrected: Refused. Nothing is sent. Check 2 · State is current.

Refused. Nothing is sent.

Check 2 · State is current

The price assumed a valuation that has since been corrected, outside the record's knowledge horizon. The reasons are recorded and the decision moves to reconsideration. The approval itself is unchanged; it simply does not license this action any more.

Action request, by contract

Submit deposit instruction

€3.8m to the institution's treasury

submit_instruction v2

Irreversible class: human-authorised, signed, segregated.

Execution Boundary · nine checks
  1. 1Authorised decision existsfor this action class and scope
  2. 2State is currentnothing relied on moved materially since authorisation
  3. 3Conditions satisfiedno condition precedent outstanding
  4. 4Terms matchprice, amount, counterparty, date
  5. 5Actor authoritythe executor may do this, now
  6. 6Segregation of dutiesproposer, approver, executor distinct
  7. 7Target preconditionthe external record did not change underneath
  8. 8Idempotencynot already executed or executing
  9. 9Reversibility plana compensation exists where one is possible
Beyond the boundary: nothing
  1. Outboxwith its ledger event, one transaction
  2. Adapteridempotency key carried to the target
  3. Treasury systemkeeps its own release authority and dual control
  4. Effect observedconfirmation linked to the action; complete
Fig. 06.3One deposit instruction and the nine checks it must pass. The approval is the same in all three scenarios; only whether this action may leave changes.Illustrative

Financial instructions go to the institution's own treasury or banking system, which keeps its release authority and dual control. Inversiq is never the last control on a payment.

06.4Controlled execution

Every action is a declared contract.

An action that leaves the institution is defined in advance: what it needs, who must authorise it, whether it can be undone, what it changes and how its effect will be confirmed. Agents and interfaces ask for an action by its contract. They never improvise their own calls to outside systems.

issue_loi(asset, price, conditions)

Class
Preparatory; withdrawable within 48 hours
Preconditions
Authorised decision; conditions precedent met
Required authority
Committee approval reference; signatory
Side effects
Counterparty notified; exclusivity requested
Confirmation
Counterparty receipt, linked to the action
Compensation
Withdrawal notice, through the same boundary
Audit shape
Hashed into the Decision Record
Fig. 06.4One action contract. Illustrative.

Control scales with consequence.

Every action belongs to a class, and the class sets the control. Delegated agent action is limited to pre-authorised, low-risk, reversible classes, with evaluation evidence and reliable escalation.

  1. 1AdvisoryMachine actors may execute under policy, to internal principals onlyNotifications and summaries to internal principals
  2. 2PreparatoryMachine actors may execute; the human owns the resultDraft documents, review tasks and deadlines, reservations
  3. 3ReversiblePolicy-dependent; may be pre-authorisedSystem write-back, such as an approved capex budget sent to the asset management system
  4. 4CompensableNamed authority; a compensation plan is requiredAPI actions and multi-step processes with partner or counterparty systems
  5. 5Irreversible or materialAlways human-authorised, signed and segregated; never pre-authorised; never delegated to machine actorsLetters of intent, contracts, financial instructions, transaction requests

Execution semantics

  1. Outbox, not direct calls

    The action, its ledger event and its outbox entry are written in one transaction; a dispatcher delivers it.

  2. Compare-and-set transitions

    Proposed, authorised, dispatched, confirmed, failed, compensated: concurrent executors cannot both act.

  3. Recovery

    Actions stuck in dispatch are re-queried at the target, retried idempotently or escalated. Never silently retried as new actions.

  4. Compensation is an action

    Reversing a step is itself authorised, through the same boundary, and linked to what it compensates.

  5. Confirmation closes the loop

    An action is complete when its effect is observed in the target system, not when the call returns.

06.5Monitoring and active decisions

Decisions stay alive.

Two years after the vote, the anchor tenant of Warehouse A is downgraded. The approval was sound, but a condition it relied on no longer holds. In most institutions nobody connects the two. Here the decision notices, and goes back to the people with authority over it.
  1. 1 · Two years inThe anchor tenant is downgradedIts rating falls from BBB− to BB+. The observation arrives from a rating feed and is recorded against the tenant.
  2. 2 · The monitorA monitor crosses its limitThe rating monitor, armed at approval, requires investment grade. It fires. The yield and DSCR monitors moved too, but stayed inside.
  3. 3 · ReconsiderationThe decision goes back to authorityThe analysis reruns deterministically, under pinned versions, with the downgraded tenant. An agent may prepare the brief; only the committee can reaffirm, amend, supersede or revoke.
  4. 4 · The outcomeA new decision recordReaffirmed, with a new covenant condition. The new record references R-17, which stays exactly as it was.
Fig. 06.5One event, from the outside world back to authority. The monitor only escalates; people change the decision, and the change is recorded as a new decision.Illustrative

Validity envelope · approved with the decision

The conditions under which the decision stays justified are worked out before the vote, from the breakevens and the robustness region in 04.3, and approved with it. Each one gets a monitor.

A change is material only when it crosses a limit or changes a criterion's outcome. Smaller moves, like the yield index going from 5.4% to 5.5%, are recorded and added up, so slow drift is still seen.

Prime logistics yield indexLimit: below 5.9%
At authorisation 5.4%two years in 5.5%
Anchor tenant ratingLimit: investment grade
At authorisation BBB−two years in BB+, downgraded
Quarterly DSCRLimit: at least 1.25x
At authorisation 1.41xtwo years in 1.31x

Two years in, the decision is outside its envelope: reconsideration required.

Fig. 06.5bThe three monitors armed at approval, and where they stood two years in. Only the rating crossed its limit, so only the rating reopened the decision.Illustrative

  • Monitors escalate; they never act

    A trigger reopens the decision or raises a finding. Nothing adjusts a signed decision automatically.

  • Materiality filters noise

    A change matters when it moves the decision across its envelope. Small drifts are added up, so a slow slide is still seen.

  • Every monitor has an owner

    A fired monitor puts the institution on notice. If nobody acknowledges it, it escalates, ultimately to the second line.

07.1The Decision Record

Not what the software did.Why the institution acted.

A Decision Record is written at the moment of approval, in the same step: everything the decision relied on, who approved it, and under which authority. If it is not written then, it cannot be reconstructed later.

Decision Record

R-17 · Acquire logistics portfolio A

Authorised with conditions · sealed

Basis

Source & context
Rent roll v3, fourteen leases, the information memorandum; knowledge horizon 12 Sep, 17:00
7f3a…c21 +15
Assumptions
Exit yield 5.50%, plausible range 5.00 to 6.25%, with standing and origin
exit_yield v2

Execution

Model & run
Deterministic kernel, methodology v7, pinned
r_812 · 91c…4e
Calculation
Levered IRR 8.9% in base; the criterion of at least 8% holds
by reference
Validation
Reconciled across sources: fourteen tenants; the rent roll prevails
recon v3

Challenge & authority

Exceptions
Two findings waived, each with its rationale
f_31, f_34
Review
Independent review; the void-period challenge answered
snapshot s_47
Authority
Investment committee under grant G1; four to one, dissent recorded
G1 · policy v4
Rationale
The return holds across the plausible exit-yield range; a condition precedent covers the void risk
chair

Consequence

Outcome
Expected year-two NOI €4.3m ± 5%, sealed now; what is observed is judged against it later
monitors · 3
Sealed 12 Sep, 17:42 · signed by the chair · sha256 4be…a1Written in the same transaction as the authorisation
Fig. 07.1Decision Record R-17 as a system object: ten fields, each bound to the exact state it relied on, sealed in the same step as the authorisation. Behind it, the same day's audit log: what the software did, not why the institution acted.Illustrative

An audit log: what happened

  • 09:14document.uploaded rent_roll_v3.xlsx
  • 09:18extraction.completed 412 values
  • 10:02assumption.updated exit_yield
  • 10:05run.completed r_812
  • 11:40finding.resolved gla_conflict
  • 14:05decision.recorded approve

Necessary, and not sufficient: it says what the software did, not on what basis the institution concluded, or under whose authority.

Not another document. A reconstructable institutional decision, bound to the state it relied on.

  • Sealed

    Hash-bound over its contents; any later change to what it references is detectable.

  • Immutable

    Superseded by later records, never edited. Errata and amendments are new records.

  • Written at the time

    Inside the same transaction as the authority transition: no authorisation exists without its record.

  • Attestable

    Exportable as a signed attestation for lenders, co-investors, auditors and supervisors.

The record is cheap now and irreplaceable later. Memory is expensive now and cheap later.

The write side and the read side
Decision RecordInstitutional memory
When it must existFrom the first governed decisionOnce enough records exist to recall from
Cost of delayUnbounded: unrecorded reliance cannot be reconstructedSmall: memory can be built over records later

07.2The Decision Graph

No decision stands alone.

Decisions share assumptions, inherit constraints, draw on the same limits and involve the same counterparties. The decision graph holds those links, so a change in one place finds every decision it touches. Pick a change below and follow it.

Three live decisions rest on the 5.5% exit yield: the acquisition of A, its financing and pipeline deal D. Revise the assumption and all three are flagged, each with the size of the impact.

Three live decisions rest on the 5.5% exit yield: the acquisition of A, its financing and pipeline deal D. Revise the assumption and all three are flagged, each with the size of the impact.

Assumption · changedExit yield 5.5%
  1. assumesAcquire Warehouse A · 2026
  2. assumesFinance Warehouse A
  3. assumesAcquire Warehouse D · pipeline

The graph holds five decisions: Acquire Warehouse K · 2024; Acquire Warehouse A · 2026; Finance Warehouse A; Capex plan, Warehouse A; Acquire Warehouse D · pipeline.

Fig. 07.2The change and every decision it reaches. Recorded and derived relations can flag or stop a decision; a similarity between decisions is only inferred, and never can.All objects illustrative

The same graph also answers

  • Which decisions used this policy version?
  • Which downstream decisions inherit this constraint?
  • Which decisions were authorised under a delegation since revoked?
  • Which previous decisions resemble this one? (inferred, never a gate)

07.3Knowledge and decisions

Two graphs, joined at the entities.

One graph describes the world as the institution understands it: assets, leases, tenants, lenders, markets. The other describes what the institution has committed to, and why. They meet at the same entities, which is how the tenant question in 07.2 can be answered at all.

Knowledge graph · the world

  • Seller Sorganisation
  • NL logisticsmarket
  • Warehouse Aasset
  • Lease L-17contract
  • Lender Borganisation
  • Tenant group Torganisation

Decision graph · the commitments

  • Acquire Adecision
  • Exit yield 5.5%assumption
  • Fund policy v4policy
  • Finance Adecision
  • Year-2 NOIoutcome

Joined at the entities: Acquire A about Warehouse A; Acquire A relies on Lease L-17; Acquire A exposed to Tenant group T; Finance A exposed to Lender B; Exit yield 5.5% about NL logistics.

Fig. 07.3The world and the commitments, joined at shared entities. Exposure to a tenant, a lender or a market is one query across both.Illustrative

07.4Outcomes

What we expected, against what happened.

Outcomes are first-class objects, not a stage at the end of a pipeline. Every authorised decision seals its expectations, in numbers, in the record. Outcomes are later compared with what was expected, not with what people remember.
  • Net operating income€4.30m ± 5% → €3.91mgap −9%
  • Occupancyat least 95% → 96%gap +1 pt
  • Capexhigher is adverse€2.4m → €3.1mgap +29%
  • Yield on cost6.6% → 6.2%gap −40 bp
Expectation band
The range sealed in the record at authorisation. A single tick where only a value was sealed.
Observed
The value observed in the window, from the systems of record.
Gap
Observed minus expected. The scale shows it as a percentage of the expected value, from −30% to +30%.
Adverse
Outside the sealed range, in the direction that hurts the decision.
Fig. 07.4Warehouse A: the expectation sealed in R-17 at authorisation, against what was observed in the year-2 window. Every gap is measured against the sealed expectation, never a revised one.Illustrative

Bad assumptions, bad luck or bad execution?

Because computation is deterministic and pinned, the decision-time model can be re-run with realised inputs, driver by driver. It answers “had we known, what would the model have said?”, not “did our decision cause this?”.

Share of the shortfall, by driver

~70%~20%
  • Exit yield, ~70%calibration failure: outside its recorded range
  • Void period, ~20%variance: inside its recorded range
  • Interaction, ~10%reported separately: non-additive residual

Rental growth was within its range. Drivers are also tagged exogenous or management-controlled, so decision quality is not blamed for execution, and the reverse.

Fig. 07.4bReplay attribution of the return shortfall: each driver's share of the gap, and whether it stayed inside its recorded range.Illustrative

Windows

Outcomes arrive over years; windows make partial outcomes usable before exit.

Declines are decisions

Where market data allows, the option not taken is observed too, so learning is not survivorship.

Selection

Won deals are where estimates were highest. Every bid is recorded so the winner's curse can be corrected.

Never overwritten

A revised figure is a new version with a reason from a closed vocabulary.

Without outcomes, the system records history. With outcomes, it can learn.

07.5Institutional memory

From document retrieval to institutional memory.

Retrieval finds documents that mention something. Institutional memory recalls decisions: what was known, assumed and disputed, who decided under which authority, what was done, and what turned out to be wrong. It is built from records and outcomes, not from text.

Intelligence is replaceable. Institutional memory is not.

Generic AI memory · replaceable

  1. Model generation 1replaced
  2. Generation 2replaced
  3. Generation 3replaced
  4. Generation 4in use, via the gateway

Chat history, session context and vector indexes: useful, and gone with the session or the model.

Institutional decision memory · kept

First governed decisionEvery model change, kept across

What accumulates

  1. 01Decision historyEvery decision, with its basis and its authority
  2. 02Assumption historyWhat was assumed, by whom, and how far off it was
  3. 03Exception patternsWhich policies are waived, where and why
  4. 04Authority historyWho decided what, under which grant
  5. 05Expected outcomesThe case each decision was approved on
  6. 06Realised outcomesWhat happened, against that case
  7. 07CalibrationHow expectations compare with results, over time
Fig. 07.5Generic AI memory belongs to a session, a vendor or a model, and goes when the model is replaced. Institutional decision memory belongs to the institution: it is written by governed decisions, survives every model change and only grows.

“A new Spain logistics acquisition. Have we made a decision like this before?”

What comes back
Without institutional memoryFour documents that mention Spain logistics: a market update, an IC memo on Valencia, a broker pitch, a board pack.
With institutional memoryTwo prior decisions: Acquire Valencia DC (2027), similar by sub-market, lease profile and rate regime; Acquire Zaragoza portfolio (2028), similar by tenant sector and WAULT.
What was assumed
Without institutional memoryWhatever the memo text happens to say, without its range or its standing.
With institutional memoryValencia: exit yield 5.25%, range 5.0 to 5.75%. Zaragoza: void period of 6 months.
Who disagreed
Without institutional memoryNot recorded.
With institutional memoryValencia: the risk member, on refinancing at maturity, with 60% confidence. Zaragoza: no dissent recorded.
What happened
Without institutional memoryNot connected to the documents.
With institutional memoryValencia: exit yield realised at 5.9%, outside the range. Zaragoza: void of 14 months, inside the range.
What was wrong
Without institutional memoryNothing about what was assumed, who disagreed, or what happened.
With institutional memoryValencia: the dissent was right; exit yield was underestimated. Zaragoza: variance, not a bad assumption.
Fig. 07.5bThe same question, without institutional memory and with it. Each recalled decision opens to its original state and knowledge horizon, its alternatives, its authority and its execution. Similarity is an inferred relation, its basis always shown.Illustrative

Three kinds of memory, three kinds of governance

  • EpisodicDecision Records, the ledger, outcomesImmutable; access follows authority over the decisions
  • SemanticThe knowledge graph, facts, market evidence, comparablesCommitted through the boundary; versioned
  • ProceduralMethodology, policies, rules, criteria, action contractsChanged only by meta-decision; never by agents or learning directly

The outside view

“Across 23 comparable acquisitions, year-three NOI averaged 6% below underwriting.”

Reference-class forecasting turns recall into calibration. The class is fixed before the new figures are visible, and includes lost bids where their outcomes are observable. Relevant prior decisions, dissents and outcomes surface in a new decision's context automatically, within access rights. Illustrative.

07.6Institutional learning

Learning proposes.Authority disposes.

Learning is where the architecture compounds, and where it could do the most damage. A pattern in past decisions must never quietly become today's rule. So every lesson arrives as a proposal with its evidence, and a named person adopts or rejects it. Earlier decisions are still judged by the rules in force when they were taken.
  1. 1 · Recorded expectationExit yield assumed at 5.25%Warehouse K, acquired in 2024. The assumption and its range were sealed in K's Decision Record at approval.Sealed at approval
  2. 2 · Observed outcomeRealised at 5.65%, 40 bp higherNot a one-off: across nine secondary-logistics exits, yields came in 35 bp above what was assumed, on average.Measured against the record, never memory
  3. 3 · Proposed adjustmentWiden the exit-yield range by 25 bpLearning proposes the change for secondary logistics, with the nine outcomes attached as evidence. Nothing changes yet.A proposal, like any other
  4. 4 · Named approvalThe head of research approves itMethodology v8 applies to new decisions from here on. K and A keep the methodology they relied on.The one step that changes anything
Fig. 07.6One learning signal, end to end. Only the last step changes anything; everything before it is a record or a proposal, and the records it learned from stay as they were.Illustrative

Single-loop

Recalibrate an estimator; update a plausible range from new comparables; flag a recurring finding.

May be proposed automatically; adopted under the relevant owner's authority.

Double-loop

Change a policy threshold, a materiality tier, a methodology default, a criterion or an objective.

A meta-decision with its own record, authority and version history. No salami drift: when small recalibrations add up past a threshold since the last meta-decision, the change escalates here.

Learned patterns never silently become

policyassumptionsrulesauthority

What the institution can learn · illustrative

Kinds of institutional learning, with an illustrative example of each
Assumption calibrationExit yields in secondary logistics were set 35 bp too low on average: the signal traced above, tracked as an error distribution over time.
Forecast scoringScored with proper scoring rules, committee estimates of hitting the hurdle were overconfident by 15 points.
Override performanceAnalyst overrides of AI rent proposals improved accuracy; overrides of cost estimates did not.
Dissent performanceDissents citing refinancing risk were vindicated in three of four cases.
Recurring exceptionsThe environmental report was waived in 11 of 14 small industrial deals.
Policy effectivenessDecisions under the stricter DSCR floor breached less, with confounders listed.

Faster learners drift faster. Routing every signal through a governed decision is what makes stronger learning safe to use.

  • No learning without lineage. Every signal traces to the records and outcomes behind it.
  • Tenant-scoped by default. An institution's history teaches that institution.
  • Protect exploration. Declined deals and rejected alternatives are observed too.
  • Measure process, not only results. Noisy outcomes cannot judge one decision.

07.7Machine learning roles

Machine learning is a technique, not a layer.

Machine learning appears in specific roles across many engines. Each role has its own data prerequisites, and each produces proposals. Every learned model is registered, validated in proportion to its use, calibrated, scoped and monitored. It can inform evaluation. It never confers authority.

Three representative roles

  • Knowledge & Semantics · Understanding

    Entity matching

    What it does
    Scores whether two references are the same asset, organisation, person or contract, in three zones: match, review, discard. ‘DHL Supply Chain (Netherlands) BV’ in a lease and ‘DHL’ in a broker memo resolve to one tenant.
    What it needs
    Labelled merges.
    The rule
    A merge is a proposal. Material merges are reviewable and reversible.

  • Prediction · Analysis

    Calibrated forecasting

    What it does
    Rent and yield estimates with calibrated intervals, from a registered estimator.
    What it needs
    Market series and outcomes.
    The rule
    A source of assumptions, not a layer that decides. Its output enters as a proposed estimate and is scored against outcomes.

  • Observation · Feedback

    Model drift detection

    What it does
    Triggers a monitor when an estimator loses calibration against what actually happened.
    What it needs
    Estimator outputs and outcomes.
    The rule
    Monitors escalate; they never act. A trigger opens reconsideration or raises a finding.

Also used in:Extraction confidence (Data, Reasoning) Graph intelligence (Knowledge, Memory) Comparable ranking (Prediction) Survival and timing (Prediction) Scenario priors (Decision Science) Anomaly scoring (Assurance) Review prioritisation (Orchestration) Assumption calibration (Learning) Outcome and pattern detection (Learning) Policy effectiveness (Learning) Decision similarity (Memory)

Every learned model is a registered model. It is used by many engines, it is never a layer, and it never confers authority.

Most roles begin as statistics over the institution's own history. A trained model earns its place only when it beats a simple baseline and a frontier model on decision-relevant error, the data rights allow it, enough outcomes exist, and the target is stable.

Roles that learn the institution's own judgement and outcomes, such as calibration, comparable ranking, anomaly baselines and decision similarity, survive much better frontier models. Generic extraction improves with them; its calibration on the institution's documents remains.

07.8Cross-decision intelligence

Many decisions, one institution.

Once decisions share entities, assumptions, limits and outcomes, the institution can ask questions no single decision can answer: where it is concentrated, which assumptions it is quietly betting on everywhere, and how one decision constrains the next.

Decisions

  • Acquire A
  • Acquire B
  • Finance A
  • Hold C
  • Acquire Dpipeline

What they share

  • Tenant group Tin three decisions
  • 3% rental growth, Dutch logisticsassumed in twelve
  • Lender Bin four loans
  • Benelux logistics equity capset by the annual allocation
Portfolio state

Derived from records and system feeds, reconciled with systems of record.

Fig. 07.8Portfolio state is derived from individual decisions and what they share. It is reconciled with systems of record, never a competing book of record.Illustrative

What becomes answerable

  1. Exposure and concentration

    The tenant limit from 07.2: approving D would take exposure to tenant group T above 15%. Limits are policy, so they apply to decisions still in the pipeline too.

  2. Shared assumption analysis

    Twelve active decisions assume 3% rental growth in Dutch logistics. Correlated assumptions are hidden systemic risk; one revision reaches all of them.

  3. Portfolio stress testing

    Under a 150 bp rate shock, replayed deterministically decision by decision, four loans breach interest cover together, all with Lender B.

  4. Decision interaction

    The annual allocation decision caps Benelux logistics equity; each acquisition consumes it. Inherited constraints are evaluated by the decision point.

  5. Allocation optimisation

    Choosing combinations under budgets and limits. Solutions return as proposals to the individual decisions, never adopted automatically.

Chapter 08

Platform

How one architecture carries more decisions, more institutions and other domains.

  1. 08.1Platform view
  2. 08.2Generalisation
  3. 08.3Reconstructability

08.1View 06 · Platform

One Core.Domains above it. Each institution its own.

What every decision domain shares lives in Core. What varies lives in domain runtimes, institution configuration and extensions. Each layer uses the one beneath it only through contracts, and nothing above Core can bypass a boundary. A code path that branches on a customer's name is a defect.

Interfaces

Workspace Console SDK API

The Workspace for decision teams, the Console for configuration, and an SDK and API for engineers and agents, including standard agent tool protocols.

Every interface uses the same contracts, the same authority and the same recording. None is a side door.

Changes as the product evolves · Owned by Inversiq

Decision instances

One per decision, per institution

The state itself: every decision, its basis, analysis, authority, actions and outcomes.

It belongs to the institution and leaves with it, in an open, verifiable format.

Changes every day · Owned by the institution

Institution configuration

Institution A Institution B Institution Ceach its own methodology, policy and authority

Methodology versions, policies and criteria, the authority graph, committee procedures, thresholds and materiality, templates, source ranks, mappings and integrations.

Configuration is data interpreted by Core, never code run per tenant. A decision is judged against the configuration in force when it was taken.

Changes when the institution's rules change, as meta-decisions · Owned by the institution

Domain runtime

Commercial real estate

the first proving domain

Illustrative pattern

Another domain runtime

a pattern, not a product

Each runtime: ontology and vocabulary, schemas, kernel calculation models, rule catalogs, decision classes, measure definitions, action contracts for the domain's systems, evaluation data.

Everything that must change when the decision domain changes completely, and as little else as possible.

Changes when a domain is added or deepened · Owned by Inversiq, and eventually partners

Inversiq Core

State Core Commit Boundary Execution Boundary Agent Runtime Policy decision point Engine mechanisms Rails Core services

Every write through the two boundaries; every authority through the decision point; every value in an envelope; every authorisation sealed. A component that needs any of this relaxed is refused.

Changes when the architecture moves · Owned by Inversiq

Extensions

  • Calculations
  • Models
  • Connectors
  • Tools
  • Action adapters
  • Subscribers
  • Ontology

attach through typed contracts

Typed, sandboxed, versioned contracts that inherit every boundary. Extensions never touch the State Core directly.

Calculation modules, registered models, connectors, tools, action adapters, event subscribers and bounded ontology extensions.

Changes when a capability is added without changing Core · Owned by the institution or a partner

Fig. 08.1Each layer with the rule it keeps, what it holds and who owns it. Extensions attach through typed contracts. The second domain runtime is an illustrative pattern, not a product.

Core also holds two floors no configuration can lower: the decision and action classes never delegable to machine actors, and need-to-know barriers inside an institution.

08.2Generalisation

A general architecture, a focused beginning.

Commercial real estate is where Inversiq starts. The nearest growth is the next decision about the same assets, inside an institution already served. Beyond that, the architecture is not tied to real estate: the same decision pattern runs through other institutional domains.

1 · Same institutionMore governed decisions about the same assets.

  1. 1 · AcquisitionAcquire Warehouse AWhere it starts
  2. 2 · FinancingFinance Warehouse ASame asset, lender and NOI assumption
  3. 3 · DevelopmentCapex plan, Warehouse ASame asset, inherits the LTV limit
  4. 4 · Asset managementRenew lease L-17Same tenant, same authority graph

Shared by all four

The same entities and data The same authority graph The same records and State Core

New for each

Decision logic and criteria Kernel models for the new class Who must approve

Fig. 08.2The nearest growth path: new kinds of decision about assets the institution already holds. Each needs new decision logic; everything drawn beneath them is already there.Illustrative

2 · Same architectureBeyond commercial real estate.

Same architecture. Different consequential decisions.

Commercial real estate is the first proving domain, not the ceiling. The same pattern appears wherever an institution decides with data, analysis, exact calculation, policy and a named authority.

  1. 01 · the proving domainCommercial real estateAcquisition and underwritingAuthority: Investment committee
  2. 02Private creditCredit underwriting and the credit memoAuthority: Credit committee
  3. 03InsuranceUnderwriting and referralAuthority: Underwriting authority
  4. 04Infrastructure and project financeThe investment or financing caseAuthority: Investment or credit committee
  5. 05Energy and utilitiesCapital project and asset investmentAuthority: Capital or investment committee
  6. 06DefenceProgramme and procurement decisionsAuthority: The defined programme or procurement authority
  7. 07Healthcare and life sciencesPortfolio, investment and development decisionsAuthority: Investment or governance committee
  8. 08Industrial capital allocationMajor capital allocation and investmentAuthority: Executive or capital committee

Shared by all eight

  1. Data
  2. Analysis
  3. Deterministic calculation
  4. Policy
  5. Authority
  6. Decision record
Fig. 08.2bFrom one domain to the next, the decision and the authority change; the band beneath them does not. Its six steps simplify the architecture on this page for comparison, and do not replace it.Illustrative future domains · not current product scope

The domain changes. The governed decision architecture does not.

What has to change when the domain does.

Take two of those patterns and compare them with commercial real estate layer by layer. The domain runtime is replaced almost entirely; Core stays untouched. Other domains appear here only as architectural patterns, not current product scope.

  • CRE acquisition

    The first proving domain

    Ontology
    Asset · unit · lease · tenant · covenant
    Kernel models
    DCF · debt sizing · exit value
    Criteria
    IRR hurdle · DSCR · LTV
    Authority graph
    Investment committee · fund mandates

  • Project finance

    Illustrative pattern

    Ontology
    Project · offtake · milestone · tranche
    Kernel models
    Construction and operating cash flows · sculpting
    Criteria
    DSCR · LLCR · cover ratios
    Authority graph
    Credit committee · delegated lending authority

  • Insurance underwriting

    Illustrative pattern

    Ontology
    Risk · exposure · limit · treaty
    Kernel models
    Pricing · accumulation
    Criteria
    Loss ratio · capacity · accumulation limits
    Authority graph
    Underwriting authority limits
  • Inversiq Core, the same in all three: State Core · Commit and Execution Boundaries · ledger · records · validity envelope · monitors · learning route · Agent Runtime.
Fig. 08.2cRead across a row to see what each domain needs. Everything above the Core row changes; the Core row does not.Other domains: illustrative patterns
Same decision class
Core: Shared unchanged. Domain runtime: Shared unchanged. Configuration: Configured.
Adjacent class
Core: Shared unchanged. Domain runtime: Mostly shared, extended. Configuration: Configured.
Adjacent domain
Core: Shared unchanged. Domain runtime: Largely domain-specific. Configuration: Configured.
Distant domain
Core: Shared unchanged. Domain runtime: Largely domain-specific. Configuration: Configured.
Fig. 08.2dThe thesis, stated so it can fail: what each layer does as the decision moves further from where it started.Qualitative, not measured

As the domain moves further away, the domain runtime is reused less and less while Core stays the same. If both fell together, the result would be a strong single-domain system, and the horizontal architecture would not be proven. A change forced into Core is treated as a finding: a missing primitive, or a domain concept that leaked in.

08.3Security, tenancy and reconstructability

Reconstructable by construction, years later.

A system that holds institutional authority must be isolated in depth, provable to third parties and reconstructable long after the people involved have moved on. These are properties of the whole architecture, not features of a security page.
How Inversiq approaches security

A reconstruction answers, verifiably

  1. What was known, and when?Knowledge horizon · bitemporal state
  2. What was assumed, and how uncertain was it?Value envelopes
  3. Which models ran, and which rules applied?Runs · model registry · rule versions
  4. What did AI propose, and who accepted or rejected it?Proposals · overrides
  5. What was challenged, who reviewed it, and who dissented?Challenges · findings · waivers · reviews · dissent
  6. Who had authority, and what did they authorise, on which conditions?Authority path · policy versions · the sealed record
  7. What was done, and was its effect confirmed?Actions · confirmations
  8. What happened, and how was it attributed?Outcomes · attribution

Every answer comes from the State Core, and the whole package verifies against the signed ledger. Audit becomes a query rather than an investigation.

What the whole architecture requires

Isolation

  • Isolation in depth. Enforced in the database as well as the application; the tenant derived only from authenticated identity.

Identity and keys

  • Identity for every actor. People through the institution's identity provider; services and agents with short-lived workload identities.
  • Signed approvals. Signed with the approver's own credentials, so authority is provable to third parties, not asserted by a vendor's database.
  • Erasure without rewriting history. Personal data under subject-scoped keys; erasure destroys the key while the fact of an approval stays provable.

Record integrity

  • Tamper-evident history. A hash-chained ledger with signed tree heads held outside the operator's control.
  • Evidential custody. Every object a decision relied on is retained under the institution's retention schedule.

Assurance and exit

  • Independent assurance access. Internal audit, external auditors and supervisors get logged, read-only access the first line cannot revoke.
  • Exit and portability. The decision history is the institution's, in an open format, verifiable without Inversiq.
Chapter 09

Compounding

Why governed decisions compound, and why better AI makes that matter more.

  1. 09.1Why it compounds
  2. 09.2Better AI raises the stakes

09.1What accumulates

Why governed decisions compound.

Every governed decision leaves something behind that the next one can use: a record, its connections, an expectation to judge it by. One decision is reconstructable. A thousand become institutional memory and calibration. None of it can be copied from a repository or bought as a dataset. Only governed use creates it.

  1. 1 decision

    A reconstructable record

    What was known, assumed, challenged and authorised, provable years later without an investigation.

  2. 10 decisions

    Connections

    Shared tenants, assumptions and limits become visible. A change in one place finds every decision it touches.

  3. 100 decisions

    Patterns

    Recurring exceptions, assumption errors and review bottlenecks show up. Reference classes start to form.

  4. 1,000 decisions

    Calibration

    Expectations are scored against outcomes by segment. The next range starts from the institution's own record, not from habit.

Fig. 09.1What becomes answerable as governed decisions accumulate. The records are the same objects at every scale; what changes is what the institution can ask of them.

Three assets build up, and they belong to the institution.

  1. 01

    Governed history

    Every record, dissent and authority path, sealed when it happened.

    R-17 still shows, years on, what the committee relied on and who disagreed.

  2. 02

    Calibration from outcomes

    How far the institution's own assumptions, forecasts and overrides have been off, by segment.

    Exit yields in secondary logistics: set 35 bp too low, on average. The next exit-yield range starts from that record, not from habit.

  3. 03

    Connected institutional state

    Entities, shared assumptions and dependencies across every decision.

    Tenant group T is one entity in three decisions, and one limit.

Each makes the next decision cheaper to prepare, harder to get wrong and easier to defend.

Seven loops produce them.

A decision is not a line with a return arrow. It moves through loops that run at different speeds, from minutes to decades. Every loop reads the same state and writes through the same boundaries, and each leaves behind something a slower loop uses.

State CoreStorethe presentLedgerthe historyGraphthe connectionsRecordsthe proofsOne state. Every loop reads it; every loop writes through the Commit Boundary.
  1. 1Analysispropose · compute · challengeMinutes to daysLeavesRuns, experiments, findings, challengesFeedsThe authority loop
  2. 2Authorityreview · condition · authoriseDays to weeksLeavesRecords, authority paths, dissent, conditionsFeedsThe execution and validity loops
  3. 3Executionact · confirm · compensateHours to weeksLeavesActions and confirmationsFeedsObservation
  4. 4Validitymonitor · trigger · reconsiderThe life of the decisionLeavesTriggers, reconsiderations, amended recordsFeedsThe authority loop
  5. 5Outcomeexpect · observe · attributeMonths to yearsLeavesOutcomes and attributionsFeedsThe learning loop
  6. 6Learningsignal · propose · govern changeAcross decisionsLeavesCalibrations, revised methodology and policyFeedsEvery future analysis
  7. 7Memoryrecord · recall · informAcross the institution's historyLeavesCases and reference classesFeedsEvery future frame
Fig. 09.1bFastest first. Each loop reads the State Core and writes back through the same boundaries; what one leaves behind, a slower one later uses.

The loops depend on each other in order

  1. Governed state
  2. Sealed records
  3. Recorded expectations
  4. Observed outcomes
  5. Learning

Learning is empty without outcomes, outcomes cannot be judged without recorded expectations, and expectations need sealed records. That is why the record comes first.

09.2The better-models test

Better AI makes control worth more.

Models are getting better at proposing: more analysis, faster, aimed at bigger decisions. Every proposal still has to become institutional state, and every action still has to be permitted. So as models improve, control over state, computation, authority, execution, lineage and outcomes becomes more valuable, not less.

×10If models become ten times more capable, which parts of the architecture shrink, and which matter more?

Improves, or commoditises

Interpretation and extraction
Better models extract more from worse documents. Bespoke parsing pipelines shrink.
Reasoning and research
Proposal quality and volume rise sharply.
Drafting and explanation
Briefs, criteria, formulations and narratives improve.
Planning
Agents attempt longer, more interleaved chains of work.
General prediction
Partly absorbed where general knowledge suffices.

Becomes more valuable

Authoritative state
More machine-produced content needs one place where what is established is decided.
Exact computation
Unchanged: it exists for reproducibility and accountability, not because models cannot calculate.
Provenance, lineage and time
Model-derived content without lineage is unverifiable.
Verification and assurance
More persuasive errors need independent method, data and people, not a second model.
Policy, authority and deliberation
Faster, more persuasive proposers need explicit authority and measured review.
Agent runtime and execution control
More autonomy requested means more need for identity, attenuation and control.
Records, outcomes and memory
Models cannot observe what they were not connected to; better models exploit history the institution alone holds.
Fig. 09.2Every part of the architecture, asked what happens if models become ten times more capable. The parts that make up for weak models shrink; the parts that hold the institution's state grow in value.

Each model generation is a supplier. Everything structural is the institution’s own.

Models are suppliers behind a gateway and a registry, so each new generation arrives without structural change. Everything structural rests on what no model can supply: the institution's own state, authority, history and outcomes.

One dependency grows rather than shrinks: meaningful human review. As models improve, the risk is not a broken boundary but a formally intact one where review decays into rubber-stamping. Reviewer attention is therefore measured and governed.

Chapter 10

Long-term architecture

What has to exist first, what Inversiq will not build, and where the architecture ends up.

  1. 10.1Dependency map
  2. 10.2Maturity
  3. 10.3Capability explorer
  4. 10.4Anti-goals
  5. 10.5The end state

10.1View 07 · Evolution

The dependency map matters more than dates.

Long-term capabilities are earned. Each becomes possible only when the capabilities beneath it exist. A demonstration can suggest otherwise, but a capability with missing foundations is not yet possible, however good the models are.

  1. Institutional learning

    Learning needs outcomes. Outcomes are judged against expectations sealed in the decision record. The record is written through the Commit Boundary and binds pinned runs of the kernel.

    21 prerequisites in the full slice

    • Commit Boundary needs Value envelope.
    • Decision record needs Commit Boundary.
    • Recorded expectations needs Decision record.
    • Outcome capture needs Recorded expectations.
    • Replay attribution needs Outcome capture.
    • Assumption calibration needs Replay attribution.
    • Pinned runs needs Calculation kernel.
    • Decision record needs Pinned runs.
    • Replay attribution needs Bitemporal state.
    • Outcome capture needs System feeds.

  2. Controlled machine action

    Before an agent may act without per-instance approval, three things must exist. Authority it can be delegated. An identity of its own. An Execution Boundary that checks every action, sends it once and confirms its effect.

    25 prerequisites in the full slice

    • Policy decision point needs Policy model.
    • Execution Boundary needs Policy decision point.
    • Exactly-once dispatch needs Execution Boundary.
    • Write-back needs Exactly-once dispatch.
    • Execution confirmation needs Write-back.
    • Pre-authorised actions needs Execution confirmation.
    • Bounded delegation needs Authority graph.
    • Machine delegation needs Bounded delegation.
    • Machine delegation needs Machine identity.
    • Pre-authorised actions needs Machine delegation.

  3. Active decisions

    Reopening a decision needs monitors. Monitors watch a validity envelope. The envelope is built from breakevens and sealed in the record. Breakevens need criteria held as data and batch runs of the kernel.

    22 prerequisites in the full slice

    • Criteria as data needs Policy model.
    • Breakevens needs Criteria as data.
    • Validity envelope needs Breakevens.
    • Decision monitors needs Validity envelope.
    • Reconsideration needs Decision monitors.
    • Decision record needs Commit Boundary.
    • Validity envelope needs Decision record.
    • Batch evaluation needs Pinned runs.
    • Breakevens needs Batch evaluation.
    • Decision monitors needs System feeds.
Fig. 10.1Three load-bearing paths, simplified. Read each from the foundations at the top to the long-term capability at the foot. The capability explorer (10.3) holds every dependency.

10.2Maturity

Towards adaptive decision infrastructure.

Maturity here means what is logically possible, not a calendar or a product status. The levels are not a single ladder: once decisions are connected, acting on them and watching them are parallel branches, and the highest level needs both. It is an order of dependency, not a delivery promise.
Maturity levels, what each adds and what it needs
1Governed decisionsDecisions as first-class objects: typed state, deterministic computation, snapshot-bound review, named authority, sealed records with recorded expectations.Needs Nothing beneath it
2Assured decisionsThe case is challenged before authority: findings, reconciliation, independent computation, coverage and computed readiness.Needs Governed decisions
3Connected decisionsDecisions, entities and assumptions connected across the institution; bitemporal state and the graph answer impact questions.Needs Assured decisions
4aExecutable decisionsAuthorised decisions change external systems through action contracts and the Execution Boundary, with confirmation and compensation.Needs Connected decisions
4bObserved decisionsDecisions stay active: envelopes monitored, conditions tracked, outcomes captured against expectations, declined options observed.Needs Connected decisions
5Learning decisionsAttribution, calibration, forecast scoring and case recall improve decisions through governed learning signals.Needs Observed decisions
6Adaptive decision infrastructureInstitution-specific models, bounded delegation to machine actors for classes of decisions and actions, cross-decision optimisation: all inside explicit authority.Needs Learning decisions and Executable decisions
Fig. 10.2Seven levels, ordered by what each needs, not by date. Executable and observed are parallel branches; adaptive needs both learning and executable.

Level 6 is not autonomous. It is a system that knows exactly what may be done, by whom or what, on which evidence and within which limits.

Autonomy at the highest level is authority delegated through the authority graph: limited to classes of action, measured and revocable. Material authority stays with named people at every level, and the authority boundary holds as the system grows more capable. That is what makes the extra capability safe to use.

10.3For reference · capability explorer

A design space, not a feature list.

The full catalogue maps close to two hundred capabilities in seventeen areas. A representative slice is here for anyone who wants the detail: what each capability does, what it depends on and what it makes possible.
State Core
  • State Core10
Understanding
  • Data & Context6
  • Knowledge & Semantics5
Analysis
  • Reasoning4
  • Computation5
  • Prediction4
  • Decision Science9
Assurance
  • Verification & Assurance5
Governance
  • Policy4
  • Authority5
  • Deliberation4
Control spine
  • Control spine5
Action
  • Controlled Execution5
Feedback
  • Observation4
  • Learning4
  • Memory & Portfolio4
Platform
  • Platform & Trust6
Fig. 10.3The slice at a glance: 89 capabilities across 17 areas, grouped by plane. The explorer below is closed by default.
Open the capability explorer

The institutional state, its history, its connections and its sealed records.

State Core · State Core · depth 7 · 17 prerequisites

Decision graph

Typed relations across decisions, entities, assumptions, policies, models, actions and outcomes, with asserted, derived and inferred edges kept apart.

Why it matters
Dependency, inheritance and exposure are graph properties.
In commercial real estate (illustrative)
The financing decision inherits the acquisition's NOI assumption and is constrained by leverage policy v3.

Depends on

Unlocks

Decision graph. Depends on 3 capabilities; unlocks 3.

Depth is the length of the longest dependency chain beneath a capability. It describes structure, not timing or availability.

10.4Architectural anti-goals

What Inversiq is deliberately not building.

Each of these is a direction the system could drift into, and many are good products in their own right. Each would weaken something the architecture exists to provide, so the line is drawn on purpose.

  • Not a replacement for the business's own systems

    Leases, balances, documents and customer records stay where they are. Inversiq holds the decisions about them, which is what lets it outlast any one of those systems.

    A system of record for the business Another document repository Another BI dashboard A spreadsheet replacement for its own sake A generic CRM An enterprise-wide digital twin

  • Not a generic AI tool

    A chat can propose and a search can find, but neither can hold authoritative state, authority or history. Models are suppliers to the system, not the system.

    A generic chatbot A generic RAG platform A model provider

  • Not autonomous authority

    Machine actors work inside explicit, bounded and revocable authority. The institution sets the objective, and no code path approves a material commitment.

    An uncontrolled autonomous agent platform An arbitrary agent swarm An investment adviser or decision-maker

  • Not horizontal workflow software

    Workflow serves the decision lifecycle. It never stands in for the decision itself.

    Generic workflow or BPM software A no-code automation builder

10.5The end state

A system of record and control for consequential decisions.

Realised over many years, the architecture gives an institution one system around the decisions that matter most: a record of each, and control over what each one sets in motion. Any decision can be reconstructed. Each one improves the next. And the system grows more capable without loosening who may decide.
  1. Decision classesOne governed decision class in one proving domainToward:Many decision classes across the institution, on the same Core08.1 · 08.2
  2. MemorySealed records and their recorded expectationsToward:Recall, reference classes and calibration across years of decisions07.1 · 07.5
  3. ExecutionAuthorised actions requested through declared contractsToward:Connected, contract-bound execution across the institution's systems06.3 · 06.4
  4. LearningOutcomes judged against what was expectedToward:Governed learning signals that refine methodology and policy07.4 · 07.6
  5. InfrastructureShared primitives proven on one domain runtimeToward:Reusable decision infrastructure: rules as data, shared governance, new runtimes08.1 · 10.2
Fig. 10.5Five directions the architecture extends in, each from a mechanism this page has already described. An order of dependency, not a timetable.

Machine actors act only through

Governed Agent Runtime

14 engines in 6 planes

Understanding
Data & Context Knowledge & Semantics
Analysis
Reasoning Computation Prediction Decision Science
Assurance
Verification & Assurance
Governance
Policy Authority Deliberation
Action
Controlled Execution
Feedback
Observation Learning Memory
Commit Boundary
State CoreStorethe presentLedgerthe historyGraphthe connectionsRecordsthe proofsEvery decision reconstructable and provable.
Execution Boundary

Systems of record and the outside world

changed only by authorised, confirmed actions

Seven loops, from minutes to decades, read this one state and write through these boundaries: analysis authority execution validity outcome learning memory

Fig. 10.5bThe end state, drawn once: an architecture, not a plan.

In that system, intelligence is abundant and replaceable, and authority is explicit. What lasts is the institution's own state, history and outcomes, and those compound with use. That is Decision Infrastructure: where consequential decisions are made, kept and improved.