Memory

Stable

The five diseases get caught late because the fact that would have flagged them sits in a different system from the one that pays for it. Memory is where those facts meet: the test result next to the pour, the notice window next to the instruction, the actual next to the tender. It is what each protection runs on.

Civil Memory is the heart of Demiton: one continuous, sourced record of a civil job from the public market through delivery. This page is the detailed model behind it. For the bigger picture - how the public market, the award seam, and your delivery join into one story - start with How your registers become one record.

Demiton’s memory layer turns every workflow run, operational form, and allocation record into queryable, access-controlled institutional knowledge - attached directly to the workers, projects, and assets the platform already tracks.

Memory accumulates: every workflow run, form submission, and allocation adds sourced facts bound to the entities they are about. That knowledge stays indexed and citable, and is surfaced back through the AI layer within the same security boundary that governs the rest of the platform.

---

What memory looks like on each tier

What memory looks like on each tier

Tier	Memory source	What you can query
Public	None - queries run against public records directly	AusTender, ABR, BOM, and open government data
Baseline	Your uploaded contracts and estimating data, plus every workflow run, allocation, and form submission across your live integrated systems	Historical rates, cost code patterns, estimator performance, and workers, projects, assets, site diaries, financials - the full operational record
Enterprise	Full stack across all integrated systems with custom entity types	As above, plus cross-system memory and custom entity types

Talk to us about Baseline when you need memory to compound across live operations.

---

What memory is

Every time a workflow runs, a form is submitted, or an allocation is created, Demiton projects a structured memory record out of that event and attaches it to the relevant entities - the worker who submitted the form, the project the allocation was for, or the asset involved. Memory records accumulate over time and can be queried through the AI chat interface and MCP tools.

This is not a search index of raw documents. Memory facts are typed, temporally valid records with a confidence score and a citation back to their source. When the AI answers a question about a worker or project, it draws on this layer as ground truth - cited, not hallucinated.

---

Memory types

Memory types

Type	What it holds	Example
episodic	Events - what happened and when	Workflow run summaries, form submissions, site diary entries
semantic	Facts with validity windows - what is known	A worker’s current competency, a project’s contract type
procedural	Methods and patterns - how things are done	Recurring workflow patterns, operational procedures

Each record carries a valid_from and optionally a valid_until. When a fact changes, the old record is superseded rather than deleted - preserving the full history. This temporal model means you can ask “what was true at this point in time” and get an accurate answer.

---

Entity anchors

Memory attaches to canonical entities, not to system-specific records. A single memory record can carry multiple anchors simultaneously - for example, a docket submission links to both the worker and the project.

Entity anchors

Anchor	What it represents
worker_id	A canonical worker, identified across Assignar, Employment Hero Payroll, and HR systems
project_id	A canonical project
asset_id	A canonical asset or piece of plant

Where the register defines them, a fact can also carry other coordinate axes - vendor, customer, legal entity, cost code, financial period, currency, and work activity. The subject of the fact is the entity it is about; the workflow run that produced it is recorded in fact lineage rather than as an anchor.

Anchoring to canonical IDs means memory survives system migrations and connector changes - the fact stays attached to the right entity regardless of where the source data came from.

---

Data domains

Each register declares a data scope that reflects the sensitivity of its facts. That scope governs who can read them, following the same domain model used across the rest of the platform.

Data domains

Domain	Scope
operations	Project activity, forms, allocations, plant movements
financials	Cost codes, rates, budget variance, contract financials
payroll	Pay records, leave, timesheets - most restricted

Read access is enforced at query time through each register’s declared data scope: a caller must hold the matching data:read_<scope> permission to read that register’s facts. Payroll registers (pay runs, pay rates), for example, require data:read_payroll; operations registers require data:read_operations.

---

Access control and confidence

Read access to Civil Memory is enforced at query time through the register’s declared data scope. A caller must hold the matching data:read_<scope> permission - for example data:read_payroll for pay runs and rates, or data:read_operations for allocations and site records - to read that register’s facts. The gate fails closed: a register whose scope cannot be resolved is denied.

Memory facts are org-wide within a tenant. There is no per-record ACL filter on fact reads: the scope on the register, not the individual row, decides who can read it. Relationship edges also carry an access domain and, where configured, the Entra group IDs permitted to traverse them.

