Skip to content
Demiton

Memory

Stable

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 Civil Memory works.

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.

After 50 jobs, Demiton knows more about how your organisation runs work than any single person on the team. That knowledge is indexed, citable, and 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

Section titled “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
Insights Your uploaded contracts and estimating data Historical rates, cost code patterns, estimator performance
Connected Every workflow run, allocation, and form submission across your live integrated systems Workers, projects, assets, site diaries, financials - the full operational record
Custom Full stack across all integrated systems with custom entity types As above, plus cross-system memory and custom entity types

Explore Insights - self-serve, no implementation fee. Talk to us about Connected when you need memory to compound across live operations.

What memory is

Section titled “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 records are typed, temporally valid facts and narratives, each carrying its own access control and confidence score. When the AI answers a question about a worker or project, it draws on this layer as ground truth - cited, not hallucinated.

Memory types

Section titled “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

Section titled “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.

Anchor What it represents
worker_id A canonical worker, identified across Assignar, KeyPay, and HR systems
project_id A canonical project
asset_id A canonical asset or piece of plant
workflow_run_id A specific workflow execution (episodic run narrative)

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

Section titled “Data domains”

Every memory record is tagged with its originating data domain. This governs who can read it, following the same three-domain model used across the rest of the platform.

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

Domain-based access is enforced at query time via ACL filtering. A user in an operations role sees operations-domain memory for their projects; payroll-domain memory is restricted to payroll staff regardless of who holds the underlying entity.

ACL and access control

Section titled “ACL and access control”

Memory records inherit their access control list (ACL) from the source record at write time. The ACL is expressed as Entra Object IDs and Entra Group IDs - the same identity model used for SharePoint and Azure AI Search.

At query time, the platform filters records against the calling user’s resolved Entra identity and group memberships. Records with an empty ACL (no specific users or groups) are accessible to anyone with domain access. Records stamped with specific user or group IDs require an explicit match.

Confidence threshold: only records with a confidence score of ≥ 0.9 are surfaced through the AI and MCP layers. Records written through direct ingest carry confidence = 1.0; records from fuzzy entity resolution carry 0.9 to 1.0.

Entity briefs

Section titled “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

Section titled “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.

Edge type What it represents
worker_assigned_to_project Worker is allocated to a project
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_assigned_to_project Asset is deployed to a project
asset_is_of_type Asset classification
asset_has_charge_out_rate Asset’s current charge-out rate
project_requires_induction Inductions required to work on a project
project_located_at_postcode Project’s physical location

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

MCP tools

Section titled “MCP tools”

The memory and graph layers are exposed through Ask Demiton. These tools are callable from AI agents with operations-domain access.

Tool What it does
query_worker_memory Retrieve memory records for a specific worker
query_project_memory Retrieve memory records for a specific project
query_asset_memory Retrieve memory records for a specific asset
query_relationship_memory Query the relationship graph for entities connected to a given entity
query_workers_on_project Workers currently assigned to a project
query_assets_on_project Assets currently deployed to a project
query_worker_skills Skills held by a worker
query_worker_inductions Inductions held by a worker
query_workers_qualified_for Workers holding a specific competency
query_workers_near_postcode Workers based near a given postcode
query_asset_charge_rate Current charge-out rate for an asset
query_asset_operators Workers qualified to operate a specific asset

All memory tools enforce operations-domain access. Every call - allowed or denied - generates an access decision audit record. See MCP Server for connection details.

Next steps

Section titled “Next steps”

How memory is written

Section titled “How memory is written”

Memory records are written by the platform through two paths:

Workflow projections - when a workflow task completes, the PROJECT_MEMORY verb writes structured facts extracted from the adapter response into MemoryRecord rows. Each record is idempotent: re-running the same workflow on the same data produces no duplicate records.

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 be set, ACL must be derived from the source, and source type must be declared. No memory record can exist without traceability to a canonical entity.

Supersession

Section titled “Supersession”

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

  1. The old record receives a valid_until timestamp.
  2. A new record is written with an updated valid_from.
  3. The old record’s superseded_by field points to the new record’s ID.

This chain is preserved indefinitely. Queries filter to valid_until IS NULL by default (currently valid), but can inspect the full history through the structured payload and supersession links.