Identity. Memory. Execution.
In that order, always.
Demiton builds institutional memory for civil construction through three enforced layers. Identity grounds every record in a person or system. Memory attaches every record to the Worker or Project it belongs to. Execution turns every system interaction into a memory event that compounds over time.
Every answer sourced. Every action governed. Every write auditable.

Every record is attributed to a person.
Demiton uses Microsoft Entra ID as its identity foundation. Every workflow run, every memory record, every query is bound to the authenticated user or system that triggered it. Anonymous data does not enter the memory layer.
Entra ID authentication gates every entry point — the platform, the Claude connector, and all write operations. One identity provider for everything.
Project access, SharePoint libraries, and memory query scope are derived from HR-maintained Entra attributes — not manually managed per-user ACLs.
Every memory record carries the identity of the user or system that created it. Memory is earned through governed action, not assembled from anonymous data streams.
Every record attaches to the entity it belongs to.
Construction entities — Workers, Projects, Vendors — are modelled as Business Objects that accumulate memory over time. A site diary mention of Smith attaches to Worker:Smith. An allocation on Project:14831D attaches to Project:14831D. The relationship between them records Smith's performance on that specific project.
This is not a search index. It is a knowledge graph bound to your operational reality — episodic, semantic, and provable.
Timestamped operational records tied to a specific workflow run. What happened, when, and who was involved.
Extracted facts about an entity that persist across multiple workflow runs. Ground condition expertise. Historical rate ranges. Reliability patterns.
Worker:Smith has been on 14 projects. His episodic memory includes every diary mention, allocation, timesheet, and governance event across all of them. His semantic memory includes what Demiton has learned about his performance: ground conditions where he excels, certifications, reliability on coastal CFA work.
None of this lived anywhere before Demiton. Now it compounds with every job.
Every system interaction is a memory event.
Demiton does not allow direct system-to-system connections. Every interaction — reading from Business Central, writing to Assignar, pushing timesheets to PayCat — executes through a governed workflow that pre-commits its state before running, fails deterministically if anything goes wrong, and writes its result back to the memory layer.
Every workflow run is persisted to the database before execution begins. If the system fails mid-run, the state is recoverable — not lost.
Failures are explicit, logged, scoped, and recoverable. No silent retries. No partial writes that corrupt downstream memory records.
All external system access goes through controlled adapters. No direct API calls outside the boundary. Every external interaction is observable and auditable.
AI alone doesn't make construction faster. Memory does.
- ×Answers from general training data, not your jobs
- ×Context that resets every session
- ×No attribution — who said what, when
- ×No provenance — where did this number come from
- ×No operational history — what happened on this project
- —Answers from your own governed operational records
- —Memory that compounds across every workflow run
- —Full attribution — identity-bound to the person or system
- —Full provenance — sourced back to the system it came from
- —26,000+ operational records preserved and queryable today
Every system contributes to the memory layer.
Demiton connects to the systems your operation already runs. Each adapter contributes a different type of operational record to the memory layer — no replacement, no migration.
Worker · Project · Relationship
Every operational record from every connected system, bound to the entity it belongs to. Queryable via Studio Chat, Claude Connector, and automated pipelines.
Your memory. Your data. Australian infrastructure.
All operational data is stored in Azure Australia East (Melbourne). Memory records never leave the customer tenant. There is no cross-customer data sharing — each deployment is isolated by design.
Three-layer data classification governs what can be shared. Layer 1 is instance-private and cannot flow anywhere. Layer 2 is curated-advisor egress — opt-in, type-level only, customer-controlled. Layer 3 is Demiton platform IP, never customer-identifiable.
See it working with your systems.
Request a demo to see the three-act architecture running against Business Central and Assignar — memory accumulating in real time.