Confidence threshold: recall has two floors. Chat-stated memory recalled into a conversation must carry a confidence of at least 0.85; the general memory reader uses a floor of 0.70. Facts written through direct ingest carry confidence = 1.0.

---

Entity briefs

Each canonical entity (Worker, Project, Asset) has an entity brief - an AI-generated summary synthesised from that entity’s current memory records. Briefs are cached for 24 hours and regenerated automatically by a background job.

Briefs appear on entity detail pages throughout the platform (worker profiles, project overviews, asset dashboards). They cite the memory records they draw from, so the source of every statement is traceable.

---

Knowledge graph

Alongside memory records, the platform maintains a relationship graph - a set of typed edges connecting entities to each other and to reference data.

Knowledge graph

Edge type	What it represents
worker_holds_competency	Worker holds a specific competency
worker_holds_induction	Worker has completed an induction
worker_has_skill	Worker has a registered skill
worker_operates_asset	Worker is a qualified operator for an asset
worker_lives_at_postcode	Worker’s home location
worker_paid_under_rate	Worker’s active pay rate
asset_has_charge_out_rate	Asset’s current charge-out rate
asset_located_at_geographic_area	Asset’s location
project_requires_induction	Inductions required to work on a project
project_located_at_postcode	Project’s physical location
project_has_subcontractor	Project’s subcontractor (a vendor flagged as a subcontractor)
project_has_estimate	Project’s estimate document
project_has_variance	Project’s variance document
variance_affects_cost_code	Variance affects a cost code
contracting_process_administered_by_agency	Government agency administering a contracting process
contracting_process_awarded_to_civil_contractor	Contractor awarded a contracting process

Worker and asset allocation - who or what is on a project - is not stored as a graph edge. It is derived at read time from the co-occurrence of a worker (or asset) and a project on the same allocation facts.

Edges have temporal validity (valid_from, valid_until) and carry a JSONB properties payload for additional structured data. Active edges have valid_until = NULL.

---

How the memory layer is queried

The memory and graph layers are not exposed as a set of separate MCP tools. They are capabilities of the single ask_demiton tool: when a question needs memory, ask_demiton routes it to the internal query services and returns cited records. See MCP tools for the generated list of tools a connection advertises, and Ask Demiton for what the tool does.

Through ask_demiton, a caller with the relevant register permissions can ask for:

• Memory facts about a worker, project, or asset, current and historical
• The workers on a project, and the assets deployed to a project
• A worker’s skills, competencies, and inductions
• The workers who hold a specific competency
• The workers based near a postcode
• A worker’s active pay rate, and an asset’s charge-out rate
• The workers qualified to operate an asset, and the assets a worker has operated
• A project’s postcode, and the inductions a project requires

Every call - allowed or denied - generates an access decision audit record. See MCP tools for the generated tool list, or MCP Server for connection details.

---

Next steps

• How your registers become one record - the spine that ties the public market to your delivery
• Ask Demiton - query the memory layer through Claude or ChatGPT
• What is Demiton - how tiers fit together and what memory scope each unlocks
• Uploading Your Data - start building memory from uploaded contracts
• Connecting a System - connect your ERP and field systems to start accumulating live memory

---

How memory is written

Memory facts are written by the platform through two paths:

Workflow projections - when a workflow task completes, the PROJECT_MEMORY verb projects structured facts extracted from the adapter response into the partitioned memory_fact table through the fact write gate. Each fact is idempotent: re-running the same workflow on the same data supersedes the current row rather than creating a duplicate.

Backfill - historical Assignar forms and allocations are backfilled into the memory layer during initial onboarding. Backfill records carry source_type = "backfill" and confidence = 1.0 for direct data matches.

The write path enforces: at least one entity anchor must resolve, and the producing source system must be declared. No memory fact can exist without traceability to a canonical entity.

---

Supersession

When a fact changes, the existing row is not deleted. Instead:

1. The old row is closed with a valid_until timestamp.
2. A new current row is written with an updated valid_from.
3. The two rows share a stable identity key - the current-state coordinate key for state facts, or the source system plus source ID for episodic facts - so the newest row is the live one and the earlier rows remain as history.

This chain is preserved indefinitely. Queries filter to valid_until IS NULL by default (currently valid) while the full history stays queryable by identity key.