Remembering the correction: Ontology and agent memory in Pivot AI

Ontology and agent memory in Pivot

How structured matter state and SurrealDB Agent Memory help an agent resume unfinished professional work.

Consider a property with a valuation of £650,000. When the valuation report is uploaded for an agent to process as part of a financial disclosure, the agent describes the property as "other property". A solicitor then corrects the classification, because the valuation supports the figure but does not establish whether the property is the family home or another property.

Suppose the next conversation about the matter starts a week later. What should the agent remember? It needs the valuation, the correction, the unresolved classification and the need to check for new evidence, and it also needs to tell their status apart. A previously generated description shouldn't be treated as authoritative just because it was saved to memory.

That is the problem we are working on at Pivot, where we are building a computational architecture for adversarial matters, expressed through ontology. Our first commercial route is financial disclosure, where documents, assertions, missing evidence and professional decisions need to remain intelligible as the work progresses.

This walkthrough uses a fictional property example, a small teaching model executed on SurrealDB 3.3.0, and the adapter Pivot built to connect its application to SurrealDB Agent Memory.

Start with the assertion

A property record can hold a value and a classification. Once people disagree about either, the application needs more information: who supplied the value, which aspect they described, what they relied on and whether someone reviewed it.

The polyphonic assertion ontology we developed at Pivot gives those distinctions a vocabulary. "Polyphonic" means that multiple voices can make assertions about the same subject without the system immediately choosing one account.

The ontology defines the entities, assertion kinds and relationships, while records represent a particular matter and domain rules determine which comparisons and calculations are meaningful.

For this example, five record types are enough:

SurrealDB record links let these records refer directly to one another. In this model, subject links an assertion to the property, while basis identifies its source input.

Figure 1. Record links in the reduced teaching model.

These are record links in the teaching schema, and the full architecture carries additional identity, temporal, access and provenance information.

The vocabulary itself lives in the field definitions. Literal union types restrict each assertion's aspect, voice and kind, and each review's decision, to named values. The teaching schema lists only the values this walkthrough uses:

SURREALQL / ASSERTION AND REVIEW FIELDS

DEFINE FIELD subject ON assertion TYPE record<property>;
DEFINE FIELD aspect  ON assertion TYPE 'valuation_gbp' | 'classification' | 'occupancy';
DEFINE FIELD value   ON assertion TYPE decimal | string;
DEFINE FIELD voice   ON assertion TYPE 'Valuer' | 'Preparation agent';
DEFINE FIELD kind    ON assertion TYPE 'source_statement' | 'model_inference';
DEFINE FIELD basis   ON assertion TYPE record<evidence>;

DEFINE FIELD assertion ON review TYPE record<assertion>;
DEFINE FIELD decision  ON review TYPE 'leave_open';

With these definitions on a SCHEMAFULL table, SurrealDB rejects an assertion whose voice or kind falls outside the vocabulary. A voice of 'Narrator', for example, fails with a coercion error instead of being stored.

Keep the source statement and the inference separate

With the property and valuation report seeded, we can record two assertions:

SURREALQL / TWO ASSERTIONS

CREATE assertion:valuation SET
    subject = property:wrenfield,
    aspect = 'valuation_gbp',
    value = 650000dec,
    voice = 'Valuer',
    kind = 'source_statement',
    basis = evidence:valuation_v1,
    locator = 'page 1';

CREATE assertion:classification SET
    subject = property:wrenfield,
    aspect = 'classification',
    value = 'other property',
    voice = 'Preparation agent',
    kind = 'model_inference',
    basis = evidence:valuation_v1,
    locator = 'page 1';

Both assertions point to the valuation report, but they make different claims: the first records the valuation as the valuer stated it, while the second records the agent's inference about classification.

A source link identifies the input to an assertion, but whether that input supports the assertion is a further question. The distinction matters because attaching a citation to an inference can make it look more established than it is.

To see both assertions with their attribution, query them together:

SURREALQL / INSPECT ATTRIBUTION

SELECT aspect, value, voice, kind, basis.title AS source
FROM assertion
WHERE subject = property:wrenfield
ORDER BY aspect;

The executed HTTP JSON result is:

RESULT / HTTP JSON

[
  {"aspect": "classification", "kind": "model_inference",
   "source": "Valuation report", "value": "other property",
   "voice": "Preparation agent"},
  {"aspect": "valuation_gbp", "kind": "source_statement",
   "source": "Valuation report", "value": "650000", "voice": "Valuer"}
]

The valuation was written as 650000dec, so it is stored as a SurrealQL decimal, and the HTTP JSON output serialises that decimal as the string "650000". More importantly, attribution and assertion kind remain visible alongside the value.

The same pattern can hold competing assertions from the parties. Before computing a discrepancy between them, a domain rule must establish that they concern comparable subjects, aspects, dates, currencies and assumptions, because a different number alone is insufficient.

Record what the reviewer decided

In our example, the solicitor leaves classification open pending evidence about occupancy or use. Pivot's model records that decision as a separate review record rather than editing the assertion:

SURREALQL / REVIEW DECISION

CREATE review:classification_correction SET
    assertion = assertion:classification,
    reviewer = 'Example solicitor',
    decision = 'leave_open',
    purpose = 'Property classification for financial disclosure',
    rationale = 'The valuation does not establish occupancy or use.',
    source_version = 'v1';

Reading the review back shows the proposed value next to the decision:

SURREALQL / INSPECT REVIEW

SELECT assertion.value AS proposed_value, decision, rationale
FROM review:classification_correction;

RESULT / REVIEW STATUS

[
  {"decision": "leave_open", "proposed_value": "other property",
   "rationale": "The valuation does not establish occupancy or use."}
]

The original inference still exists, and its review status and the reason for that status are available separately. Re-running the assertion query returns both original records unchanged, which preserves the history needed to understand the correction.

A production implementation also needs to bind the decision to the exact examined inputs, reviewer authority and relevant versions, whereas the reduced model demonstrates only the separation.

Save the correction deliberately

This is where SurrealDB Agent Memory enters the workflow.

In Pivot, saving to memory is a single, deliberate operation: the caller makes an explicit request to remember reviewed operational state, the save handler checks the caller's access, and only then does it invoke Pivot's memory adapter. Ordinary conversation does not automatically become durable matter memory.

For the example, the instruction is:

The valuation supports £650,000. Property classification remains open pending occupancy or use evidence.

The adapter uses SurrealDB Agent Memory's /facts write endpoint. With illustrative identifiers, its request body has this shape:

AGENT MEMORY / REQUEST BODY

{
  "text": "Solicitor-reviewed operational instruction for this matter: The valuation supports £650,000. Property classification remains open pending occupancy or use evidence.",
  "infer": "full",
  "scopes": [
    [
      "org/example-firm/matter/example-matter/user/example-reviewer"
    ]
  ]
}

The write carries an idempotency key derived from the scope and the instruction. For illustration, such a key has the shape org/example-firm/matter/example-matter/user/example-reviewer?the-valuation-supports-650000-property-classification-remains-open. The adapter then reports whether the save succeeded, was disabled or was unavailable.

The stored instruction preserves a useful state of work: the £650,000 figure is supported, the property's classification remains unresolved, and occupancy or use evidence is needed to resolve it.

Recall the work within its authorised scope

When a later question arrives, Pivot's adapter requests relevant reviewed state from the /context endpoint, with a read lens that uses the same firm, matter and user path as the write. The request asks for corrections, unresolved issues and next-step constraints relevant to the current question, and it uses a small candidate count rather than requesting a broad history for every answer.

Scope requires care, because a path identifies where memory belongs while permissions establish who may access it. SurrealDB Agent Memory's scope documentation makes that distinction explicit. Application authorisation, service principals and grants must agree with the requested scope.

The user component also makes this particular memory personal to an authorised participant working on the matter. Sharing a correction across a team needs an explicit policy and an appropriate scope.

There is a small retrieval detail worth retaining. Pivot's adapter removes a generic acknowledgement from older recalled context, because a sentence such as "Recorded as reviewed operational state" carries no property-specific information. If that is all retrieval returns, the adapter reports no_match, since a successful response from a memory service should not be confused with useful continuity.

Build the answer from memory and current evidence

In Pivot's case-chat integration, memory recall and current evidence retrieval are separate reads, and their results enter the model context with different labels and responsibilities.

The memory block instructs the agent to check recalled state against current matter data, keep unresolved issues unverified and explain relevant changes.

For our fixture, the current evidence check is simple:

SURREALQL / CHECK CURRENT EVIDENCE

SELECT VALUE value
FROM assertion
WHERE subject = property:wrenfield
    AND aspect = 'occupancy';

RESULT / OCCUPANCY ASSERTIONS

[]

Within this small, fully inspected fixture there is no occupancy assertion, so the classification remains open.

In a real matter, an empty retrieval result could also reflect incomplete extraction, access restrictions or retrieval coverage. The application must account for those possibilities before describing evidence as missing.

The distinction between memory and evidence also shapes observability. Pivot's adapter returns a bounded preview of recalled context and preserves available trace metadata, which helps a reviewer inspect what context was supplied but does not establish that the model used it correctly. Prompt guidance expresses the intended behaviour, and cross-session evaluations must establish whether the agent follows it.

Expose the same domain contract through PivotHub

Pivot's V3.5 architecture takes this separation beyond one chat handler, with PivotHub as the proposed coordination layer for authenticated access, connectors and governed tools.

An agent should receive bounded matter results containing provenance and review status. Mutations should pass through shared domain handlers that check permissions, inputs and versions.

SurrealDB supplies the linked data model and query mechanisms, and SurrealDB Agent Memory supplies a way to retain and recall working context. Pivot's ontology and application rules assign the domain meaning: what counts as an assertion, what a review changes, and which actions a participant may take.

Keeping those responsibilities explicit lets the surrounding models and interfaces evolve while the matter remains interpretable.

Before production, the important checks concern the boundaries between them: whether recall respects grants, whether current evidence is sufficiently covered, whether decisions remain bound to their examined versions, and whether the model preserves uncertainty when memory and new evidence differ. Full dependency propagation across findings and outputs belongs to the wider V3.5 design and needs separate implementation and validation.

The first commercial workflow gives us a bounded place to establish these properties. The larger vision is persistent preparation that people can carry forward as professionals contribute scoped judgement.

For the property in this example, useful continuity has a precise shape: the £650,000 valuation is supported; classification remains open; occupancy or use evidence is the next requirement. An agent returning to the matter should preserve that unfinished work and retain a route back to the evidence.

Technical sources

1. 1.

   Record links

2. 2.

   Storing memories

3. 3.

   Recalling memories

4. 4.

   Contexts and scope