Inside Pivot's V3.5 architecture for adversarial matters, expressed through an ontology and built on SurrealDB.
Consider a client that declares that an account held £55,000 on 31 March, and a bank statement that records £40,000 on the same date. January and March statements have been supplied, while February is missing. Before anyone drafts a financial schedule, there are already two different problems: a disagreement about a balance and a gap in the evidence.
Both figures matter. So do their sources, the date they describe and the decision about how to use them. Choosing one value and discarding the other would make the schedule easier to generate while making the matter harder to understand. Reducing the disagreement to a chat message would leave the next task dependent on someone finding that message and reading it correctly.
This is why we describe Pivot as a computational architecture for adversarial matters expressed through ontology. In V3.5, the matter is the persistent unit of work. Clients, professionals and agents contribute to it through attributed assertions, explicit computations and scoped decisions. SurrealDB supplies the connected data foundation for those relationships.
Our organising principle is continuity, namely that preparation, evidence and professional judgement should remain intelligible as the work moves between people and systems. Financial disclosure makes the architectural choices concrete. We will follow the account above through disagreement, review and the arrival of a late statement.
Give disagreement a structure
An adversarial matter contains statements made by people with different positions, knowledge and responsibilities. A client declaration, an extracted bank entry, an expert opinion and a solicitor's assessment can concern the same asset while carrying different evidential weight. We represent those contributions separately.
The Polyphonic Assertion Ontology gives each assertion an envelope: who asserted what, about which entity and aspect, on what basis and at which time. For our account, the subject is a stable account identity; the aspect is its closing balance; the value is a typed monetary amount in GBP; the effective date is 31 March. The client's declaration and the statement extraction have separate voices, kinds and source anchors.
The effective date and the time an assertion enters the system are separate. A March balance received in April still describes March. A correction has its own version and a supersession relationship, preserving the earlier declaration. Source anchors identify the exact document version and location used, so a later change to a file cannot silently change the basis of an assertion.
Figure 1. Competing assertions retain separate origins. A computed finding and a professional decision have distinct identities and dependencies.
Four parts of the system have separate responsibilities: the ontology defines vocabulary, types, relations and constraints; the graph holds the matter state that those definitions describe; explicit rules and domain handlers compute findings and control actions; and language models propose extractions, explanations and drafts. Because each responsibility stays with one part, the meaning of each operation can be inspected. The ontology describes the disagreement, but it does not decide which party is right.
Compute findings over comparable assertions
For the two balances, comparison starts with account identity, aspect, currency, date and assertion kind. £55,000 at the end of February and £40,000 at the end of March could both be correct. If the identity is uncertain or a date is missing, the comparison stays unresolved and records the reason. A model's confidence cannot supply the missing information.
A finding records the rule version, the assertion versions it examined, whether the rule applied, and an explanation. The coverage finding has different inputs: the account, the required period and the evidence received. February's absence is independent of the balance conflict, so one finding can change while the other remains open.
Suppose a solicitor reviews the March statement and adopts £40,000 for the draft schedule. The decision records the reviewer, the accepted engagement, the purpose, the rationale and the exact inputs. The £55,000 declaration keeps its original author and status. Adoption sets a working position for a defined purpose, and the competing position stays on record.
Findings, decisions and outputs therefore have their own records. A summary such as 'the account balance is £40,000' is a view over those records, written for a particular audience and current as of a stated point. The relationships underneath it show how that figure entered the schedule.
Keep the relationships in SurrealDB
SurrealDB fits the shape of this state. Its record links connect records through typed record IDs, including references in nested objects and arrays. An assertion links to its subject and source version; a domain query follows those links to retrieve its basis.
Some relationships need state of their own: a dependency carries an input version and the reason it was included, and a supporting relationship carries provenance. SurrealDB's graph relations are records with fields alongside their endpoints, so the relationship itself can be inspected and queried.
The useful queries follow the work: which assertions support this section, which sources did this decision examine, and which results depend on a changed input? Pivot's domain model supplies the meaning of those relationships. Domain services apply access and action policy as the graph is queried.
The original document bytes are kept behind a separate storage boundary. An originating document system remains authoritative for its own versions. An authorised evidence copy carries the obtained version, hash and receipt; a reference carries the source identifier and access requirements. The graph connects evidence to work without absorbing every system's responsibility.
Record links stay within the database in which a SurrealDB query runs. Sharing across workspace and database boundaries is an application operation with origin identifiers, exact versions and a transfer receipt. We keep local graph relationships and cross-workspace authority explicit.
Give every interface the same domain contract
The client portal, professional workbench, background workers and external agents are entry points into the same operations. PivotHub provides access and coordination: identity, source mappings and eligible tools. Shared domain handlers own the evidence, findings, decisions and release semantics.
Figure 2. PivotHub connects interfaces and agents to shared domain operations. These responsibilities sit within a modular application with workers and durable state.
The mutation boundary checks the actor, workspace, matter, engagement, action, input shape and expected versions. Approval is specific to the operation. A matter ID identifies a target; credentials and policy establish authority. An agent and a user interface enter through the same contract.
Tool contracts make that boundary visible: typed inputs and outputs, versioned schemas, declared effects, permissions and retry behaviour. Reading an account, proposing a correction, accepting a value and releasing a schedule are separate operations. Delegating preparation does not delegate approval. Instructions that appear inside a bank statement are treated as document content, not as instructions to act on.
Agent context is also a bounded input: permitted source anchors, assertion and finding versions, current instructions and freshness information. The run's manifest, tool receipts and output versions make it possible to check its result before the result has any effect. External assistants receive bounded results, and what they say about those results afterwards is outside the domain handler's control.
Make changing evidence part of the model
The situation presented at the top of this post includes a missing statement for February. What happens when this statement finally arrives?
Once the statement for February arrives, its receipt and source version become new inputs. Coverage is recomputed for the account and period; new comparable assertions enter the relevant conflict computations. The coverage gap closes, while the disagreement about March may remain open.
Dependencies connect input versions and rules to findings, output sections and decisions. This structure identifies the work that is affected and explains why it needs to be reconsidered. In the schedule, the passage about missing statements changes. A reviewed March figure retains the evidence and decision that supplied it.
Figure 3. A late statement creates new results and review work. Earlier approvals remain attached to their original inputs and output versions.
An approval is bound to an exact output version, input manifest, audience and operation. Before release, the system checks those dependencies and the current authority. If material evidence arrives between generation and approval, the output may need to be reviewed again. A change to an unrelated asset need not invalidate every section.
There is an engineering cost to this choice. Dependencies need careful maintenance, and retained versions need a retention and access policy. In return, the effect of a new source on the work can be identified exactly, instead of the source becoming one more item in the context window.
Give memory and execution different jobs
Our companion article followed an agent remembering a solicitor's correction. Scoped operational memory preserves continuity: a selected instruction, an unfinished request or a constraint on the next task. On resumption, that memory is interpreted against current evidence, permissions and task scope.
Each kind of state has one job: matter state holds assertions, findings and decisions; memory holds continuity notes; summaries give readable views; and workflow state records completed steps and their effects. A remembered sentence is useful context, but the source and the execution receipt keep their own identities and responsibilities.
SurrealDB Agent Memory distinguishes scope from permission: scope partitions records, while principals and grants govern access. The same distinction matters in Pivot. A firm, matter and user path identifies a partition; enforced authority controls what can be retrieved or changed.
A worker interrupted after receiving February's statement needs a checkpoint and an input manifest. A timeout after uploading a schedule may leave the external outcome unknown. Recovery checks the destination or reconciles the recorded operation before repeating the effect. Memory alone cannot answer whether an upload succeeded.
The execution contract rests on idempotency keys with request hashes, worker leases and fencing, and a durable event or outbox alongside the domain change where both share a transactional store. Across stores and external systems, the contract is at-least-once delivery with deduplication and reconciliation. An ambiguous result is recorded as an explicit state that has to be resolved.
Keep authority with the contribution
The architecture separates actor, workspace, matter and engagement. A person's preparation and a professional's contribution can concern the same matter while retaining different access and responsibility. A released assessment carries its inputs, qualifications, scope and permitted audience, so its basis stays clear when preparation continues.
A professional engaged for one question receives the grant for that question, and another professional needs a grant of their own. Internal analysis stays under the firm's control. Permission to read a source, authority to adopt a position and authority to release an assessment are separate parts of the contribution.
The boundaries also apply to derived information, because snippets, search counts, summaries, agent context and conclusions can reveal protected inputs. A revocation also reaches dependent work and cached context. An earlier valid release has its own policy basis and audit history. Sharing preserves lineage without turning the matter into an unrestricted common graph.
A matter that carries its reasoning forward
We now return to the account with the statements from January to Marchh. The graph holds two March assertions with different origins, a finding about their disagreement, a reviewed working figure and a coverage result changed by February's arrival. Each answers a different question. Their connections explain how the schedule was assembled and what the next task can rely on.
That is the architectural role of ontology in Pivot V3.5: it gives preparation, evidence, computation and professional judgement a shared language while keeping their differences. SurrealDB provides the records and relationships. PivotHub and the domain contracts govern how participants act on them. The matter carries the work forward, with its sources, disagreements and decisions still attached.
