Memory Overview
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
| 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
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
| 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.
| 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
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
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
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.
| 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
The memory and graph layers are exposed through the Demiton MCP server. 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
- MCP Server - query the memory layer through Claude or ChatGPT
- Platform overview - how tiers fit together and what memory scope each unlocks
- Uploading Your Data - Insights customers: start building memory from uploaded contracts
- Connecting a System - Connected customers: connect your ERP and field systems to start accumulating live memory
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
When a fact changes, the existing memory record is not deleted. Instead:
- The old record receives a
valid_untiltimestamp. - A new record is written with an updated
valid_from. - The old record’s
superseded_byfield 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.