# Demiton - Full Documentation Generated: 2026-10-03 ## Product identity USP: The overrun that never happens. Definition: Demiton fills your registers from the systems you already run, in a published format, and makes the result queryable from Claude or ChatGPT over the Model Context Protocol. Category: civil construction protection layer (construction software) Target customer: Australian civil construction firms, AU$10M-150M revenue, 30-200 people, self-perform with owned plant Primary interface: Claude / ChatGPT via Model Context Protocol (MCP) MCP server: https://api.demiton.io/mcp Web app: https://app.demiton.io Docs: https://docs.demiton.io Marketing: https://demiton.io ## The five diseases The taxonomy every register and surface is organised under - what erodes margin on a civil job, and what the register that watches for it gives you today. Rework: Work done twice: failed inspections, NCRs, wrong ground assumptions. Protection: The failed result reaches the person who can stop the next stage the day it lands, with the close-out date attached. Today: Every NCR, test result and plant pre-start lands in one register, tied to the location and the crew - so the pattern shows up before the same defect gets poured twice. Registers: safety_ncr, inspection_test_result, site_inspection, plant_prestart. Cost drift: Cost and programme drift against the tender. Protection: Drift against the price you quoted is flagged at $50K, not $5M. Today: Budget and actual are reconciled every night, by cost code, against the tender you priced - so drift shows up as a number you can query, not a surprise at the next progress claim. Registers: budget_vs_actual, job_budget, tendered_budget, cost_element, project_performance_record. Missed claims: Variations and time owed but never claimed: notices missed, time bars closed, wet days never logged. Protection: When the instruction arrives or the rain starts, the clock starts. The notice is drafted and waiting before the window shuts, while the ground is still wet. Today: Every variation, progress claim and contract clause is in one register you can query by project and date, and site diaries carry the weather on the day correlated against Bureau of Meteorology observations for the same location - so a notice window or a wet-weather claim is a question you can ask, not a date buried in an inbox or a claim reconstructed from memory weeks later. Registers: variations, change_event, progress_claim, contract_terms, payment_schedule, site_diary. Disputes: The claim that became a case. Protection: If the day's record isn't in by evening, you're told which one is missing while people still remember the day. Today: Contract terms, day works dockets and rate verifications sit in one queryable record, and every active project is checked each morning against 125 published evidence standards for its jurisdiction and contract form - met, at risk, missed or unmeasurable. The check runs; it has not yet been proved on a live job. Registers: contract_terms, sor_verification, day_works_docket, rfi. Lapsed compliance: The right to bid itself: panels, prequalification, certificates. Protection: Every expiry counts down at 90, 30 and 7 days, with the renewal attached. Today: Your schemes, classifications and certificate expiry dates are one register you declare once. Company certificate and insurance expiries already count down at 90, 30 and 7 days, with the alert in the app and by email; the countdown has fired end to end in a demo tenant, not yet on a live job. Registers: compliance_certifications, compliance_prequal, compliance_state, prequalification_answer, certification_register. All five protections run every day, each against the registers that hold its facts. Where a register is still empty, the protection says which kind of system would fill it. ## Tiers Free: AU$0. Protection on your first AU$1M of work under watch, every calendar year. Verified business email required. https://app.demiton.io/auth/register?ref=docs Baseline: AU$55,000/year. Margin protection, one flat annual fee. Up to AU$100M of work under watch, negotiated above. Protection included. https://demiton.io/contact?ref=docs-tier-baseline Enterprise: Contact us. Multi-entity consolidation, custom adapters and bespoke terms. Negotiated. https://demiton.io/contact?ref=docs-tier-enterprise Pricing basis: lifecycle reach, not seat count. All paid tiers: unlimited users. ## Core concept: Civil Memory Civil Memory is one continuous, sourced record of a civil job across its whole life. Public half: OCDS (Open Contracting Data Standard) - market, tenders, awards. Private half: OC4IDS (Open Contracting for Infrastructure Data Standard) - delivery projects. The seam: the award - when a pursued tender becomes a won delivery project. Every fact is typed, time-valid, anchored to a canonical entity (worker / project / asset), and carries a citation. Registers: 180 published, each with a versioned JSON Schema contract at /registers//v.json. ## Six product surfaces Studio: in-app AI - ask, get sourced answers and reports inline. Market: public civil work pipeline (planning, tender, award). Protection: the five diseases that erode margin - rework, missed claims, disputes, cost drift, lapsed compliance - plus the project board, watches, alerts and the prevention ledger. Every tier. The former Prequalification (Compliance) and Projects surfaces were retired into Protection in September 2026. Memory: the sourced record, entity briefs and the knowledge graph. Agents: scoped, budgeted tool loops; probe agents propose config, producer agents write reviewable output. Labelled "Agents & ML" in the app. Ask Demiton: MCP - the same tools as Studio, from your own AI client. Configuration surfaces: Systems (connectors, /connectors) and the Control Room (workflows, /workflows). ## Concepts Register: the product/storage axis of Civil Memory - what you ask for. Ingest group: the producer/transport axis of Civil Memory - how a fact gets recorded (previously "conduit"). Agent taxonomy: probe agents propose org configuration; producer agents write reviewable output. ## Standards OCDS: pre-award half of Civil Memory, projected on ingest from AusTender and state portals. OC4IDS: the post-award delivery-reporting shape. Snapshot publication is built and validated; per-project consented emission is not yet available. Conformance: adapters declare standard_conformance; a single validated service is the only writer to the public snapshot table. ## MCP tools A connection lists 4 tools. ask_demiton: Ask any question in natural language. Demiton routes it to the registers and public sources your tier permits and answers with citations. exa_search: Search the live web for something Demiton does not hold - a supplier page, a release note, a current figure. Available on Insights and above, and metered per search. tell_demiton: Propose a write to a connected system, or record a durable fact. Writes go to your approval queue rather than executing directly. switch_org: Change which organisation this connection answers for, when you belong to more than one. Also registered but not advertised: list_reports, run_report, get_report_run, build_work, build_status, queue_work. Platform-owner only: forge, instruct_demiton. --- ## [PRODUCT_OVERVIEW] Demiton Documentation Description: The overrun that never happens. Five things erode margin on a civil job - rework, cost drift, missed claims, disputes and lapsed compliance - and Demiton catches each one in the register that watches for it. URL: https://docs.demiton.io/ ## Five things kill margin. Demiton catches each one. Rework, missed claims, disputes, cost drift, lapsed compliance - the same five diseases on every civil job, caught late because the fact that would have flagged them early was never in one place. Demiton reads the register that holds that fact, every night, before the cost compounds. - **Rework**: Work done twice: failed inspections, NCRs, wrong ground assumptions. Protection: The failed result reaches the person who can stop the next stage the day it lands, with the close-out date attached. Today: Every NCR, test result and plant pre-start lands in one register, tied to the location and the crew - so the pattern shows up before the same defect gets poured twice. - **Cost drift**: Cost and programme drift against the tender. Protection: Drift against the price you quoted is flagged at $50K, not $5M. Today: Budget and actual are reconciled every night, by cost code, against the tender you priced - so drift shows up as a number you can query, not a surprise at the next progress claim. - **Missed claims**: Variations and time owed but never claimed: notices missed, time bars closed, wet days never logged. Protection: When the instruction arrives or the rain starts, the clock starts. The notice is drafted and waiting before the window shuts, while the ground is still wet. Today: Every variation, progress claim and contract clause is in one register you can query by project and date, and site diaries carry the weather on the day correlated against Bureau of Meteorology observations for the same location - so a notice window or a wet-weather claim is a question you can ask, not a date buried in an inbox or a claim reconstructed from memory weeks later. - **Disputes**: The claim that became a case. Protection: If the day's record isn't in by evening, you're told which one is missing while people still remember the day. Today: Contract terms, day works dockets and rate verifications sit in one queryable record, and every active project is checked each morning against 125 published evidence standards for its jurisdiction and contract form - met, at risk, missed or unmeasurable. The check runs; it has not yet been proved on a live job. - **Lapsed compliance**: The right to bid itself: panels, prequalification, certificates. Protection: Every expiry counts down at 90, 30 and 7 days, with the renewal attached. Today: Your schemes, classifications and certificate expiry dates are one register you declare once. Company certificate and insurance expiries already count down at 90, 30 and 7 days, with the alert in the app and by email; the countdown has fired end to end in a demo tenant, not yet on a live job. All five protections run every day, each against the registers that hold its facts. Where a register is still empty, the protection says which kind of system would fill it. {ROLLOUT_MARKER} [How this works, disease by disease →](/start-here/diseases) --- ## Where are you starting from? --- ## How do I get started with Demiton? The free path needs nothing but a business email. Paid options come after. 1. **Create your account** - [app.demiton.io/auth/register](https://app.demiton.io/auth/register) - 30 seconds, no credit card. You will need a business email address. A free Public tier account is created immediately. 2. **Connect an AI client** - point Claude Desktop or ChatGPT at [Ask Demiton over MCP](/access/mcp-server). Every tier includes MCP access; what changes is the data it can read. 3. **Ask a real question about public civil work** - try *"Who won Queensland road contracts over $5M this year?"*. The answer comes back sourced from AusTender, ABR and BOM, with a citation for every fact. 4. **Decide whether you need your own data in the answer** - the Public tier shows awarded contracts. Open tenders, planning notices and your own uploaded history sit on Insights and above - see the tiers below. Full walkthrough in the [Quickstart →](/start-here/quickstart). For how the app is laid out, see [Navigating the Platform](/getting-started/navigation). --- ## Which tier is right for me? Every price above, and what each tier includes, is kept current at [demiton.io/pricing](https://demiton.io/pricing). Prefer to talk it through? [Contact the team](https://demiton.io/contact?ref=docs-home-tiers). --- ## Start here The platform in full - the surfaces, how the tiers fit together, and what memory scope each unlocks. [Read more →](/overview/platform) The five diseases that erode margin on a civil job, and the register that catches each one. [Read more →](/start-here/diseases) The spine of Demiton: one sourced record of a job from the public market, through the award, into delivery. Why it compounds. [Read more →](/start-here/civil-memory) Create an account, ask your first question in Claude, then decide whether to connect your operation. [Get started →](/start-here/quickstart) ## The product: six surfaces Those six are the product surfaces. The app also carries two configuration surfaces under **Configure**: **Systems** (`/connectors`), where you connect your own systems, and the **Control Room** (`/workflows`), where workflows and runs are managed. See [Navigating the Platform](/getting-started/navigation) for the full map. --- ## Reference Demiton reads. It does not replace. Browse the systems that feed your memory - ERP, field ops, payroll, document stores, and public data. [Browse connectors →](/connectors/overview) Connect Claude or ChatGPT to Demiton. Available on every tier - what changes is the data it can read. [Read more →](/access/mcp-server) A keyed HTTP API for headless and programmatic access to the same data, with the same tier and identity rules. [Read more →](/access/api) Identity-bound by default. Every read and every write resolves against your authoritative systems before anything happens. [Read more →](/security) Questions about scope, integration or procurement? [Talk to the team](https://demiton.io/contact?ref=docs-home-footer). --- ## [PRODUCT_OVERVIEW] What is Demiton Description: The overrun that never happens - what Demiton is, the five diseases it catches, and how the tiers fit together. URL: https://docs.demiton.io/overview/platform/ **{PROMISE}** Rework, missed claims, disputes, cost drift, lapsed compliance - the same five things erode margin on every civil job, and Demiton exists to catch each one before it costs you. See [the five diseases](/start-here/diseases) for how, disease by disease. All five protections run every day, each against the registers that hold its facts, and every fact they run on is one question away in Claude or ChatGPT. **{DEFINITION}** That sentence is the mechanism. Your jobs run through multiple disconnected systems - ERP, field ops, payroll, documents, estimating. Each one holds a partial view, and every handoff loses fidelity. A job ends without anyone capturing what worked, what didn't, who performed, which conditions drove cost - the knowledge leaves with the people who finish the project. Demiton keeps that record. Every job, bound to the workers, projects, estimates, ground conditions and vendors it's about, in one place that persists, accumulates, and informs the next decision - the longer you run jobs through Demiton, the better the next one gets. That record is [Civil Memory](/start-here/civil-memory): one continuous, sourced story of a civil job from the public market, through the award, into delivery - with reporting back to government as the intended next step. Everything else in the platform feeds it or is a lens onto it. --- ## Where to start Not sure which tier fits your situation? Here's the fast path: | Your situation | Where to start | |---|---| | You want to explore with no commitment | [Quickstart](/start-here/quickstart) - free tier, no credit card | | You want your own ERP, field ops, or payroll read and watched | [Baseline - AU$55,000/yr, cover to AU$100M - talk to us](https://demiton.io/contact?ref=docs-platform-baseline) | | You need multi-system integration, custom reports, or bespoke terms | [Enterprise - cover negotiated above AU$100M - contact us](https://demiton.io/contact?ref=docs-platform-enterprise) | Current pricing for every tier is published at [demiton.io/pricing](https://demiton.io/pricing). All tiers serve the same buyer: {BUYER}. What changes between tiers is the data scope - public records, your historical uploads, or your live operational systems. --- ## How you use it Ask Demiton is the universal interface. Every tier reads through it. What changes between tiers is the data scope the MCP can see - public records, your uploaded contracts, or your live integrated systems. You ask Claude or ChatGPT a question. The MCP serves the answer - sourced, identity-filtered, attributable. There is no separate UI to learn. The platform inherits the AI tool you already use. The web app at [app.demiton.io](https://app.demiton.io) is for configuration, audit review, and direct workflow operation. Day-to-day questions - *"which estimator's rates held last quarter?"*, *"who performed best on coastal sand?"* - happen in your AI client. --- ## The product: six surfaces Demiton is six surfaces. Five live in the app; one is the external door through your AI client. [Market](/surfaces/market) and [Memory](/memory/overview) are lenses on the public-to-private life of a job, joined at the award, and [Protection](/start-here/diseases) is where the job's margin is defended. [Studio](/surfaces/studio) and [Ask Demiton](/surfaces/ask-demiton) are the two AI surfaces. [Agents](/surfaces/agents) runs scoped, budgeted tool loops over the whole spine. | Surface | What it is | |---|---| | [Studio](/surfaces/studio) | The in-app AI: ask, and the platform answers with sourced results and reports | | [Market](/surfaces/market) | Discover and pursue public civil work - planning, tenders, awards | | [Protection](/start-here/diseases) | The five diseases that erode margin, caught in the register that already holds the fact. Every tier | | [Memory](/memory/overview) | The whole sourced story, and the seam where a public award becomes your delivery project | | [Agents](/surfaces/agents) | Scoped tool loops that propose org config or produce reviewable artifacts (Insights+). The app labels this page **Agents & ML** | | [Ask Demiton](/surfaces/ask-demiton) | Use Demiton from Claude, ChatGPT, or your IDE over MCP | Those six are the product surfaces. The app also carries two configuration surfaces: **Systems** (`/connectors`), where you connect your own systems, and the **Control Room** (`/workflows`), where workflows and runs are managed. See [Navigating the Platform](/getting-started/navigation) for the full map. The former **Prequalification** (labelled Compliance) and **Projects** surfaces were retired in September 2026; both are now carried by Protection, and their old URLs redirect to `/protection`. For how these fit into one continuous record, see [How your registers become one record](/start-here/civil-memory). --- ## What the platform does ### Reads your stack Demiton reads from estimating, finance, field ops, payroll, document stores, and public data sources through the [connector layer](/connectors/overview). It does not replace any of them. Your systems of record stay where they are. - Per-project P&L from Business Central, refreshed nightly - Budget-to-actual integrity across labour, plant, materials, and subcontract costs - Cross-system identity reconciliation between ERP, field ops, and payroll - Site diaries, allocations, and compliance forms from Assignar - Document retrieval from SharePoint and Dropbox, identity-filtered against the source ACLs ### Reconciles every night Estimates against actuals. Allocations against payroll. Ground-condition variations against the bid. The variance is surfaced - and attributed to the entities it touches - without anyone running a report. ### Compounds memory Every reconciliation, every allocation, every form submission writes a structured record back to the [memory layer](/memory/overview), bound to the canonical worker, project or asset. Records supersede rather than overwrite, so the history is preserved and every question can be answered as at a point in time. What accumulates is your own operation - rates, crews, conditions, subcontractor performance - which is why it cannot be copied from public data or a product demonstration. ### Executes safely Writes back to your systems run through the Workflow Runtime - simulation first, approval second, production third. Every action is identity-bound and recorded in the [audit trail](/security#audit-trail). --- ## Tiers Demiton is a single platform with tiered access. Tiers map to lifecycle reach, not company size or seat count - see [How your registers become one record](/start-here/civil-memory#tiers-are-how-far-along-the-life-you-reach) for how far each tier goes. All paid tiers include unlimited users, and every tier includes MCP access - what changes is the data the MCP can read. | Tier | Price | What it is | |---|---|---| | **Free** | [AU$0](https://demiton.io/pricing) | Protection on your first AU$1M of work under watch, every calendar year. Verified business email required. | | **Baseline** | [AU$55,000/year](https://demiton.io/pricing) | Margin protection, one flat annual fee. Up to AU$100M of work under watch, negotiated above. Protection included. | | **Enterprise** | [Contact us](https://demiton.io/pricing) | Multi-entity consolidation, custom adapters and bespoke terms. Negotiated. | ### Free - [AU$0](https://demiton.io/pricing) The public-data layer, and protection on your first AU$1M of work under watch. Free permanently. Verified business email at signup. - MCP access against AusTender, ABR, BOM, and CKAN OpenData - 10 ad-hoc searches per month, 3 saved watchlists with weekly digest - 100 hosted classifier API calls per month The entry point is [Quickstart](/start-here/quickstart) - real contractor data from AusTender, real entity data from ABR, real weather from BOM, with no credit card required. ### Baseline - [AU$55,000/yr](https://demiton.io/pricing) Margin protection, one flat annual fee. Up to AU$100M of work under watch, negotiated above. Protection is included, not an upgrade. - All five protections, every register - Unlimited systems connected - Your full operational history, kept and compounding - The year-one study: harvest, the identity graph, and what each disease has cost you - A named contact - Supply Nation Certified businesses pay 50%: AU$27,500 a year The margin bonus is 25% of the cash protection recovers, on the first AU$1M recovered in a calendar year and 12.5% above it. There is no dollar cap. It bills on cash actually received, so a catch you are not paid for is not charged, and avoided cost is recorded in the ledger and not billed. The annual fee is reviewed against CPI at each anniversary and can fall as well as rise. Sold directly, not self-serve. [Talk to us](https://demiton.io/contact?ref=baseline) and we set it up. ### Enterprise - [Contact us](https://demiton.io/pricing) For firms requiring 3+ system integrations, custom dashboards and reports, API access, or bespoke contract terms - including Tier-1 head contractors, state agencies, and organisations with more complex procurement structures. Larger firms are Baseline with the cover negotiated above AU$100M. - Full system integration across ERP, field ops, payroll, and document management - Custom reports and dashboards - API access for your own integrations - Dedicated Customer Success Manager and quarterly platform reviews - Phone support [Contact us](https://demiton.io/contact?ref=docs-platform-enterprise) to scope an Enterprise deployment. --- ## Getting started - **Quickstart** - [sign up, ask your first question, connect a system](/start-here/quickstart) - **Navigating the platform** - [the sidebar, the search palette, and the shortcuts](/getting-started/navigation) - **How your registers become one record** - [the spine that ties it all together](/start-here/civil-memory) - **Connect your AI client** - [Ask Demiton over MCP](/access/mcp-server) - **Build against the API** - [programmatic access with an API key](/access/api) - **Talk to sales for Baseline or Enterprise** - [contact us](https://demiton.io/contact?ref=baseline) to scope a deployment --- ## [CORE_CONCEPT] How your registers become one record Description: Civil Memory is the spine of Demiton - one continuous, sourced record of a civil job from the public market through delivery, award to reporting. URL: https://docs.demiton.io/start-here/civil-memory/ **Every job leaves a trail. Civil Memory remembers it. Margins improve.** Civil Memory is the heart of Demiton. It is one continuous, sourced record of a civil job across its whole life - from the moment it appears in a government forward programme, through the open tender, to the award, into delivery on site, and back out as structured reporting to the government client. Everything else in the platform is a way to feed that record or a lens onto it. This is the mechanism behind [the five diseases that erode margin](/start-here/diseases): a fact caught late costs money, a fact in the record the moment it happens doesn't. --- ## One continuous story Most construction software treats the public market and your own delivery as two different worlds. Demiton treats them as one life, joined at the **award**. ``` PUBLIC MARKET THE SEAM YOUR DELIVERY planning -> tender -> award ──► you win ──► deliver -> report to government ``` - **Before the award** you are watching and pursuing public work - planning notices, open tenders, who won what. This is the **Market** surface. - **The award is the seam.** A public contracting process becomes your private delivery project. Linking the two runs through the project-contract-link API today; the in-app declare-win flow is still to come. - **After the award** you deliver the job, reading from your own systems - ERP, field ops, payroll, documents. Reporting the delivery back to the government client is the intended end of the line, not something the platform emits today. Civil Memory is the only place that draws the whole line. It is where you see a pursuit go from "spotted in the pipeline" to "delivered and reported," with every fact attributed to where it came from. Under the hood, the public half is the open [OCDS](/standards/ocds) standard (contracting processes) and the delivery half is [OC4IDS](/standards/oc4ids) (infrastructure projects). You never have to read a standard - they run underneath as the credibility engine. "Civil Memory" is how the work is actually used. See [Conformance](/standards/conformance) for how the platform guarantees it. The award is the seam: a public contracting process becomes your delivery project. Linking the two is implemented on the backend - the project-contract-link API moves a link from pursuing to won - but the in-app declare-win flow is still to come. OC4IDS emission is in the same state. The platform stages an OC4IDS payload for review and stops there; nothing is published to a government client. The consent model exists, but the emission path that would call it does not. Treat both as the direction of travel, not buttons you will find in the app today. --- ## Why it compounds Civil Memory is not a search index of documents. Each fact is a typed, time-valid record, attached to the canonical entity it is about - a worker, a project, an asset - and carrying a citation back to its source. Records accumulate and supersede rather than overwrite, so the history is never lost. That is why memory compounds. Every reconciliation, allocation and form submission adds to the record, and because records supersede rather than overwrite, the history is never lost. What accumulates is specific to how your organisation runs work - your rates, your crews, your ground conditions, your subcontractors - so it is not something a competitor can copy from public data or a product demo. See [Memory](/memory/overview) for the full model - entity anchors, memory types, ACLs, entity briefs, and the knowledge graph. --- ## You reach it chat-first You do not learn a new dashboard to use Civil Memory. You ask for it, in the AI client you already use, through [Ask Demiton](/surfaces/ask-demiton). Open Claude or ChatGPT and ask *"where did my labour rates hold last year?"* or *"who won the contract we lost on the Pacific Highway, and at what price?"* - the answer comes back sourced, identity-filtered, and attributable. The web app at [app.demiton.io](https://app.demiton.io) is where you configure systems, review the audit trail, and work the surfaces directly. The day-to-day questions happen in your AI client. --- ## The surfaces are lenses on memory Demiton is six surfaces. Five live in the app; one is the external door through your AI client. Each one either feeds Civil Memory or reads from it. | Surface | What you do there | Relationship to memory | |---|---|---| | [Studio](/surfaces/studio) | Ask, in the app, and get sourced answers and reports | Reads memory; runs reports over it | | [Market](/surfaces/market) | Discover and pursue public work | Feeds the public half of the spine | | [Protection](/start-here/diseases) | See the five diseases that erode margin, and the project board under cover | Reads the registers the diseases fire on | | [Memory](/memory/overview) | See the whole sourced story - the seam where a public award becomes your delivery project | Civil Memory itself | | [Agents](/surfaces/agents) | Run scoped tool loops that propose config or produce artifacts | Reads memory; producer agents write reviewable output back | | [Ask Demiton](/surfaces/ask-demiton) | Use Demiton from Claude, ChatGPT, or your IDE | Reads memory over the open MCP standard | The former Prequalification and Projects surfaces were retired into Protection in September 2026. --- ## Tiers are how far along the life you reach Demiton's tiers map to lifecycle reach, not company size. Memory deepens as you move along the spine. | Tier | Lifecycle reach | What lights up in memory | |---|---|---| | **Public** | Watch the market (free) | The public award record | | **Insights** | Pursue: planning, tender, bid intelligence | The market half, plus your uploaded history | | **Connected** | Deliver won projects from live systems | The delivery half - live operational memory | | **Enterprise** | Report to government + portfolio | The full spine, with OC4IDS reporting as the intended next step | --- ## Next steps - [What is Demiton](/overview/platform) - the platform in full, and how the tiers fit together - [Quickstart](/start-here/quickstart) - sign up, ask your first question, connect a system - [Memory](/memory/overview) - the detailed memory model - [Ask Demiton](/surfaces/ask-demiton) - connect Claude or ChatGPT --- ## [DOCUMENTATION] Why the diseases are in this order Description: Why rework, cost drift, missed claims (including weather), disputes and lapsed compliance are listed in that order, and where the evidence for each is kept. URL: https://docs.demiton.io/start-here/disease-priority/ The five diseases on the [previous page](/start-here/diseases) are listed in the order published research says they cost a contractor, most first: **rework, cost drift, missed claims, disputes, lapsed compliance.** Weather rolled into missed claims: a wet day the contract's extension-of-time or delay-cost clause doesn't get claimed is exactly a missed claim, not a disease of its own. This page is the argument for that order. **The evidence lives at [research.demiton.io](https://research.demiton.io)**: every figure, the paper or report it came from, where in that document to look, how sure we are, and what it isn't. Anyone can dispute a figure or add a source there, and the same record is on [GitHub](https://github.com/demitonapp/disease-economics). Nothing on this page is a figure you should quote; quote the research page, which says where it came from. Which figure applies depends on where the work is. A rework study from Australian civil projects says something about a Queensland job; a Singapore building study doesn't. So research.demiton.io shows each disease's spread for the state and industry you pick, and Protection applies to each of your projects the nearest evidence for its own location ([the rule](https://github.com/demitonapp/disease-economics/blob/main/METHOD.md#5-which-figure-applies)). Where no evidence applies, it says so rather than borrowing someone else's number. ## How we set the order In September 2026 we ran separate literature searches, one per disease. Each had three rules: only report a figure actually read in the source, say exactly what it's a percentage *of*, and say so plainly when good evidence doesn't exist instead of stretching a weak number. Every figure was then checked a second time against the original source. Where we could only see a figure through someone else's citation, it's marked second-hand. Those searches are now a public record that keeps growing: [how a figure gets in](https://github.com/demitonapp/disease-economics/blob/main/METHOD.md). Where two diseases had similarly strong evidence, we broke the tie by asking which evidence measures money the *contractor itself* loses, rather than money that's merely at stake or mostly borne by someone else. That's why rework sits above cost drift, even though overruns are bigger in dollars. Rework has real measurements of what contractors lose. For most of the rest, researchers have measured *how much is at stake* (how much is claimed, held back or fought over) rather than how much a contractor ends up losing. Every figure on research.demiton.io is labelled contractor loss, money at stake, owner's money or societal, and only the first two are ever applied to your contracts. ## 1. Rework Work done twice: kerbs poured to the wrong level, built off a superseded drawing, redone after a failed test. Rework has **the strongest evidence of the five**, and it points one way: it's common, it's large relative to a civil contractor's margin, and the contractor pays for it. Surveys of Australian civil projects and one contractor's own ledgers agree on that much; they disagree on how big, because most rework is never recorded as rework. [Every rework figure, with its source →](https://research.demiton.io/rework/) ## 2. Cost drift The gap between the price a job was won at and what it actually costs. There's **strong evidence that overruns are large and common**, and that margins are thin enough for a modest one to wipe them out. There's **weak evidence on how much of an overrun the contractor keeps** rather than recovering through variations, and much of the best-known overrun research measures the client's money, not the contractor's. [Every cost drift figure, with its source →](https://research.demiton.io/cost-drift/) ## 3. Missed claims Variations, extensions of time, delay costs and retention the contract allowed and nobody claimed in time. **No study measures the share a contractor never recovers.** The evidence shows how big the pot is, how rarely contractors use the payment protections they're entitled to, and how much is never paid when a business fails. Weather sits here: the evidence is on how many days it takes and what a standing day costs, and on contracts written so the contractor carries most of it. [Every missed claims figure, with its source →](https://research.demiton.io/missed-claims/) ## 4. Disputes Money fought over, what it costs to fight, and how much is recovered. There's **good evidence on how much is at stake and what the fight costs**, mostly from large projects that were already in trouble, and Queensland's own adjudication record. **No verified figure exists for what a dispute costs a contractor as a share of the contract.** [Every disputes figure, with its source →](https://research.demiton.io/disputes/) ## 5. Lapsed compliance Accidents, lapsed licences and insurance, and the cost of breaching the obligations that come with the job. There's **solid national data on what non-compliance costs in total**, and it consistently shows **most of that cost falls on workers and the public, not the employer**. Costs per incident are measured; the cost of losing standing altogether (dropped from a licence, a panel or a prequalification list) isn't. That's why it ranks last on *measured* cost, not on how much it matters. [Every lapsed compliance figure, with its source →](https://research.demiton.io/lapsed-compliance/) ## What this means for you This order is the default. It decides the order the diseases show up in during setup, and the order we build detection for each one. It isn't a claim about *your* business: a contractor with a run of disputed variations, or one heading into a wet season, may reasonably rank them differently. [Setup](/start-here/diseases) lets you put the five in whatever order matters to you. If you find a figure that doesn't match its source, or a better study we missed, [suggest it on research.demiton.io](https://research.demiton.io). ## Next steps - [research.demiton.io](https://research.demiton.io) - every figure, its source, and what it isn't - [The overrun that never happens](/start-here/diseases) - the five diseases and where each lives in the platform - [Register catalog](/concepts/register-catalog) - every register, grouped by domain and by disease --- ## [CORE_CONCEPT] The overrun that never happens. Description: Five things erode margin on a civil job - rework, cost drift, missed claims (including unclaimed wet days), disputes and lapsed compliance. Demiton catches each one in the register that watches for it. All five protections run every day. URL: https://docs.demiton.io/start-here/diseases/ Five things kill margin on a civil job, the same five every time: rework, cost drift, missed claims, disputes and lapsed compliance. Every one of them starts small and gets caught late - after the pour, after the window closes, after the drift has compounded from $50K to $5M. Demiton exists to catch each one where it starts: in the register that already holds the fact, read before the fact turns into a cost. That's the whole platform, from one angle. Every connector, every register, every surface in the rest of this site is doing one of these five jobs. They are listed in the order published research says they cost a contractor, most first. [Why the diseases are in this order](/start-here/disease-priority) sets out the argument, and [research.demiton.io](https://research.demiton.io) keeps every figure with its source. --- ## The five diseases - **Rework**: Work done twice: failed inspections, NCRs, wrong ground assumptions. Protection: The failed result reaches the person who can stop the next stage the day it lands, with the close-out date attached. Today: Every NCR, test result and plant pre-start lands in one register, tied to the location and the crew - so the pattern shows up before the same defect gets poured twice. - **Cost drift**: Cost and programme drift against the tender. Protection: Drift against the price you quoted is flagged at $50K, not $5M. Today: Budget and actual are reconciled every night, by cost code, against the tender you priced - so drift shows up as a number you can query, not a surprise at the next progress claim. - **Missed claims**: Variations and time owed but never claimed: notices missed, time bars closed, wet days never logged. Protection: When the instruction arrives or the rain starts, the clock starts. The notice is drafted and waiting before the window shuts, while the ground is still wet. Today: Every variation, progress claim and contract clause is in one register you can query by project and date, and site diaries carry the weather on the day correlated against Bureau of Meteorology observations for the same location - so a notice window or a wet-weather claim is a question you can ask, not a date buried in an inbox or a claim reconstructed from memory weeks later. - **Disputes**: The claim that became a case. Protection: If the day's record isn't in by evening, you're told which one is missing while people still remember the day. Today: Contract terms, day works dockets and rate verifications sit in one queryable record, and every active project is checked each morning against 125 published evidence standards for its jurisdiction and contract form - met, at risk, missed or unmeasurable. The check runs; it has not yet been proved on a live job. - **Lapsed compliance**: The right to bid itself: panels, prequalification, certificates. Protection: Every expiry counts down at 90, 30 and 7 days, with the renewal attached. Today: Your schemes, classifications and certificate expiry dates are one register you declare once. Company certificate and insurance expiries already count down at 90, 30 and 7 days, with the alert in the app and by email; the countdown has fired end to end in a demo tenant, not yet on a live job. All five protections run every day, each against the registers that hold its facts. Where a register is still empty, the protection says which kind of system would fill it. {ROLLOUT_MARKER} --- ## How this differs from watching a dashboard A dashboard shows you the number after someone builds the report. A register is the fact itself, structured and queryable the moment it lands - a test result, a variation, a day's weather, a certificate's expiry date. The difference matters because every one of these five diseases is a timing problem: the notice that had to be drafted by a date, the drift that was cheap to fix at $50K and expensive at $5M, the panel that checks your certification before you know it lapsed. Demiton reads the registers every night against the systems you run - see [What the platform does](/overview/platform#what-the-platform-does) - so the fact is there to ask about before the deadline, not after. Demiton now runs a check for each of the five diseases every day: non-compliance and missed claims and disputes run theirs every morning, and rework and the baseline overrun alongside them. The fact is still one query away, in Claude or ChatGPT, the moment you think to ask it. --- ## Where each disease lives in the platform - **Rework and lapsed compliance** show up first in Protection's lapsed compliance disease and the safety and compliance registers - the standing that keeps you eligible to bid, and the site records that keep the work right the first time. - **Missed claims and disputes** live in the contract registers - variations, progress claims, day works dockets - reachable from [Memory](/memory/overview) and Protection's project board. Weather is part of missed claims: [Site diary](/connectors/operational/assignar) records correlated against [Bureau of Meteorology](/connectors/intelligence/bom-weather) observations for the same site, so a rain day is a claim like any other. - **Cost drift** is the nightly reconciliation described in [What is Demiton](/overview/platform) - budget against actual, by cost code, against the tender you priced. See every register that touches any of the five in the [register catalog](/concepts/register-catalog#grouped-by-disease). --- ## Next steps - [Why the diseases are in this order](/start-here/disease-priority) - the argument for the order - [research.demiton.io](https://research.demiton.io) - what each one costs a contractor, every figure with its source - [Register catalog](/concepts/register-catalog) - every register, grouped by domain and by disease - [How your registers become one record](/start-here/civil-memory) - the spine that ties them into one story - [Quickstart](/start-here/quickstart) - ask a real question in a few minutes --- ## [HOW_TO_GUIDE] Quickstart Description: Start free - create an account, connect Claude or ChatGPT, and ask a real question about Australian public civil construction contracts. URL: https://docs.demiton.io/start-here/quickstart/ You can be asking Demiton real questions in a few minutes, on the free tier. No SQL, no dashboards, no training sessions, no credit card. ## 1. Create your account [app.demiton.io/auth/register](https://app.demiton.io/auth/register) - 30 seconds. A verified business email gets you the free tier immediately. ## 2. Connect your AI client Connect Claude Desktop or ChatGPT to [Ask Demiton over MCP](/access/mcp-server). Every plan includes MCP access - on the free tier it reads AusTender, ABR, BOM and CKAN open data. ## 3. Ask a real question Try: > *"Who won Queensland road contracts over $5M this year?"* The answer comes back sourced from AusTender award records, with a citation for every fact - not invented. Ask a few in a row and watch how the results narrow as you name a region, a buyer or a value band. ## 4. Decide whether you need your own data in the answer The free tier covers **awarded** contracts and puts your first **AU$1M** of work under watch. Open tenders, forward planning and your own operational records are not in scope on Free. When you want your own systems read - ERP, field ops, payroll, documents - that is [Baseline](https://demiton.io/pricing): **AU$55,000 a year**, cover to **AU$100M** of work under watch, protection included, and a named contact. Sold directly rather than self-serve. See [Connecting a System](/getting-started/connecting-a-system), or [talk to us](https://demiton.io/contact?ref=baseline). --- **Next, free:** [Navigating the Platform](/getting-started/navigation) to find your way around the app, or [How your registers become one record](/start-here/civil-memory) for why the record compounds. **Ready for your own data?** [Start the 14-day Insights trial](https://demiton.io/insights?ref=docs-quickstart) - no credit card, no implementation fee. **Want to talk it through first?** [Contact the team](https://demiton.io/contact?ref=docs-quickstart). --- ## [CORE_CONCEPT] Agent types (probe and producer) Description: The probe/producer taxonomy behind Demiton's Agents surface: why scoped, budgeted tool loops either only propose or write reviewable output. URL: https://docs.demiton.io/concepts/agents/ An agent is a scoped, budgeted tool loop: it has a defined goal, a budget on how much reasoning and tool-calling it can spend, and it reads [Civil Memory](/start-here/civil-memory) the same way any other reader does. This page is the taxonomy behind the [Agents surface](/surfaces/agents) - why agents are built the way they are, not just what the UI shows you. What separates one agent from another is what it is allowed to do with what it finds. --- ## Probe agents propose, never write A probe agent owns one axis of your organisation's configuration - who a worker's identity resolves to across systems, or what a document's geography implies about which project it belongs to. When a probe reaches a conclusion, that conclusion becomes a pending change in your approvals queue. It is never written directly. This matters because a probe's job is inference over incomplete or ambiguous signals - exactly the kind of reasoning that benefits from a human's final say before it becomes the organisation's stated configuration. A probe can also re-run itself when the underlying data drifts, proposing an update rather than silently going stale. ## Producer agents consume approved config and write reviewable output A producer agent runs against configuration that's already been approved - it doesn't re-litigate your organisation's setup, it uses it. Its output is a reviewable artifact: a drawing-quantity measurement checked against a schedule of rates, or a cited launch brief for a tender response. The output sits in a reviewable state until someone looks at it - it's a proposal to be checked, not a fact silently added to the record. Both categories exist because the alternative - letting a reasoning loop write straight into memory or straight into organisation config - trades a small amount of friction for the possibility of silent, hard-to-trace drift. Every agent's output is inspectable before it's trusted: a probe's proposal sits in the approvals queue, a producer's output sits in its run detail page. --- ## Next steps - [Agents (surface)](/surfaces/agents) - where to find and run agents in the app - [Registers](/concepts/registers) and [Ingest groups](/concepts/ingest-groups) - what agents read from and, for producers, write back through --- ## [CORE_CONCEPT] Ingest groups Description: An ingest group is the pipe that writes facts into Civil Memory, carrying the routing, entitlement and provenance rules for every record it writes. URL: https://docs.demiton.io/concepts/ingest-groups/ A disease can only be caught as early as its fact reaches the register. When a test result or a variation lands on time and says where it came from, the [five diseases](/start-here/diseases) are caught while they are still cheap. The ingest group is the pipe that gets it there. An ingest group is how a fact actually gets recorded. Every connector that reads from your ERP, every field-ops harvester, every document extraction, and every computed reconciliation writes into [Civil Memory](/start-here/civil-memory) through an ingest group. It's the pipe - as distinct from the [register](/concepts/registers), which is the product the pipe fills. Ingest groups were previously called **conduits**. Same concept, clearer name. Old links and names still resolve. --- ## What travels with an ingest group An ingest group is more than a data path. It's the single place the platform records: - **Entitlement** - which tier, and which of your organisation's permissions, are required for this data to flow at all - **Provenance** - where the fact came from, stamped on every record it writes - **Routing** - which register, or registers, it feeds Because these properties live on the ingest group rather than scattered across individual writes, a fact's origin and the rules that approved it are never ambiguous after the fact. --- ## One register, several ingest groups A register can be filled by more than one ingest group. A register has one **owner** ingest group - the primary source, which sets the shared rules other contributors must agree to - and can have any number of **contributor** ingest groups layering additional facts on top. A document-extraction pipeline can, for instance, backfill a register that a structured form submission normally owns. When you ask for that register, you see facts from every ingest group that feeds it, not just the owner. If [registers](/concepts/registers) answer "what am I asking for," ingest groups answer "how did this get here, and was it allowed to." You rarely need to name an ingest group directly - it's what the platform resolves once you name a register. --- ## Next steps - [Registers](/concepts/registers) - the product an ingest group fills - [Connectors](/connectors/overview) - the systems most ingest groups read from - [Agents](/concepts/agents) - producer agents write to memory the same way an ingest group does --- ## [DOCUMENTATION] What is an obligation, and how does it become a protection? Description: An obligation is one duty a published document places on you for a job, with its clause, its window and what happens if you miss it. Where they come from, where the public library lives, how to propose one, and what Demiton does not promise. URL: https://docs.demiton.io/concepts/obligations/ An obligation is one duty a published document places on you for one job, with its clause, its window and what happens if you miss it. Section 76 of Queensland's Building Industry Fairness (Security of Payment) Act 2017 is one: after you serve a payment claim, the principal has 15 business days to give you a payment schedule, and if it does not, the full claimed amount becomes payable. Demiton reads your payment claims against that window, so a schedule that has not arrived is flagged on business day 16, not discovered at adjudication. Every obligation guards against one of the [five diseases](/start-here/diseases). The s 76 window guards against disputes. A missed extension-of-time notice under AS 4000 guards against missed claims. A late Taxable Payments Annual Report guards against lapsed compliance. --- ## From a document to a protection Reading order: one example per row, read left to right; each arrow names what the step produces, and the disease the protection guards against is in brackets. Every row is a real entry in the obligation library. ``` SOURCE INSTRUMENT OBLIGATION PROTECTION Contract AS 4000-1997 --states--> claim an EOT within 28 days --arms--> Watch cl 34.2 of the delay starting (missed claims) Law BIF Act 2017 (Qld) --states--> a payment schedule within 15 --arms--> Watch s 76 business days of a claim (disputes) Law Taxation Administration --states--> lodge the TPAR by 28 August --arms--> Countdown Act 1953 (Cth), Sch 1 each year (lapsed compliance) Principal TMR MRTS50 --states--> hand over as-constructed --arms--> Check cl 11.2 records within 12 months (rework) ``` Four words carry this page: - An **instrument** is one published document: an Act, a regulation, a contract form, a principal's specification, a permit. - An **obligation** is one duty that instrument places on you, with its clause, its window and its consequence. - A **protection** is one obligation switched on for one of your jobs. Each protection runs daily from the day you switch it on. - The **protection type** is how Demiton runs it. There are four, listed below. A protection that cannot run yet says why: the register it reads is empty, and it names the kind of system that would fill it ("your finance system") before any vendor. --- ## The seven sources Every duty on a job comes from one of seven places. When you add a job, its obligations are grouped by these seven, and each source shows the instruments that apply to that job and why ("The site is in Queensland", "Commonwealth law applies across Australia"). | Source | What it holds | Example in the library | |---|---|---| | **Contract** | The contract form you signed and its amendments. Demiton reads the conditions and every dated window. | AS 4000-1997, NZS 3910:2013, GC21 | | **Law** | Statute and regulation where the site is, and Commonwealth or national law that applies everywhere. | BIF Act 2017 (Qld), Construction Contracts Act 2002 (NZ) | | **Principal** | Your client's own specifications and conditions, which apply because that principal is on the job. | TMR MRTS50, Auckland Transport's NZS 3910 special conditions | | **Approvals** | The permits and consents this site holds. | None in the library yet | | **Counterparties** | Funders, landowners, utilities and other parties whose terms bind the job. | None in the library yet | | **Workforce** | Awards and agreements that cover the crew. | None in the library yet | | **Your own commitments** | Certifications and protocols you have committed to yourself. | Society of Construction Law Delay and Disruption Protocol | A standard such as AS, ISO or an MRTS is not a source of its own. A standard binds a job only because a contract or a principal calls it up, so it enters through that source. --- ## The four protection types | Type | What Demiton does | Example | |---|---|---| | **Watch** | Waits for the event that opens a window, then tracks the deadline. | A payment claim is served; the 15 business days for a schedule start. | | **Countdown** | Counts down to a fixed date, flagged at 90, 30 and 7 days. | The TPAR due on 28 August. | | **Check** | Looks for evidence that must exist, on a cadence. | As-constructed records held before the 12-month handover. | | **Threshold** | Tracks a measure against the line it must not cross. | Cost to date against the tender budget. The library holds no threshold obligation yet. | The type and the disease are set separately. A watch can guard against disputes or missed claims; what decides the disease is what the missed duty costs you. --- ## Where the obligation library lives The library is public, in the [demitonapp/registers](https://github.com/demitonapp/registers) repository on GitHub. Each instrument is one file, filed under the place it binds (Queensland law under `AU-QLD`, Commonwealth law under `AU`), and every obligation in it carries a primary citation: the URL of the instrument, the clause, and the date it was read. Anyone can read it, and the product reads the same files. The repository publishes public instruments only. Your contract, your amendments and any obligation you add to your own job are never published there; they stay in your organisation's record. --- ## Where the library is thin On 30 September 2026 the library held 247 obligations from 70 instruments. They are not spread evenly: - **By source:** law 133, contract 60, principal 33, approvals 14, your own commitments 6, workforce 1. Counterparties holds none yet: an insurer's notification clause lives in the policy a particular organisation holds, not in a published instrument. - **By place:** New South Wales 45, Queensland 40, Western Australia 20, the ACT 15, Victoria 14, South Australia 12, Tasmania 11, the Northern Territory 9. Commonwealth law adds 32 to every Australian job. New Zealand national instruments hold 48; of the 17 regions, only Auckland holds its own (1). When you add a job, Demiton states how many obligations the library holds for that job's place, and says plainly when that is few. A job in the Northern Territory draws 9 obligations from Northern Territory instruments against 45 in New South Wales, and the screen says so. The current count for every state and region is on the [obligation library by place](https://research.demiton.io/obligations/) page. The library holds what it holds. Demiton never says the list is complete, and an obligation the library does not hold, and you did not add, is not protected. No library of law is complete, so Demiton promises the protections you switched on, not the ones nobody wrote down. This is not legal advice. --- ## Adding an obligation the library does not hold You know your jobs better than the library does. There are two ways to close a gap: - **For your job only.** Add the obligation to the job as a private obligation, with its clause and window. It is protected from that day, and it never leaves your organisation. - **For everyone.** If the obligation comes from a public instrument (an Act, a regulation, a published specification), propose it to the library: open an issue or a pull request on [demitonapp/registers](https://github.com/demitonapp/registers) with the instrument, the clause and a link to the source. Demiton reviews every obligation before it merges, and it reaches every customer on the next library release. Not on GitHub? Send it to us and we will raise it. --- ## What runs today The library is live: the daily disputes check reads it. The screen where you add a job, see its obligations source by source, add a private one and switch each one on is being built, along with the in-app action that proposes an obligation to the library. Until that screen ships, the five daily checks run as they do now, and this page describes what that screen does. --- ## Next steps - [The five diseases](/start-here/diseases) - what each obligation guards against - [What a register is](/concepts/registers) - the record a protection reads - [Glossary](/glossary) - obligation, instrument, source, protection and the rest in one place --- ## [REFERENCE] Register catalog Description: Every register in Civil Memory, grouped by domain - each with a published contract, from site diaries and timesheets to tender notices and weather. URL: https://docs.demiton.io/concepts/register-catalog/ Demiton fills your registers from the systems you already run, in a published format. Every [register](/concepts/registers) in Civil Memory is grouped by domain below: every register has a [published contract](/registers) except one - `document_list` - which is live but not yet published. The [contract index](/registers) carries the live count. Ask for any of them by name through [Studio](/surfaces/studio) or [Ask Demiton](/surfaces/ask-demiton). ## Grouped by disease The registers below also group under the five problems Demiton exists to catch before they cost you money - the same taxonomy that appears across the platform, not just in this catalog. See [The overrun that never happens](/start-here/diseases) for what each register gives you today. | Disease | What it is | Registers that watch for it | |---|---|---| | **Rework** | Work done twice: failed inspections, NCRs, wrong ground assumptions | `safety_ncr`, `inspection_test_result`, `site_inspection`, `plant_prestart` | | **Missed claims** | Variations and time owed but never claimed: notices missed, time bars closed, wet days never logged | `variations`, `change_event`, `progress_claim`, `contract_terms`, `payment_schedule`, `site_diary` | | **Disputes** | The claim that became a case | `contract_terms`, `sor_verification`, `day_works_docket`, `rfi` | | **Cost drift** | Cost and programme drift against the tender | `budget_vs_actual`, `job_budget`, `tendered_budget`, `cost_element`, `project_performance_record` | | **Lapsed compliance** | The right to bid itself: panels, prequalification, certificates | `compliance_certifications`, `compliance_prequal`, `compliance_state`, `prequalification_answer`, `certification_register` | This is illustrative, not exhaustive - most registers below touch more than one disease, and the domain tables are the complete list. ## Status and kind | Status | Means | Registers | |---|---|---| | **Available** | Filled today from connected systems, uploads or Demiton's own public data | 96 | | **Declared** | Defined and written by Demiton, and fills as soon as a source or feature produces its first record | 31 | | **Planned** | Defined as a contract, ahead of the connector that will fill it | 28 | | **Live - no contract yet** | Filled today from connected systems, but with no published contract to read | 1 | **Kind** says what one record on the register is: an **Event** happened at a point in time, a **State** is the current value of something, and a **Procedure** is a rule or method Demiton follows. Four registers carry a colon in their ID: `document_location:asset`, `document_location:opportunity`, `document_location:project`, and `overstaffing_verdict:overstaffing_verdict`. Their [contract URLs](/registers) replace the colon with a double dash, so `document_location:asset` is published at `/registers/document_location--asset`. --- ## Counterparties The people and organisations you deal with: customers, suppliers, subcontractors, your own companies and users. 13 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `bank_accounts` | Bank accounts registered in your ERP. | State | Available | | `customer_list` | Customers registered in your ERP. | State | Available | | `entity_attribute` | One key/value attribute on a project, worker, asset or other entity, such as a project's stage. | State | Declared | | `entity_link_origin` | Where a record's link to an opportunity or customer came from in your CRM or ERP. | State | Available | | `group_members` | Members of each group in your identity directory. | State | Declared | | `legal_entities` | The operating companies in your group: the root every worker, project and cost code belongs to. | State | Available | | `payable_entry` | Outstanding supplier bills and the aged payables balance. | Event | Available | | `receivable_entry` | Outstanding customer invoices and the aged receivables balance. | Event | Available | | `subcontractor_list` | Subcontractors engaged on your projects. | State | Available | | `user_list` | Users in your identity directory and operational systems. | State | Available | | `vendor_list` | Vendors and suppliers registered in your ERP. | State | Available | | `bank_guarantee` | Bank guarantees and other security instruments given or held under a contract. | - | Planned | | `insurance_certificate` | A counterparty's certificates of currency, which gate site access. | - | Planned | --- ## Workforce Your people: who they are, what they're qualified for, and their leave. 14 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `competency_verification` | Verification-of-competency assessments per worker. | Event | Available | | `employee_contact_detail` | Employee contact and emergency-contact details from payroll. Readable only by roles permitted to see personal information. | Event | Available | | `employee_hr_records` | HR record events for a worker: leave, disciplinary action, personnel file changes. | Event | Available | | `employee_list` | Employees registered in your payroll system. | State | Available | | `health_screening` | Fitness-for-work and fatigue screening results, by worker and project. | Event | Available | | `induction_onboarding` | Site induction and onboarding acknowledgements. | Event | Available | | `leave_balance` | Current leave balances per employee and leave category. | Event | Available | | `leave_category_list` | Leave types defined in your payroll and operational systems. | State | Available | | `leave_request` | Leave requests and their approval status. | Event | Available | | `policy_acknowledgements` | A worker's sign-off that a policy or procedure was read and accepted. | Event | Available | | `training_records` | Training logs and training requests, by worker. | Event | Available | | `worker_qualification` | Competencies, certificates and licences held by workers: rigging, EWP, first aid and so on. | Event | Available | | `attendance_record` | Who actually attended site, and when, as distinct from planned allocation. | - | Planned | | `certification_register` | Worker credentials and their expiry, as safety and site-access systems hold them. | - | Planned | --- ## Payroll Timesheets, pay runs and the codes behind them. 6 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `expense_claims` | Employee expense claims, by worker and period. | Event | Available | | `pay_categories` | Pay category definitions, with rates and award mappings. | State | Available | | `payroll_run` | Completed pay runs with gross and net totals. | Event | Available | | `timesheet_code_list` | Timesheet and pay codes: award codes, allowances and the like. | State | Available | | `timesheet_entry` | Timesheet submissions, with hours by date and pay category. | Event | Available | | `superannuation_fund` | Superannuation funds and fund products employees are paid into. | - | Planned | --- ## Safety Incidents, inspections, prestarts and the compliance record, held as one system the way ISO 45001 treats it. 17 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `compliance_certifications` | Your organisation's compliance certificates: prequalifications, ISO certifications, statutory registrations. | Event | Available | | `compliance_documents` | Safety and compliance documents attached to projects or workers. | Event | Available | | `compliance_evidence` | Evidence backing a compliance record: certificates, audit reports, licences. | State | Declared | | `compliance_prequal` | A counterparty's prequalification under a scheme, used to judge subcontractor or supplier eligibility. | State | Declared | | `compliance_state` | Current compliance status for one area of a legal entity: a scheme, obligation or requirement. | State | Declared | | `plant_prestart` | Daily plant and equipment pre-start checks: condition, defects, compliance. | Event | Available | | `plant_risk_assessment` | Plant and equipment risk assessments. | Event | Available | | `safety_incident` | Safety incidents and near misses on site. | Event | Available | | `safety_ncr` | Non-conformance reports raised on site, for quality and safety. | Event | Available | | `site_inspection` | Vehicle and plant inspection checklists. | Event | Available | | `toolbox_talk` | Toolbox talks and pre-work safety meetings. | Event | Available | | `permit_to_work` | Permits controlling hazardous work. | - | Planned | | `environmental_observation` | Environmental observations on site: dust, noise, water, spills. | - | Planned | | `inspection_test_result` | Soil and concrete test results (AS 1289, AS 1012). | Event | Declared | | `environmental_aspect` | The environmental aspects and impacts register an ISO 14001 system keeps. | - | Planned | | `asbestos_register` | The asbestos register work health and safety regulations require. | - | Planned | | `prequalification_answer` | Your answers to a prequalification questionnaire. | - | Planned | --- ## Contracts The commercial instrument: claims, retention, variations and the terms behind them. 12 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `contract_link` | A verified link from one of your projects to a public government contracting record. | State | Declared | | `contract_terms` | Commercial terms extracted from each contract document: payment terms, retention, notice windows, and liquidated damages (contract-wide and per milestone). | State | Declared | | `day_works_docket` | Day works dockets for extra or variation work. | Event | Available | | `progress_claim` | Progress claims issued per project: claimed, certified, paid and retention held. | Event | Available | | `retention_position` | Retention currently withheld on a job, and its status. | State | Available | | `sor_verification` | A client's schedule of rates checked against the tender drawings by independent measurement. | State | Available | | `sor_verification_tendered` | The same schedule-of-rates check run on tendered jobs, compared against your own submitted rates. | State | Available | | `variations` | Approved contract variations: scope change, value and approval status. | State | Declared | | `subcontract` | The subcontract itself: the instrument, not the subcontractor or the claim. | - | Planned | | `change_event` | The early warning of a potential change, before it is priced as a variation. | - | Planned | | `payment_schedule` | The payment schedule answering a progress claim under Security of Payment legislation. | - | Planned | --- ## Projects What happens on a job: diaries, programmes, milestones and outcomes. 24 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `construction_methodology` | Work method statements and construction methodology held as reference for a project. | Procedure | Available | | `diary_photo_observation` | What a site diary photo shows (subject, work type, quality, concerns), read from the image. | Event | Declared | | `job_progress` | Job progress from your ERP: percent complete and percent invoiced. | State | Available | | `margin_driver_contribution` | Predicted contribution of each cost or revenue driver to a project's margin, by period. | Event | Declared | | `margin_watch_learning` | Lessons and observability gaps Margin Watch has found on a project, awaiting review. | State | Declared | | `portal_document` | Documents downloaded from a client or tender portal, by project. | Event | Declared | | `programme` | A construction programme extracted from an uploaded schedule document. | State | Available | | `project_details` | Details of active and completed projects from your operational and ERP systems. | State | Available | | `project_list` | Active and completed projects from your operational and ERP systems. | State | Available | | `project_milestone` | Delivery milestones: planned and actual dates for practical completion, defects liability and other key dates. | State | Declared | | `project_outcome` | A project's actual financial outcome at close-out or a reporting point. | Event | Declared | | `project_performance_record` | A project's performance summary for a period: margin, schedule and quality signals. | State | Declared | | `site_activity` | Daily site activity: crew, plant and progress. | Event | Declared | | `site_bore_reference` | Borehole records referenced for a site. | State | Declared | | `site_diary` | Daily site diaries: delays, weather, productivity, variations. | Event | Available | | `site_geology` | Ground conditions and geology recorded for a site. | State | Declared | | `site_requisitions` | Site requisitions for materials, plant or resources, by worker and project. | Event | Available | | `utility_location` | Subsurface utilities on a site, with their AS 5488 quality level. | - | Planned | | `daily_log` | A structured daily log, distinct from a form-shaped site diary. | - | Planned | | `rfi` | Requests for information, with status, response and cost or schedule impact. | - | Planned | | `drawing_register` | The drawing register: each drawing, its revision and status. | - | Planned | | `punch_list` | Completion defects to close out before handover. | - | Planned | | `traffic_management_plan` | Traffic management plans (AS 1742.3). | - | Planned | | `survey_control` | Survey control marks in GDA2020 / MGA2020. | - | Planned | --- ## Assets Plant, vehicles and equipment: where they are, how they're used, and what they cost to run. 19 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `allocation` | Who and what is rostered on which job, and when. | Event | Available | | `asset_disposal` | Plant and equipment written off, sold or scrapped. | Event | Available | | `asset_utilisation` | Engine hours and utilisation for plant and equipment. | Event | Available | | `driving_behaviour_event` | Harsh braking, acceleration and cornering events from telematics. | Event | Available | | `equipment_assignment` | Current and past equipment assignments to projects and sites. | Event | Available | | `equipment_list` | The plant and equipment register across your operational systems. | State | Available | | `equipment_transfer` | Plant and equipment moves between sites. | Event | Available | | `fixed_asset_list` | Fixed assets from your ERP, with cost, book value and depreciation. | State | Available | | `gps_event` | GPS events: ignition, speed, geofence crossings. | Event | Available | | `hilti_location` | Where a tool tracked in Hilti ON!Track is located. | State | Declared | | `maintenance_record` | Plant service and maintenance records. | Event | Available | | `plant_fuel_usage` | Plant and vehicle fuel usage per project, for fuel tax credit claims. | Event | Available | | `plant_snapshot` | The plant register at a project location at a point in time. | Event | Declared | | `speeding_event` | Speeding events from telematics. | Event | Available | | `vehicle_list` | Vehicles registered in your telematics system. | State | Available | | `vehicle_location` | Last-known GPS position of each vehicle. | Event | Available | | `fuel_transaction` | Individual fuel purchases and fills from fleet systems. | - | Planned | | `asset_meter_reading` | Odometer and engine-hour readings, as recorded. | - | Planned | | `plant_registration` | Plant item registrations (AS 2550 item registers). | - | Planned | --- ## Financials The ledger: journals, job costs, budgets, purchasing and invoices. 16 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `budget_vs_actual` | Budget against actual spend for the organisation, by expense category. | State | Declared | | `cash_position` | Current cash balances across bank accounts. | State | Available | | `chart_of_accounts` | Your general ledger accounts. | State | Available | | `cost_element` | Posted job cost lines from your ERP job ledger. | Event | Available | | `dimension_set_entry` | The finance dimension values (such as equipment) attached to ERP postings. | Event | Available | | `financial_period_list` | Accounting periods from your ERP. | State | Available | | `gl_journal_entry` | General ledger journal entries: payroll, payables, receivables and manual postings. | Event | Available | | `invoice_issued` | Invoices your organisation has issued to customers. | Event | Available | | `job_budget` | Job budgets per project, by expense category. | State | Available | | `profit_and_loss` | Profit and loss for a period. | State | Available | | `purchase_line` | Job-linked purchase order and invoice lines. | Event | Available | | `purchase_order` | Purchase orders raised against suppliers: committed spend not yet posted. | Event | Available | | `trial_balance` | Debit and credit balance per general ledger account. | Event | Available | | `work_activity_categories` | Job tasks normalised to a standard work activity taxonomy: piling, anchors and so on. | State | Available | | `credit_note` | Credit notes issued against invoices. | - | Planned | | `intercompany_transaction` | Transactions between companies in your group, for elimination on consolidation. | - | Planned | --- ## Opportunities Winning work: pipeline, tenders, estimates and the verdicts that inform a bid. 16 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `bid_no_bid_verdict` | A bid/no-bid verdict for an open tender, weighing your prequalifications and certifications against its requirements. | Event | Available | | `estimating_email` | Emails in your estimating mailbox, filed against the opportunity they concern. | Event | Available | | `market_intelligence` | Demand, competition and pricing signals for a sector or region. | State | Declared | | `opportunities` | Your commercial pipeline: won, lost and in-flight opportunities from CRM or ERP. | State | Available | | `opportunity` | Changes to a pipeline opportunity over time. | Event | Available | | `opportunity_specifications` | Technical and scope specifications extracted from an opportunity's tender documents. | State | Available | | `opportunity_win_probability` | Predicted probability of winning a pipeline opportunity. | Event | Declared | | `overstaffing_verdict` | Whether a project's actual crew exceeds its tendered labour schedule. | State | Declared | | `overstaffing_verdict:overstaffing_verdict` | Per-project instances of the overstaffing verdict. | State | Declared | | `tender_baseline_active` | Which tender baseline is the current reference for a project. | State | Declared | | `tender_brief` | A cited brief on a tender: everything known about it and how you are placed to pursue it. | State | Declared | | `tender_incoming` | Client-issued documents for a tender you are estimating: brief, scope, pricing schedule. | State | Available | | `tender_submission` | Tenders you have already submitted: scope, pricing and outcome. | State | Available | | `tendered_budget` | Tendered budget lines across all cost categories, from the winning estimate. | State | Available | | `tendered_rate_observation` | One priced line from a tender you submitted: item, unit, rate and quantity. | Event | Available | | `tender_addendum` | Addenda issued during a tender, each of which changes what is being priced. | - | Planned | --- ## Documents Where documents live and how they move. 7 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `document_list` | Documents and files in your connected storage. Live, bound to connected storage, but with no published contract yet. | State | Live - no contract yet | | `document_location` | Where an entity's source documents live: a SharePoint or Dropbox folder. | State | Declared | | `document_location:asset` | The document folder bound to a plant or equipment asset. | State | Declared | | `document_location:opportunity` | The document folder bound to a tender or opportunity. | State | Available | | `document_location:project` | The document folder bound to a project. | State | Available | | `dropbox_document_routing` | Your rules for routing an incoming Dropbox document to the right folder. | Procedure | Available | | `document_transmittal` | Transmittals recording which documents went to whom, and when. | - | Planned | --- ## Platform Public data Demiton maintains for every organisation (the `platform_*` registers), plus your workspace's own configuration. 12 registers. | Register | What it holds | Kind | Status | |---|---|---|---| | `extraction_procedure` | How a document type is parsed into structured facts. | Procedure | Available | | `memory_recall` | Conclusions Ask Demiton and your workflows have written back to memory. | Event | Available | | `platform_award` | Awarded government civil contracts, from AusTender and state sources. | Event | Available | | `platform_contractor_stats` | Per-contractor statistics rolled up from awarded contracts. | State | Available | | `platform_entity_attr` | ABR registration details for a contractor ABN. | State | Available | | `platform_planning` | Forward programme and works-to-tender notices from government pipelines. | Event | Available | | `platform_prequal` | A contractor's status on government prequalification registers. | Event | Available | | `platform_rate` | Economic series: RBA cash and lending rates, ABS price and wage indices. | State | Available | | `platform_tender` | Open government civil tender notices. | Event | Available | | `platform_weather` | Current Bureau of Meteorology observations by region. | Event | Available | | `document_filing_convention` | Your conventions for where each document type is expected to live. | State | Available | | `platform_geofence` | Geofence zones that give GPS positions their meaning. | - | Planned | --- ## Next steps - [Register contracts](/registers) - the fields, requiredness and an example record for each published contract - [Registers](/concepts/registers) - what a register is, and why it is not the system that fills it - [Ingest groups](/concepts/ingest-groups) - the pipe that fills a register - [Connectors](/connectors/overview) - the systems that feed them --- ## [CORE_CONCEPT] Registers Description: A register is one kind of record kept in Civil Memory - site diaries, safety incidents, budget lines - regardless of which system produced it. URL: https://docs.demiton.io/concepts/registers/ Every one of the [five diseases](/start-here/diseases) starts as a fact on a register: the failed test result, the variation notice, the missing diary day, the budget line drifting from the tender, the certificate expiry. Demiton catches a disease where that fact lands, so the register is where prevention happens. [All registers](/concepts/register-catalog#grouped-by-disease) groups them by the disease they feed. A register is what you're actually asking for. Every kind of record in [Civil Memory](/start-here/civil-memory) - a site diary entry, a safety incident, a budget line, a supplier rating - is kept on a register. It is the same idea as the plant register, drawing register or NCR register a contractor already keeps: one kind of record, in one agreed format. A register holds what happened; an [obligation](/concepts/obligations) is what a job owes. The deadline a protection watches comes from an obligation, and the fact that shows it was met lands on a register. The obligations themselves are public, one file per Act, contract form or specification, in the [obligation library on GitHub](https://github.com/demitonapp/registers). When you ask a question through [Studio](/surfaces/studio) or [Ask Demiton](/surfaces/ask-demiton), you're naming a register: "safety incidents," "budget vs actual," "site diaries." You don't need to know, or care, which system produced the underlying record. Every register has a published [contract](/registers) that says what one record on it holds. --- ## Why the register, not the system Before this model existed, a request named the pipe that wrote the data, not the record it produced. That worked as long as one register had one writer. It broke as the platform grew for reasons that show up as real product limits if left unfixed: - **More than one system can feed the same register.** If your organisation runs Business Central for one contract type and Xero for another, "job cost elements" should mean the same thing regardless of which ERP produced it. A request that names the writer instead of the record can't express that. - **Delivery is a server decision, not a caller decision.** Whether a fact is served from a cache, computed live, or read straight off a table shouldn't change what you ask for. - **The name should describe the record, not the plumbing.** "Safety incidents" is what you mean. The mechanism that got the incident into memory is an implementation detail. A register is deliberately not the same thing as an [ingest group](/concepts/ingest-groups) - the pipe that writes to it. Keeping the two separate is what makes both problems solvable independently. The API and the MCP tools call a register a **shelf**. The `shelf` parameter on Ask Demiton takes a register ID such as `site_diary`, and the contract schema key is `x-demiton-shelf-type`. The app itself says "register." A few register IDs contain a colon - `document_location:asset` - while the published contract URL replaces it with `--`. The word differs; the thing is the same. Registers and [ingest groups](/concepts/ingest-groups) together replace what used to be a single "Capability" concept. Every capability-named thing was really either a record you ask for (now a register) or a pipe (now an ingest group, previously called a conduit). Nothing you built against the old name broke - it still resolves, just to more precise underlying vocabulary. --- ## Next steps - [Register catalog](/concepts/register-catalog) - every register, grouped by domain - [Register contracts](/registers) - the fields, requiredness and an example record for each register - [Ingest groups](/concepts/ingest-groups) - the pipe that fills a register - [Obligations](/concepts/obligations) - the duties a protection holds a job to, and the public library they come from - [Agents](/concepts/agents) - agents read registers the same way Studio and Ask Demiton do - [How your registers become one record](/start-here/civil-memory) - the record registers are drawn from --- ## [PRODUCT_SURFACE] Agents - scoped reasoning loops Description: Agents are scoped, budgeted tool loops that reason over Civil Memory and deliver a cited artifact or a proposed configuration change. URL: https://docs.demiton.io/surfaces/agents/ Agents are scoped, budgeted tool loops that reason over [Civil Memory](/start-here/civil-memory) and deliver a result on their run - either a citation-rich artifact or a proposed change to your organisation's configuration. They sit alongside Workflows (deterministic verb graphs you configure once and run repeatedly) and [Studio](/surfaces/studio) (ad-hoc chat): an agent is a bounded, purpose-built reasoning loop with its own budget and its own audit trail. Find it at `/agents` in the app. --- ## Two kinds of agent Every registered agent declares which of two categories it belongs to. The split exists so that agents touching organisation-wide configuration are never trusted with a direct write - a human always reviews the change before it takes effect. - **Probe agents** own one axis of your organisation's configuration and *propose* it - they never write it directly. Every side effect lands as a pending approval in your [approvals queue](/security), and a probe can re-run itself when it detects drift. Example: a probe that infers which of your systems' identities map to the same worker. - **Producer agents** consume configuration you have already approved and write reviewable output - never silently finalised, always visible for review before it's treated as fact. Examples: a measurement agent that verifies drawing quantities against a schedule of rates, or an agent that synthesises a cited tender launch brief. For the underlying taxonomy - why the split exists and how it prevents unreviewed drift - see [Agents](/concepts/agents) under Concepts. --- ## What will you find on the Agents surface? - **`/agents`** - the index. Every agent definition available to your organisation, grouped by probe or producer, with a strip of recent run activity. - **`/agents/:slug`** - an agent's detail page. Overview (what it does, its budget, what it produces), Runs (its history), and - for probes - Proposals (its pending approvals). - **`/agents/runs/:runId`** - a single run. Budget burned against budget allowed, a step-by-step timeline that surfaces failures first, and - for measurement agents - the source evidence behind the result. Run detail pages are deep-linkable and shareable - you can send a colleague a link straight to the run that matters, not just the agent that produced it. --- ## How do Agents connect to the other surfaces? Agents read [Civil Memory](/start-here/civil-memory) the same way [Studio](/surfaces/studio) and [Ask Demiton](/surfaces/ask-demiton) do, and measurement agents source the underlying documents the same way the platform's own harvesters do. A probe's proposals resolve through the same approvals queue as every other proposed change in the system - there is no separate approval mechanism just for agents. --- ## Which tier includes Agents? Insights and above - the same gate as [Memory](/memory/overview). Agents require organisation configuration that only exists once your organisation is connected, so there is no Public-tier Agents surface. ## Next steps - [Agents (Concepts)](/concepts/agents) - the probe/producer taxonomy in depth - [Memory](/memory/overview) - what agents read from - [Studio](/surfaces/studio) - the ad-hoc alternative for a one-off question --- ## [PRODUCT_SURFACE] Ask Demiton (MCP clients) Description: Ask Demiton is how you use Demiton from outside the app - in Claude, ChatGPT, or your IDE - over the open Model Context Protocol. URL: https://docs.demiton.io/surfaces/ask-demiton/ Every one of the [five diseases](/start-here/diseases) can be asked about before it costs you: which certificates expire this quarter, which variations still have no notice, which days have no diary. Each protection raises its own flag. This is where you ask what sits behind one, and the answer cites the register it came from. Ask Demiton is how you use Demiton from outside the app - in Claude, ChatGPT, an IDE, or any client that speaks the open Model Context Protocol (MCP). It is the external twin of [Studio](/surfaces/studio): the same tools, the same sourced answers, the same identity and audit guarantees, brought into the AI client you already work in. This is the front door to [Civil Memory](/start-here/civil-memory) - you ask for what you need, where you already are. Connect at `https://api.demiton.io/mcp`. For step-by-step setup, see the [MCP Server guide](/access/mcp-server). --- ## What can Ask Demiton do? Once connected, your AI client gains a small set of Demiton tools: - **Ask in natural language.** Query public market data and - for Connected organisations - your own operational memory: *"who won the contract we lost on the Pacific Highway, and at what price?"*, *"which estimator's rates held last quarter?"* - **Discover and run reports.** List the reports available to your role, run one, and get the result back. - **See it as a dashboard.** Report results render as interactive views right inside Claude, while the underlying data stays available to the conversation. - **Propose a correction.** Suggest a write (for example, fixing a timesheet); it lands in your organisation's approval queue rather than executing directly. "Ask Demiton" is the customer name for the MCP tool. When you see it in install docs or in your AI client, it is the same engine that powers Studio in the web app. --- ## How is Ask Demiton secured and audited? Every connection is authenticated - there are no anonymous callers. You connect with OAuth (sign in through your AI client) or an API key, and every answer is filtered to what your identity is allowed to see. Each tool call passes an entitlement, permission, and quota check, and is written to the [audit trail](/security#audit-trail). Demiton never invents data; it serves what it holds, with a citation back to the source. --- ## Which tier includes Ask Demiton? Any authenticated user can connect; what changes is what the tools can read. Public users reach public market data; Insights adds your uploaded history; Connected adds your live operational memory. See [What is Demiton](/overview/platform#tiers) for the tier model. ## Next steps - [MCP Server](/access/mcp-server) - connect Claude, ChatGPT, or your IDE - [Studio](/surfaces/studio) - the same answers inside the app - [Memory](/memory/overview) - what the tools read from --- ## [PRODUCT_SURFACE] Market - the pre-award surface Description: Market is where you discover and pursue public civil work - planning notices, open tenders, and awards - before you win it. URL: https://docs.demiton.io/surfaces/market/ Market is where you discover and pursue public civil work before you win it: the forward programme, open tenders, and recent awards across Australia. It runs entirely on free public data, so it is populated on day one for every organisation - no systems to connect. Market is the pre-award half of [Civil Memory](/start-here/civil-memory): the public market you watch and chase. Find it at `/explore` in the app. --- ## What can Market do? - **See the pipeline.** Planning, tender, and award laid out as a lifecycle rail, filterable by jurisdiction and category, with live closing countdowns on open tenders. - **Watch and pursue.** Bookmark any opportunity to your watchlist, or pursue a tender to move it into your pipeline as an opportunity. - **Know the field.** A win/loss scorecard (win rate, loss reasons, "who beats us") alongside public market intelligence - top contractors, agencies, and jurisdictions by value. - **Research suppliers.** Search contractors by name or ABN to see value, contract count, and the work types they win. - **Attach context.** Bind a CRM or document slot on a tender to your own systems, and fetch or upload tender attachments. When you win a tender you pursued, the intended model is to record it as a declared win against your delivery [project](/memory/overview): a PURSUING contract link becomes WON, and the public contracting process joins your private delivery record. The backend endpoint exists today (`POST /api/v1/memory/projects/{project_id}/contract-links/declare-win`); a dedicated Memory screen for it is not built yet. --- ## How does Market feed Civil Memory? Market feeds the public half of the spine. Every notice, tender, and award is a sourced fact in the platform's public record, normalised to a single shape regardless of which government portal it came from. The same public data is what [Ask Demiton](/surfaces/ask-demiton) reaches when you ask market questions in your AI client. For the data behind it - which jurisdictions are covered, how awards are matched to your CRM, and the coverage gaps we are honest about - see [Public Data connectors](/connectors/overview#public-data-connectors-all-tiers). --- ## Which tier includes Market? | Tier | What you see in Market | |---|---| | **Public** | Awards - watch the market, free | | **Insights** | Planning + tender + market intelligence; pursue work and generate bids | See [What is Demiton](/overview/platform#tiers) for the full tier model. ## Next steps - [The five diseases](/start-here/diseases) - including the lapsed compliance standing that decides which work you are eligible to pursue - [Memory](/memory/overview) - the sourced record behind Market --- ## [PRODUCT_SURFACE] Studio - the in-app AI surface Description: Studio is Demiton's in-app AI surface - ask a question and the platform answers by calling tools, running reports, and rendering results inline. URL: https://docs.demiton.io/surfaces/studio/ Studio is where a disease gets caught by asking: which certificates lapse before the next panel review, which variations are past their notice window, where cost has drifted from the tender. Until each [protection](/start-here/diseases) raises its own flag, the fact is one question away, and the answer cites the register it came from. Studio is the AI surface inside the Demiton app. You ask a question; the platform answers by calling tools, running reports, and rendering the results inline - sourced and identity-filtered. It is the one surface that is not tied to a stage of the job: it reaches across [Market](/surfaces/market), [Protection](/start-here/diseases), and [Memory](/memory/overview) through the same engine that powers [Ask Demiton](/surfaces/ask-demiton) in your AI client. Find it at `/studio` in the app. --- ## What can Studio do? - **Chat with your operation.** Multi-turn conversations that stream as they answer, grounded in your [Civil Memory](/start-here/civil-memory). - **Pick a depth.** A per-question selector (Quick / Standard / Deep) trades speed for thoroughness on harder questions. - **Run reports inline.** Browse the reports available to your role, run one with a short form, and see it render as an interactive dashboard right in the conversation - with CSV and PDF download. - **See the working.** A collapsible trace shows which tools were called and what they returned, so every answer is inspectable. - **Talk to it.** Voice input is available, with cost and token usage shown per answer. Studio and Ask Demiton are twins. Studio runs inside the app; Ask Demiton is the same tools and answers brought into Claude, ChatGPT, or your IDE over the open MCP standard. Use whichever you are already in. --- ## How does Studio use Civil Memory? Studio does not hold its own data. It reads through the same identity-bound, audited path as everything else, drawing on [Market's](/surfaces/market) public data and - for Connected organisations - the operational data behind [Memory](/memory/overview). Every answer is attributable, and every tool call is recorded in the [audit trail](/security#audit-trail). --- ## Which tier includes Studio? All paying tiers reach Studio. Your tier and the per-question depth selector together govern how deep the model reaches and which data it can see - public records only, or your live operational systems. See [What is Demiton](/overview/platform#tiers) for the tier model. ## Next steps - [Ask Demiton](/surfaces/ask-demiton) - the same answers in your own AI client - [Memory](/memory/overview) - what Studio reads from - [Connectors](/connectors/overview) - the systems that feed it --- ## [POLICY_REFERENCE] Conformance & the One-Way Valve Description: How Demiton declares OCDS/OC4IDS conformance at the edges, and how the One-Way Valve keeps tenant operational memory off the public hub. URL: https://docs.demiton.io/standards/conformance/ Standards conformance in Demiton is a property declared at the edges of the system, not a claim about internal storage. This page is the concrete "how it's enforced" companion to [OCDS](/standards/ocds) and [OC4IDS](/standards/oc4ids). --- ## Conformance is declared per adapter Every adapter that touches procurement or delivery-reporting data declares its own conformance level: | Adapter kind | Declares | |---|---| | Procurement adapters (AusTender, state portals) | `ocds-1.1` | | The snapshot publication path | `oc4ids-0.9.5` | | Native operational adapters (ERP, field ops, payroll) | `none` | Nothing in the platform stores OCDS or OC4IDS as its native format. Internal facts keep their own typed structure; conformant output is *projected* wherever a boundary is crossed - on ingest from a government portal, or on publication out. See [OCDS](/standards/ocds) for what that projection looks like on the way in. --- ## The One-Way Valve Your tenant's operational memory - site diaries, allocations, payroll reconciliations, anything produced by running your own business - never flows to Demiton's public platform hub as a side effect of being in the system. The only route out is a project snapshot you explicitly choose to publish; the per-project OC4IDS emission that would carry a delivery record to a government client is not built yet. That's the One-Way Valve: data can flow from the public hub into your tenant freely (that's how [Market](/surfaces/market) works), but it only flows back out through one deliberate, logged action - never silently, never automatically. ## How the valve is enforced There is exactly one way tenant data becomes public: it is published as a project snapshot. Three properties of that path are what make the guarantee hold. - **One writer.** A single publication service is the only code in the platform permitted to insert, update, or delete a published snapshot. Nothing else can put a row on the public side, so there is one place to audit rather than a rule every future feature has to remember to obey. - **Validated before it persists.** That service projects the snapshot into OC4IDS shape and validates it against the OC4IDS JSON Schema and its codelists *before* anything is written. A conformance failure is deterministic and non-retryable - the publication does not happen, and there is no silent fallback to publishing something unvalidated. - **Triggered, never ambient.** Publication runs as an explicit workflow step. No scheduled sweep, harvest, or background job publishes tenant operational data. ### The emission half is not built yet Snapshot publication exists and is validated; a per-project, consented **OC4IDS emission** - where you choose to report one project's delivery data to one government client - does not. The workflow that prepares OC4IDS facts is staging only, and the `EmissionConsent` model has no production call site, so there is no emission path for a consent check to run on. Treat the consent half of the One-Way Valve as the intended design, not a shipped control. Reads work the same way in the other direction: the public procurement endpoints serve only the award and contract stages anonymously. Planning and tender data requires an authenticated, entitled session. You can connect live operational systems to Demiton without worrying that doing so exposes your business to competitors or to the public. Nothing about how you run a job becomes visible outside your organisation unless you choose to publish it. --- ## Next steps - [OCDS](/standards/ocds) - the pre-award standard this conformance model produces - [OC4IDS](/standards/oc4ids) - the delivery-reporting standard, and what a publication contains - [Security](/security) - the broader identity and audit model this sits within --- ## [POLICY_REFERENCE] OC4IDS Description: OC4IDS (Open Contracting for Infrastructure Data Standard) structures the delivery half of Civil Memory: the project record for work you deliver. URL: https://docs.demiton.io/standards/oc4ids/ OC4IDS - the Open Contracting for Infrastructure Data Standard - structures the delivery half of [Civil Memory](/start-here/civil-memory): the infrastructure project record for work you've won and are delivering, or have delivered. Where [OCDS](/standards/ocds) covers the public, pre-award side of a job, OC4IDS picks up at the award seam and covers everything after. --- ## What does OC4IDS cover in Demiton? Once a delivery project exists inside [Memory](/memory/overview) - live operational data from your own ERP, field ops, and payroll systems - OC4IDS is the shape that data is designed to take when it is reported back out: project scope, cost, schedule, and outcome, structured the way government clients and the broader infrastructure sector can consume. ## The One-Way Valve holds; emission is forthcoming Your day-to-day operational memory - site diaries, allocations, payroll reconciliations - is never exposed as a side effect of simply existing in the platform. That is the **One-Way Valve**. The half of it that exists today is snapshot publication: one service is the only code permitted to write a published snapshot, and it validates the OC4IDS projection against the schema and codelists before it persists. See [Conformance](/standards/conformance) for how that path is enforced. The other half - a **contractor-initiated, consented, audited emission** of one project's delivery data to one government client - is not built yet. The workflow that stages OC4IDS facts is explicitly staging only, and the `EmissionConsent` model has no production call site. Until it ships there is no emission you can trigger, so no per-project delivery record leaves your tenant at all. There is no background process that publishes your delivery data, and the consented, per-project OC4IDS emission itself is not available in the current release. What you can rely on is the direction of the valve: your operational memory does not leave your tenant as a side effect of using the platform. --- ## Next steps - [OCDS](/standards/ocds) - the pre-award standard, and [the difference between the two](/standards/ocds#what-is-the-difference-between-ocds-and-oc4ids) - [Conformance](/standards/conformance) - the One-Way Valve and how it's enforced, in detail - [Memory](/memory/overview) - where delivery data lives before it's ever emitted --- ## [POLICY_REFERENCE] OCDS Description: OCDS (Open Contracting Data Standard) structures the pre-award half of Civil Memory - planning, tenders and awards from public procurement portals. URL: https://docs.demiton.io/standards/ocds/ OCDS - the Open Contracting Data Standard - is the open schema that every Australian jurisdiction publishes contract notices and awards under. It's the standard behind [AusTender](/connectors/intelligence/austender) and the state procurement portals, and it structures the pre-award half of [Civil Memory](/start-here/civil-memory): planning notices, open tenders, and awards, before a job becomes yours to deliver. --- ## What does OCDS cover in Demiton? OCDS-shaped data is the public record of a contracting process: who's buying, what's being tendered, who bid, who won, and at what value. In Civil Memory terms, this is everything on the [Market](/surfaces/market) side of the award seam - the part of a job's life that happens in public, before you win it. ## What is the difference between OCDS and OC4IDS? They are two halves of the same job, joined at the award. OCDS records the public procurement process before you win; [OC4IDS](/standards/oc4ids) is the shape for the infrastructure project you deliver afterwards. | | OCDS | OC4IDS | |---|---|---| | Full name | Open Contracting Data Standard | Open Contracting for Infrastructure Data Standard | | What it covers | The contracting process: who is buying, what is tendered, who bid, who won, at what value | The infrastructure project: scope, cost, schedule and outcome through delivery | | Stage of the job | Pre-award: planning, tender and award | Post-award: from the award seam to close-out | | Who publishes it | Government procurement portals - AusTender and the state portals | In Demiton's model, the contractor, as a consented emission to the government client (forthcoming) | | Half of Civil Memory | The public half, read by [Market](/surfaces/market) | The delivery half, fed by your operational systems | The delivery half is browsable in [Memory](/memory/overview); the former Projects surface was retired in September 2026. | Example record | An AusTender award notice for a road package | A delivery report for a bridge project: physical progress, subcontractors, completion | ## Projection, not storage Demiton never stores OCDS as its native format. Facts live in their own typed structure internally, and the platform *projects* them into OCDS shape on ingest - reading a government portal's release and translating it into the record Civil Memory holds - and again wherever a caller needs OCDS-conformant output. Conformance is something the platform produces at its edges, not something baked permanently into how data is stored. This is deliberate: it means the internal fact model can evolve, absorb new source systems, and support queries the standard was never designed for, without ever losing the ability to speak OCDS where it matters. See [Conformance](/standards/conformance) for exactly how adapters declare their conformance level, and [OC4IDS](/standards/oc4ids) for the standard that takes over after the award. --- ## Next steps - [OC4IDS](/standards/oc4ids) - the delivery-reporting standard that picks up after the award - [Conformance](/standards/conformance) - how conformance is declared and enforced - [How your registers become one record](/start-here/civil-memory) - the award seam where OCDS hands off to OC4IDS --- ## [TECHNICAL_REFERENCE] Memory Description: How Demiton builds and queries Civil Memory across workers, projects, and assets - the sourced record at the heart of the platform. URL: https://docs.demiton.io/memory/overview/ The [five diseases](/start-here/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](/start-here/civil-memory). 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 | 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 | | **Enterprise** | Full stack across all integrated systems with custom entity types | As above, plus cross-system memory and custom entity types | [Explore Insights](https://demiton.io/insights?ref=docs-memory) - self-serve, no implementation fee. [Talk to us about Connected](https://demiton.io/contact?ref=docs-memory-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 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 | 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, 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. | 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_` 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_` 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. | 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](/access/mcp-tools) for the generated list of tools a connection advertises, and [Ask Demiton](/surfaces/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](/access/mcp-tools) for the generated tool list, or [MCP Server](/access/mcp-server) for connection details. --- ## Next steps - [How your registers become one record](/start-here/civil-memory) - the spine that ties the public market to your delivery - [Ask Demiton](/surfaces/ask-demiton) - query the memory layer through Claude or ChatGPT - [What is Demiton](/overview/platform) - how tiers fit together and what memory scope each unlocks - [Uploading Your Data](/getting-started/uploading-your-data) - Insights customers: start building memory from uploaded contracts - [Connecting a System](/getting-started/connecting-a-system) - Connected customers: 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. --- ## [DOCUMENTATION] Connecting a System Description: How to connect a system to Demiton - the four-step wizard, system types, credential fields, environment scoping, and variant connectors. URL: https://docs.demiton.io/getting-started/connecting-a-system/ **Insights customers** connect to Demiton by uploading historical data, not by connecting live systems. See [Uploading Your Data](/getting-started/uploading-your-data) instead. **Connected customers** - continue below to walk through the connection wizard. Connecting a system gives Demiton access to that system's data under your identity. The access profile varies by system - some connectors are read-only, others support approved writes. All credentials are encrypted at rest and every operation is fully audited. To open Systems, choose **Systems** in the sidebar (it sits under **Configure**), or press **Ctrl+K** (⌘K on a Mac) and search for "Systems". --- ## The connection wizard Demiton walks you through four steps. To start, click **Add System** on the Systems page. 1. ### Select a system Browse or search for the system you want to connect. Systems are grouped by category - ERP, Payroll, Banking, Cognitive, Data Sources, and more. Click any system card to select it and advance to the next step. If a system shows a lock icon, it requires an access request before you can connect it - click the card to request access. Search by name or keyword - for example, typing "pay" finds Employment Hero Payroll and Payroll categories, "365" finds Business Central and Finance & Operations. 2. ### Name and scope the connector Give the connector a name you'll recognise later - for example, **"Business Central Production"** or **"Employment Hero Payroll AU"**. Then choose an environment: | Environment | Use for | |---|---| | **Production** | Your live system | | **UAT** | A staging or test instance | The name and environment are displayed on the Systems page and used as the connector's alias throughout the platform. 3. ### Configure the connection Enter the credentials for your system. The fields vary by system type: | System type | Systems | Connection | What you'll need | |---|---|---|---| | `D365_FINOPS`, `D365_BUSINESS_CENTRAL`, `DATAVERSE` | Dynamics 365 F&O, Business Central, Dataverse | OData / Dataverse | Tenant ID, Client ID, Client Secret, and your base URL | | `XERO` | Xero | OAuth 2.0 | Client ID and Client Secret - you'll be redirected to the provider to authorise | | `AZURE_FOUNDRY` | Azure AI Foundry | OAuth 2.0 | Client ID and Client Secret - provisioned under your Azure tenant | | `KEYPAY` | Employment Hero Payroll (KeyPay) | OpenAPI / API key | Your API key and the base URL for your instance | | `SQL` | SQL Database (Postgres or MSSQL) | SQL | Host, port, database name, username, password, and dialect | | `BANKING_GENERIC` | Australian Banking Gateway | SFTP | Host, port, username, and an SSH key or password | | `M365_EXCEL` | Excel Upload | File upload | Upload a file directly - no ongoing connection required | | `MS_TEAMS` | Microsoft Teams | OAuth 2.0 | Authorise Microsoft Graph to post approvals and notifications to channels | Before creating, click **Test Connection** to validate your credentials without committing anything. The test result will tell you exactly what failed if the connection can't be established. Once the test passes, click **Create Connector**. For OAuth 2.0 systems, clicking **Create Connector** redirects you to the provider's login page. After authorising, you'll be returned to Demiton automatically. 4. ### Done - resources discovered The connector is live. Demiton runs a discovery pass and lists every resource the connection exposes - tables, endpoints, objects - so you can see exactly what data is available. From here you can: - **Back to Systems** - return to the Systems overview - **Bind an entity** - associate a canonical entity (e.g. a Worker or Project) with data from this connector, so it feeds [Civil Memory](/start-here/civil-memory) --- ## Adding a UAT/Production pair If you connect the same system in both UAT and Production, Demiton links them as a variant pair - they appear grouped on the Systems page and share a logical alias so workflows can target either environment cleanly. To add a variant: 1. On the Systems page, find the existing connector 2. Click **Add Variant** on its card 3. The wizard opens at Step 2 with the environment pre-set to the opposite of what you already have 4. Complete the credentials for the new environment --- ## Platform-managed connectors Some connectors - Azure AI Foundry and Claude Enterprise - are configured and managed by Demiton on your behalf as part of your deployment. These appear in Systems but are not self-service. Contact your Customer Success Manager to enable or modify them. --- ## After connecting Once a connector is live, it is available for: - **Workflow tasks** - FETCH, PUSH, and EXECUTE verbs run against the connector's resources - **Studio** - [the in-app AI](/surfaces/studio) uses connected data as grounded sources for responses - **Memory** - bind entities like Workers, Projects, and Assets so the connector feeds [Civil Memory](/start-here/civil-memory) - **Ask Demiton** - your connected data becomes queryable [from your AI client](/access/mcp-server) See the [Connectors reference](/connectors/erp/business-central) for system-specific credential guides. --- ## Next steps - [MCP Server](/access/mcp-server) - query your connected data through Claude or ChatGPT - [Business Central](/connectors/erp/business-central) - ERP credential guide - [Assignar](/connectors/operational/assignar) - field ops credential guide - [Memory overview](/memory/overview) - how Demiton builds institutional knowledge from your connected systems --- ## [DOCUMENTATION] Navigating the Platform Description: How to move around Demiton - the sidebar, the Ctrl+K search palette, the real keyboard shortcuts, and the destinations that have retired. URL: https://docs.demiton.io/getting-started/navigation/ Demiton has two ways to get anywhere: the **sidebar**, and the **search palette** you open with **Ctrl+K** (⌘K on a Mac). Most sessions start in one of them and never need the other. --- ## The sidebar The sidebar down the left of the screen is the primary navigation rail. It is grouped by what you are doing: | Section | What lives there | |---|---| | **Work** | The surfaces you use every day - Studio, Market, Compliance, Projects, Memory, Agents & ML | | **Configure** | Your own systems and settings - Systems, Control Room, Workspace (Connected plan and above) | | **Account** | Workspace settings, shown to Insights and Public accounts | | **Platform** | Demiton's internal admin tools, visible only to platform staff | A **Search** item sits at the top of the rail, directly above the Work section - the visible way into Ctrl+K for anyone who does not know the shortcut. You can collapse the sidebar to icons with the rail on its right edge, or with the toggle in the top bar. It stays collapsed where you left it as you move around. On mobile (below 768px) the sidebar is replaced by a bottom tab bar - Studio, Projects, a centre button that opens the palette, and a **More** drawer for everything else. --- ## Where each destination lives Every destination below is a real entry in the app's navigation catalog. Your tier, and your role, decide which ones you see - a destination above your tier is still listed, with an **Insights plan** or **Connected plan** badge, rather than disappearing. | Section | Product name | App label | Route | Notes | |---|---|---|---|---| | Work | Studio | Studio | `/studio` | The in-app AI | | Work | Protection | Protection | `/protection` | The five diseases, the project board, watches, alerts and proof. Every tier, including Free/Public | | Work | Market | Market | `/explore` | Public civil work: planning, tenders, awards | | Work | Memory | Memory | `/memory` | The sourced record. Insights and above | | Work | Agents | **Agents & ML** | `/agents` | Scoped agent runs and ML models. Insights and above | | Configure | Systems | Systems | `/connectors` | Connectors to your own systems. Connected | | Configure | Workflows | **Control Room** | `/workflows` | Workflows, templates, runs. Connected | | Configure | Workspace | Workspace | `/hq` | Organisation settings, members, billing, API keys | | Account | Workspace | Workspace | `/hq` | The same page, shown to Insights and Public accounts while Configure is hidden | Deeper destinations - Market Snapshot, Dimension Audit, Template Catalog, Team Members, API Keys, Write Approvals, Competitors, Watchlist, and the tab inside each page - are reachable from the search palette rather than the top-level rail. The stand-alone **Compliance** (formerly Prequalification) and **Projects** destinations were retired in September 2026 and are no longer in the navigation. Both are now carried by Protection: the lapsed compliance disease reads the standing you declared, and the Project board is the job under cover. Their old URLs redirect to `/protection`. --- ## The search palette (Ctrl+K) Press **Ctrl+K** - **⌘K** on a Mac - from anywhere to open the search palette, or click **Search** at the top of the sidebar. It is the fastest route to a destination you can name but cannot place. The palette searches across: - **Work, Configure, More and Platform** - every destination, grouped by its sidebar section. A locked destination is still shown, with its plan badge, and takes you to billing to upgrade. - **Page sections** - the tabs inside a page. Typing "registers" lands on the **Registers** tab inside Control Room, not just on the Control Room page. Only sections that actually match what you typed are listed. - **Registers** - each register you have by name, taking you straight to that register's page. Typing "payment claim" or "compliance gate" opens it directly, without going via Memory first. Available on Insights and above. - **Memory** - entities from Civil Memory once you have typed two characters: workers, projects, assets, vendors, cost codes and more. - **Connect a System** - quick links that open Systems ready to add a specific connector. - **Commands** - the keyboard shortcuts available on the page you are on. - **Recent** and **Suggested** - the last eight destinations you visited, and a short contextual list for where you are. **Keyboard navigation:** ↑↓ to move, ↵ to open, Esc to close. --- ## Keyboard shortcuts These are the global shortcuts, exactly as the app binds them: | Shortcut | Action | |---|---| | **Ctrl+K** (⌘K on a Mac) | Open the search palette | | **Ctrl+J** (⌘J on a Mac) | Toggle the agent sidecar | | **?** | Show the keyboard shortcuts for your current location | | **Escape** | Close the current overlay | | **1**–**9** | Go to a destination you have pinned to that slot | One more shortcut is scoped to a single page: | Shortcut | Where | Action | |---|---|---| | **Ctrl+N** (⌘N on a Mac) | Control Room only | Create a new workflow | Press **?** at any time to see what is available where you are. --- ## The agent sidecar (Ctrl+J) **Ctrl+J** opens the agent sidecar - a persistent panel on the right of the screen that shows what your workflows are doing, without leaving the page you are on. A status dot stays visible at the edge of the screen: - **Blue** - a run is in progress - **Red** - a run has failed and needs attention - **Green** - everything has finished Runs are grouped by status, and the panel opens itself when a run fails. Expand any run inline for its task detail, follow it through to the full run view, or retry a failed run from the panel. --- ## Retired destinations Some older documentation points at hubs that no longer exist. **Scheduling**, **Estimating**, **Finance**, **Human Resources**, **Purchasing** and **Assets** were rolled into Civil Memory, and their URLs now redirect to `/memory`. **Vendors**, **Workers**, **Opportunities** and `/next/` were removed outright. If you reach one of those pages from an old bookmark, you will land on Memory. Use the search palette for what you were looking for - the entity types those hubs used to hold (workers, vendors, projects, assets, cost codes) are all searchable there. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - the wizard behind the Systems destination - [Uploading Your Data](/getting-started/uploading-your-data) - the Insights path, which starts in Systems too - [What is Demiton](/overview/platform) - how the surfaces and tiers fit together --- ## [DOCUMENTATION] Uploading Your Data Description: How Insights customers upload historical contract and estimating data, then query it through Claude or ChatGPT via the MCP server. URL: https://docs.demiton.io/getting-started/uploading-your-data/ On Insights, you don't connect live systems - you upload historical data. Demiton applies the open-source procurement classification framework to your uploads, structures the result against domain entities, and makes it queryable through Claude via the MCP server. This is the fastest path to value: no IT involvement, no credentials, no implementation scoping. Upload a file and start asking questions. Not yet on Insights? [Sign up at demiton.io/insights](https://demiton.io/insights?ref=docs-upload-guide) - credit card, no implementation fee, 14-day free trial. That link opens the Insights page on demiton.io; your account and uploads live in the app at [app.demiton.io](https://app.demiton.io). When you outgrow uploads and want live system integration, [contact us about Connected](https://demiton.io/contact?ref=docs-upload-guide-upgrade). --- ## What to upload Insights is designed for historical contract and estimating data. The most valuable uploads are: | Data type | Format | What you'll get | |---|---|---| | Historical contract rates | Excel, CSV | Rate comparison across projects, estimator performance, where rates held vs actuals | | Tender submissions and BOQs | Excel, CSV | Classification against the procurement framework, rate benchmarking | | Project cost summaries | Excel, CSV | Budget vs actual patterns, cost code breakdown | | Estimating workbooks | Excel | Structured rate extraction, classification, query via Claude | The platform handles messy, real-world spreadsheets - headers in row 3, merged cells, multiple worksheets. You don't need to clean your data before uploading. Your uploads live on the **Systems** page. In the app's navigation, Systems normally sits under **Configure**, which appears on the Connected plan - so on an Insights account you may not see it in the sidebar. Reach it with **Ctrl+K** (⌘K on a Mac) and search for "Systems". --- ## How to upload 1. ### Sign in and navigate to Systems Go to [app.demiton.io](https://app.demiton.io) and sign in with your Insights account. Open **Systems** - press **Ctrl+K** (⌘K on a Mac) and search for "Systems" - then click **Add System**. 2. ### Select Excel / CSV and upload your file Choose **Excel** or **CSV** from the connector list. Upload your file - supported formats: `.xlsx`, `.xls`, `.csv`. Give the upload a name - for example, **"Pacific Highway BOQ 2024"** or **"FY24 Contract Summary"**. 3. ### Review classification Demiton processes the file and applies the procurement classification framework. A classification summary shows: - How many line items were classified - Which cost categories were identified - Any rows that couldn't be classified (you can review and correct these) Classification typically completes within a few minutes for most workbooks. 4. ### Connect the MCP server and start querying Once your data is classified, it is available through the MCP server. [Connect Claude or ChatGPT](/access/mcp-server) and start asking questions: - *"Which cost codes had the largest variance between estimate and actuals across my uploaded projects?"* - *"What were the earthworks rates on the Pacific Highway contract?"* - *"Which estimator's rates held best against actuals?"* - *"Summarise the labour split across my uploaded BOQs."* --- ## What the classification framework does Demiton applies an open-source procurement classification framework to every upload. This maps unstructured line items - cost codes, descriptions, quantities, rates - to a consistent taxonomy across Australian civil construction categories. The result is a structured view of your historical rates that can be: - Queried across projects ("what did earthworks cost per m³ across all uploads?") - Compared against your own benchmarks - Asked about directly in natural language through Claude The framework source is published at [github.com/demitonapp](https://github.com/demitonapp). --- ## Upgrading to Connected Insights answers the question: *"what do we know from our historical records?"* Connected answers: *"what is happening right now, and what happened last week on site?"* When you find yourself wanting to ask questions about live project financials, current workforce allocations, or last night's site diaries, that's the signal to move to Connected. [Contact us](https://demiton.io/contact?ref=docs-upload-guide-connected) - the first conversation is about scoping which 1 to 2 systems to integrate. --- ## Next steps - [Navigating the platform](/getting-started/navigation) - where Systems sits in the app, and how to get around - [MCP Server](/access/mcp-server) - connect Claude or ChatGPT to your uploaded data - [Platform overview](/overview/platform) - how tiers fit together - [Memory overview](/memory/overview) - how uploaded data becomes queryable civil memory - [Upgrade to Connected](https://demiton.io/contact?ref=docs-upload-guide-next-connected) - live system integration when you outgrow uploads - [Roadmap](/roadmap) - what is being built next, including more data sources and registers --- ## [TECHNICAL_REFERENCE] API Access Description: Use the Demiton product API to read your registers, workflow runs, and reports programmatically; get an API key and authenticate requests. URL: https://docs.demiton.io/access/api/ The Demiton API is the platform's REST interface for programmatic access. It exposes the same registers, workflow runs, and reports you can see in the app, so your own systems and scripts can read them directly. The API is available on the **Connected** tier and above. API keys are scoped to your organisation and carry the same identity and access controls as your platform account. The MCP server is a separate interface, available on every tier. If you are on Insights and want programmatic access to your contract data, [upgrading to Connected](/overview/platform#tiers) adds the API alongside live system integrations. [Contact us](https://demiton.io/contact?ref=docs-api-upgrade) to discuss. --- ## Getting an API key 1. Sign in to the Demiton platform 2. Go to **HQ → API Keys** 3. Create a new key - give it a name so you can identify it later 4. Copy the key immediately. It is only shown once. API keys carry your organisation's access. Treat them like passwords - do not commit them to source control or share them publicly. --- ## Authenticating Pass your API key as a Bearer token in the `Authorization` header on every request: ```http Authorization: Bearer YOUR_API_KEY ``` --- ## Base URL Your API base URL is available in **HQ → API Keys** alongside your key. It is specific to your deployment. --- ## API reference The full API reference is available via Swagger at `/api/v1/docs` on your deployment URL - requires authentication. --- ## Next steps - [MCP Server](/access/mcp-server) - connect your AI assistant directly to your operational data --- ## [TECHNICAL_REFERENCE] MCP Server Description: Connect Claude, ChatGPT or an IDE to Demiton over the Model Context Protocol - setup, authentication, and what each tool can read on your tier. URL: https://docs.demiton.io/access/mcp-server/ Ask Demiton exposes your operational data as tools that any MCP-compatible AI client - including Claude - can call directly. Ask questions about project financials, workforce, site records, and civil memory in natural language, with every response sourced from your connected data. **Available on every tier.** What changes between tiers is the scope of data the MCP can read: | Tier | What the MCP can read | |---|---| | Public | AusTender, ABR, BOM, and CKAN open data | | Insights | Public data + your uploaded contracts and estimating data | | Connected | Public data + uploads + your live integrated systems (ERP, field ops, payroll, documents) | Every tool call is identity-bound and audited. Not sure which tier you need? See [Quickstart](/start-here/quickstart) - real contractor and weather data on the free Public tier. When you're ready to ask questions about your own contracts, [sign up for Insights](https://demiton.io/insights?ref=docs-mcp). **Invited by your organisation?** If a colleague sent you a Demiton invitation, you are joining a Connected-tier workspace. After accepting the invite and signing in with your Microsoft work account, follow the **Connected tier** tab below. When the sign-in browser window appears during setup, use the same Microsoft work account your invite was sent to. --- ## How do I connect Claude or ChatGPT to Demiton? The fastest way to connect if you use [claude.ai](https://claude.ai) in a browser. No config file, no installer, no command line. 1. Open any Claude conversation and click **Customize** (bottom-left of the sidebar). 2. Select **Connectors**, then click **+**. 3. Enter the server URL: `https://api.demiton.io/mcp` 4. Sign in with your Demiton account when the OAuth prompt appears. That's it. Demiton will appear in your Connectors list and its tools become available in every conversation. The same tier model applies: Public (free), Insights, or Connected. Your account tier determines which tools and data sources are available. **Don't have an account?** [Sign up at demiton.io](https://app.demiton.io/auth/register?ref=docs-mcp-claude-web) - the Public tier is free with a verified business email. ChatGPT supports MCP connectors natively through its connector builder. No command-line tools or config file edits needed. **Create a new connector with these values:** | Field | Value | |---|---| | Name | Demiton | | Server URL | `https://api.demiton.io/mcp` | | Authentication | OAuth | Leave the advanced OAuth panel as-is. ChatGPT auto-discovers the OAuth endpoints from the server - no manual endpoint configuration required. Click **Create**, then sign in with your Demiton account when the OAuth prompt appears. The same tier model applies: Public (free), Insights, or Connected. Your account tier determines which tools and data sources are available - the connection setup is identical for all three. **Don't have an account?** [Sign up at demiton.io](https://app.demiton.io/auth/register?ref=docs-mcp-chatgpt) - the Public tier is free with a verified business email. The MCP server is at `https://api.demiton.io/mcp`. Connect via OAuth using `mcp-remote` - your tier permissions apply automatically on sign-in. **One-line installer (recommended):** **macOS / Linux:** ```bash curl -fsSL https://raw.githubusercontent.com/demitonapp/claude-desktop-installer/main/install.sh | bash ``` **Windows (PowerShell):** ```powershell irm https://raw.githubusercontent.com/demitonapp/claude-desktop-installer/main/install.ps1 | iex ``` Source and uninstall: [github.com/demitonapp/claude-desktop-installer](https://github.com/demitonapp/claude-desktop-installer) **Or add manually to `claude_desktop_config.json`:** ```json { "mcpServers": { "demiton": { "command": "npx", "args": ["-y", "mcp-remote", "https://api.demiton.io/mcp"] } } } ``` On first run, a browser window opens to sign in with your Demiton account. No API key is stored in the config. **Microsoft organisation?** If your organisation uses Entra ID (Azure AD), the sign-in window will show a Microsoft login prompt. Use your Microsoft work account - the same one your Demiton invitation was sent to. **Headless or CI access?** Generate an API key in **HQ → API Keys** and use it as a Bearer token instead: ```json { "mcpServers": { "demiton": { "type": "http", "url": "https://api.demiton.io/mcp", "headers": { "Authorization": "Bearer YOUR_API_KEY" } } } } ``` --- ## What tools does Ask Demiton provide? Ask Demiton exposes a small, stable set of tools to your MCP client. `ask_demiton` is the headline tool: it routes any natural-language question to the right registers internally, so you do not call individual data sources as separate tools. A tenant's client is advertised four tools: | Tool | What it does | |---|---| | `ask_demiton` | Ask a natural-language question. Demiton reads the register (or view) you name at the coordinates you supply and returns compact, cited records for your tier. Read-only. | | `tell_demiton` | Propose a write to a connected system - queued for admin approval at **HQ → Approvals** - or record a fact into Civil Memory. | | `instruct_demiton` | Trigger a Demiton platform agent, or poll a run you already triggered. Platform-only: the caller must hold `platform:manage_workflows` in at least one organisation. | | `switch_org` | Change which organisation the connection answers for, when the user asks about a different organisation. | Report tools are not advertised separately: `list_reports`, `run_report`, and `get_report_run` are reachable through `ask_demiton`'s `view` parameter. See [MCP tools](/access/mcp-tools) for the generated record of the tool list. ### Connected tier On the Connected tier, `ask_demiton` can also reach the live data in your integrated systems (ERP, field ops, payroll, documents). You do not need separate tools - just ask `ask_demiton`. For example: - **Project intelligence** - ask about project financials, budget variance and its drivers, cost-code breakdowns, induction requirements, and the civil memory accumulated for a project. - **Workforce** - ask which workers are on a project, a worker's skills and inductions, the plant a worker can operate, who is qualified for a role or asset, who is available near a location, and the memory accumulated for a worker. - **Assets** - ask which plant is on a project, an asset's charge rate, who is qualified to operate it, and the memory accumulated for an asset. - **Site data** - ask Demiton to search site diaries, safety forms, toolbox talks, inspection records, and resource allocations. - **Procurement** - ask about historical procurement records and the memory accumulated for a vendor (performance, payment history, scope patterns). For repeatable, structured output, use `ask_demiton` with a report `view`. --- ## What questions can I ask Demiton through Claude? Once connected, you can ask your AI assistant questions like: - *"What's the current budget position on Pacific Highway?"* - *"Which workers on site at Burringbar are qualified to operate the excavator?"* - *"Show me safety incidents recorded in the last two weeks."* - *"What were the ground conditions on the Cunningham Gap project last month?"* - *"Who's available near postcode 4000 with earthworks experience?"* Every answer is sourced from your connected data and filtered to data you are authorised to see. --- ## Troubleshooting ### Demiton does not appear as a tool in Claude Desktop 1. **Restart Claude Desktop.** Config changes only take effect on restart - opening a new conversation is not enough. 2. **Check the config file path.** macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`. Windows: `%APPDATA%\Claude\claude_desktop_config.json`. 3. **Validate your JSON.** A single missing comma or bracket prevents the entire config from loading. Paste the file into [jsonlint.com](https://jsonlint.com) to check. 4. **Check Node.js is installed.** `mcp-remote` requires Node 18 or later. Run `node --version` in a terminal - if the command is not found, install Node from [nodejs.org](https://nodejs.org). ### The sign-in browser window opens but authentication fails 1. **Use the right sign-in method for your account.** - Invited by your organisation via Microsoft? Sign in with your **Microsoft work account**. - Signed up via Google? Use Google sign-in. - Signed up with email and password? Use that. 2. **Check your account is active.** Log in at [app.demiton.io](https://app.demiton.io) directly to confirm your account is not suspended or pending email verification. 3. **Clear the mcp-remote token cache.** Tokens are stored in `~/.mcp-remote-cache` (macOS/Linux) or `%APPDATA%\mcp-remote-cache` (Windows). Delete the folder and reconnect. ### I get 401 Unauthorized on every tool call - **API key auth:** the key may have been rotated or deleted. Generate a new key in **HQ → API Keys** and update your config. - **OAuth (mcp-remote):** your session has expired. Delete `~/.mcp-remote-cache` and reconnect to get a fresh token. ### Claude says it cannot access my data or returns empty results - **Insights tier:** Upload your contract and estimating data at [app.demiton.io](https://app.demiton.io) before querying. The MCP reads from your uploaded data - there is nothing to return until data is indexed. See [Uploading Your Data](/getting-started/uploading-your-data). - **Connected tier:** At least one system must be connected and synced before live data is returned. See [Connecting a System](/getting-started/connecting-a-system). - **Wrong tier:** Some data sources require a higher tier. Live integrated-system data requires Connected. If you are on Public or Insights, `ask_demiton` will only return data your tier permits. ### `ask_demiton` cannot find a project I named Refer to the project by its exact code (e.g. `P2025-001`) or a distinctive name fragment (e.g. `Silverwater` or `Parramatta Rail`). Avoid generic fragments like `Road Upgrade` that could match multiple projects. Project codes are shown on the Projects surface in the Demiton app. ### Claude returns a quota exceeded error Your organisation has reached its monthly MCP call limit for your plan. Contact [support@demiton.io](mailto:support@demiton.io) or review usage in **HQ → Billing**. ### ChatGPT shows an error when adding the connector 1. **Check the Server URL.** It must be exactly `https://api.demiton.io/mcp` with no trailing slash. 2. **Leave the advanced OAuth panel unchanged.** ChatGPT discovers the OAuth configuration automatically - do not fill in the authorization or token endpoint fields manually. 3. **Sign in with the right account.** When the OAuth prompt appears, use your Demiton account (the same email and provider you used to sign up at app.demiton.io). ### Still stuck? Email [support@demiton.io](mailto:support@demiton.io) with your account email, the error message or symptom, which client you are using (Claude Desktop, Claude Code, claude.ai, ChatGPT, or other), and your operating system. --- ## Next steps - [Uploading Your Data](/getting-started/uploading-your-data) - Insights customers: upload contracts and estimating data to start querying - [Connecting a System](/getting-started/connecting-a-system) - Connected customers: connect your ERP, field ops, and payroll systems - [API Access](/access/api) - programmatic access via API key (Connected tier) - [Connectors overview](/connectors/overview) - all systems Demiton integrates with --- ## [TECHNICAL_REFERENCE] What MCP tools does Demiton provide? Description: The four tools a Demiton MCP connection lists - ask_demiton, tell_demiton, instruct_demiton and switch_org - and what each one does. URL: https://docs.demiton.io/access/mcp-tools/ A Demiton MCP connection lists **four tools**. This page is the single, generated record of them: it is built from `packages/api/app/runtime/mcp/tool_registry.py`, so it cannot drift from what your AI client actually sees. Most work happens through `ask_demiton`. You do not call a tool per data source - you ask a question and Demiton routes it to the registers and public sources your tier permits. If you are looking for a tool named after a specific system or report, it does not exist; ask for the record instead. The MCP tools a Demiton connection lists ToolWhat it does - `ask_demiton`: Ask any question in natural language. Demiton routes it to the registers and public sources your tier permits and answers with citations. - `exa_search`: Search the live web for something Demiton does not hold - a supplier page, a release note, a current figure. Available on Insights and above, and metered per search. - `tell_demiton`: Propose a write to a connected system, or record a durable fact. Writes go to your approval queue rather than executing directly. - `switch_org`: Change which organisation this connection answers for, when you belong to more than one. ## Other tools you may see referenced Some names appear in older documentation or in Demiton's internal surfaces but are **not** in your tool list: Tools that are registered but not advertised to a tenant ToolStatus - `list_reports`: UNLISTED - folded into ask_demiton(view=…), sunset 2026-12-09. - `run_report`: UNLISTED - folded into ask_demiton(view=…), sunset 2026-12-09. - `get_report_run`: UNLISTED - folded into ask_demiton(view=…), sunset 2026-12-09. - `build_work`: UNLISTED - replaced by forge. - `build_status`: UNLISTED - replaced by forge. - `queue_work`: UNLISTED - replaced by forge. Report runs and listing are reached through `ask_demiton` with a `view`, and by the REST API at `/api/v1/reports`. See [API access](/access/api). ## Connecting See [MCP Server](/access/mcp-server) for the connection steps, authentication and per-user identity. The server is available on every tier, including the free [Public tier](/overview/platform#tiers) - what changes between tiers is the data a tool can read, not the tool list.

Start free and ask your first question, or{' '} talk to us about connecting your own systems.

--- ## [CONNECTOR] Azure AI Foundry connector for model inference Description: Azure AI Foundry connector for LLM inference behind Studio chat, document intelligence and workflow steps. Platform-managed. URL: https://docs.demiton.io/connectors/cognitive/azure-ai-foundry/ Azure AI Foundry is the default AI inference provider for the Demiton platform. The adapter invokes Azure AI Foundry's deployment API for the Studio chat interface, document intelligence, and workflow LLM steps. **Authentication:** Platform-managed (Entra ID managed identity) **System type:** `AZURE_FOUNDRY` **API reference:** [Azure AI Foundry](https://learn.microsoft.com/en-us/azure/ai-studio/) Run Demiton inference on your Azure AI Foundry deployment — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-azure-ai-foundry). --- ## Integration model This connector is configured and managed by Demiton as part of your deployment - you do not supply credentials or manage the connection yourself. The adapter is currently in Beta. The `CHECK_HEALTH` command is implemented for connectivity verification. Full deployment management integration is in progress. --- ## Connection setup No tenant credentials are required or accepted. This connector is configured and managed by Demiton as part of your deployment. --- ## Security **Access type:** Platform-managed - inference only Demiton calls the Azure AI Foundry inference API under its managed identity. Document content and query context is sent to the model for the duration of inference only - it is not stored by the AI provider beyond the request lifetime. No customer data is used for model training. All inference runs under Demiton's managed identity, not under individual user credentials. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Civil Memory](/start-here/civil-memory) - where connector data lands and is retrieved from - [MCP Server](/access/mcp-server) - cognitive capabilities power the AI layer behind MCP queries - [Connect your operation](https://demiton.io/contact?ref=docs-azure-ai-foundry) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Discord connector for workflow notifications Description: Discord connector for sending workflow notifications and alerts to channels by webhook URL or bot token. Outbound delivery only. URL: https://docs.demiton.io/connectors/comms/discord/ Discord connector for delivering workflow notifications and alerts to Discord channels via webhook or bot token. **Authentication:** Webhook URL or bot token **System type:** `DISCORD` **API reference:** [Discord API](https://discord.com/developers/docs/intro) Get Demiton alerts delivered to Discord — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-discord). --- ## Supported resources | Resource | FETCH | PUSH | EXECUTE | |---|:---:|:---:|:---:| | `messages` | ✓* | ✓ | ✓ | \* FETCH returns webhook or channel metadata only - not message history. PUSH sends a message. EXECUTE supports the `SEND_ALERT` command. --- ## Integration model Supports two authentication modes: - **Webhook** - provide a channel webhook URL; simpler setup, channel-scoped - **Bot token** - provides access to multiple channels; can fall back to a platform-managed bot if no credentials are supplied --- ## Connection setup Provide either: - **Webhook URL** - the Discord channel webhook URL, or - **Bot Token** + **Channel ID** - a Discord bot token and the target channel ID --- ## Security **Access type:** Write-only (outbound delivery) Demiton sends messages to Discord channels. It does not read message history or channel content. **Permissions required:** Bot token with `Send Messages` on the target channels, or a webhook URL scoped to a specific channel. Do not grant administrator permissions to the Demiton bot. Treat webhook URLs as credentials - rotate them if exposed. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Microsoft Teams](/connectors/comms/teams) - the channel-based notification alternative - [Connect your operation](https://demiton.io/contact?ref=docs-discord) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] SendGrid connector for transactional email Description: SendGrid connector for transactional email delivery with base64 attachments from workflow pipelines. Write-only outbound delivery. URL: https://docs.demiton.io/connectors/comms/sendgrid/ SendGrid transactional email connector for high-volume email delivery. Supports attachments - primarily used for delivering vendor statements, reports, and other generated documents from workflow pipelines. **Authentication:** API key **System type:** `SENDGRID` **API reference:** [SendGrid Mail Send API](https://docs.sendgrid.com/api-reference/mail-send/mail-send) Deliver Demiton workflow email through SendGrid — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-sendgrid). --- ## Supported resources | Resource | EXECUTE | |---|:---:| | `email` | ✓ | EXECUTE with action `SEND` delivers an email with optional base64-encoded file attachments. Message IDs are tracked for delivery confirmation. --- ## Integration model The adapter calls SendGrid's Mail Send API with an API key. Messages are sent with optional base64-encoded attachments, and the returned message IDs are tracked for delivery confirmation. --- ## Connection setup Required values: - **API Key** - a SendGrid API key - **From Email** - the verified sender email address - **From Name** *(optional)* - display name for the sender --- ## Security **Access type:** Write-only (outbound delivery) Demiton sends transactional emails via SendGrid. It does not access email history, contact lists, or any SendGrid analytics. **Permissions required:** SendGrid API key with `Mail Send` permission only. Use a restricted key - do not use a full-access API key. Rotate the API key on a regular schedule. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [SMTP](/connectors/comms/smtp) - self-hosted email delivery alternative - [Connect your operation](https://demiton.io/contact?ref=docs-sendgrid) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] SMTP Email connector for workflow delivery Description: Generic SMTP connector for sending workflow email notifications and documents over TLS or STARTTLS. Write-only outbound delivery. URL: https://docs.demiton.io/connectors/comms/smtp/ Generic SMTP connector for sending email notifications and delivering documents (PDFs, reports) from workflow pipelines. Compatible with Gmail, Outlook, SendGrid SMTP relay, and any standard SMTP server. **Authentication:** Username and password (TLS/STARTTLS) **Connection type:** `SMTP` Deliver Demiton workflow email through your own SMTP server — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-smtp). --- ## Supported resources | Resource | EXECUTE | |---|:---:| | `email` | ✓ | EXECUTE with action `SEND` delivers an email. Supports MIME multipart messages and attachments. --- ## Integration model On EXECUTE `SEND` the adapter opens a TLS or STARTTLS session to the configured host and delivers a MIME multipart message, including attachments, to the SMTP server. --- ## Connection setup Required values: - **Host** - SMTP server hostname - **Port** - typically 587 (STARTTLS) or 465 (TLS) - **Username** - **Password** - **Use TLS** - enable for port 587 --- ## Security **Access type:** Write-only (outbound delivery) Demiton sends email via SMTP. It does not read email, access mailboxes, or retrieve any data from the mail server. **Permissions required:** SMTP credentials for an account authorised to send on behalf of your organisation. Use a dedicated service account - not a personal email account. Use app passwords or OAuth-based SMTP authentication where supported by your mail provider. Rotate credentials regularly. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [SendGrid](/connectors/comms/sendgrid) - hosted email delivery alternative - [Microsoft Teams](/connectors/comms/teams) - channel-based notification alternative - [Connect your operation](https://demiton.io/contact?ref=docs-smtp) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Microsoft Teams connector for workflow alerts Description: Microsoft Teams connector for sending adaptive card notifications and approval requests from workflows. Outbound delivery only. URL: https://docs.demiton.io/connectors/comms/teams/ Microsoft Teams connector for delivering workflow notifications and approval requests to Teams channels or users via adaptive cards. Supports both Graph API and webhook delivery. **Authentication:** OAuth 2.0 via Entra ID service principal **System type:** `MS_TEAMS` **API reference:** [Microsoft Graph - Teams API](https://learn.microsoft.com/en-us/graph/api/resources/teams-api-overview) Get Demiton's answers delivered to Microsoft Teams — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-teams). --- ## Supported resources | Resource | PUSH | EXECUTE | |---|:---:|:---:| | `channels` | ✓ | ✓ | | `webhooks` | ✓ | | PUSH sends an adaptive card message to a channel or user. EXECUTE supports `REQUEST_APPROVAL` - sends an interactive approval card and waits for a response, used in governance gate workflows. --- ## Integration model Supports two delivery modes: - **Graph API** - uses the service principal for authenticated delivery to any channel the principal has access to - **Webhook** - delivers to a specific channel via an incoming webhook URL (simpler setup, no Graph permissions needed) Adaptive cards are constructed from workflow output - tables, summaries, and structured data are formatted automatically. --- ## Connection setup Required values: - **Tenant ID** - **Client ID** - Entra app registration - **Client Secret** For webhook delivery, provide the **Webhook URL** instead. --- ## Security **Access type:** Write-only (outbound delivery) Demiton sends messages and approval cards to Teams channels. It does not read message history, channel membership, or any other Teams data. **Permissions required:** Service principal with `ChannelMessage.Send` (for channel messages) or `Chat.ReadWrite` (for direct messages), depending on your workflow configuration. Grant the minimum scope required. Message content delivered through Demiton workflows is subject to the same approval gates as any other workflow output. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [SMTP](/connectors/comms/smtp) - email delivery alternative for workflow notifications - [MCP Server](/access/mcp-server) - query connected data and route results to Teams channels - [Connect your operation](https://demiton.io/contact?ref=docs-teams) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Microsoft Dataverse connector for Power Platform Description: Microsoft Dataverse connector for entity reads, record creation, single-record lookups and CRM actions. Read and approved write. URL: https://docs.demiton.io/connectors/datasource/dataverse/ Microsoft Dataverse connector for the Power Platform data layer. Supports entity reads, record creation, single-record lookup, and CRM action execution. **Authentication:** OAuth 2.0 via Entra ID service principal **System type:** `DATAVERSE` **Protocol:** OData v9.2 **API reference:** [Dataverse Web API](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/webapi/overview) See your Dataverse records in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-dataverse). --- ## Supported resources | Resource | FETCH | PUSH | LOOKUP | EXECUTE | |---|:---:|:---:|:---:|:---:| | `entities` | ✓ | | | | | `records` | ✓ | ✓ | ✓ | | | `actions` | | | | ✓ | FETCH on `entities` lists available entity types. FETCH on `records` queries entity records with OData filters (`$filter`, `$select`, `$top`, `$orderby`). LOOKUP retrieves a single record by key. EXECUTE routes CRM actions via `Microsoft.Dynamics.CRM.{action}`. --- ## Integration model The adapter acquires an OAuth 2.0 client-credentials token from Entra ID and calls the Dataverse Web API at version `v9.2`. FETCH on `records` passes the OData query options through to the service, and LOOKUP resolves a single record by key. Writes respect simulation mode - a dry run validates the payload without creating a record. --- ## Connection setup Required values: - **Tenant ID** - **Client ID** - Entra app registration - **Client Secret** - **Environment URL** - your Dataverse environment URL (e.g. `https://yourorg.crm.dynamics.com`) --- ## Security **Access type:** Read and approved write Demiton reads entity records and can create records via approved workflows. CRM action execution also occurs only through approved workflows. **Permissions required:** Service principal with Dataverse application user access scoped to the specific tables your workflows use. Do not grant system administrator privileges to the Demiton service principal. Use a dedicated app registration for Demiton and rotate credentials on a regular schedule. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Business Central](/connectors/erp/business-central) - the companion ERP connector for organisations on Dynamics 365 - [MCP Server](/access/mcp-server) - query Dataverse entities through Claude once connected - [Connect your operation](https://demiton.io/contact?ref=docs-dataverse) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Dropbox connector for document migration Description: Dropbox connector for reading files, folders and shared folder membership in migration workflows. Read-only file access. URL: https://docs.demiton.io/connectors/datasource/dropbox/ Dropbox connector for reading files, folders, and shared folder membership. Primarily used for document migration workflows - retrieving content from legacy Dropbox Business accounts for indexing or transfer to SharePoint. **Authentication:** OAuth 2.0 (refresh token) **System type:** `DROPBOX` **API reference:** [Dropbox API v2](https://www.dropbox.com/developers/documentation/http/documentation) See your Dropbox files in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-dropbox). --- ## Supported resources | Resource | FETCH | LOOKUP | |---|:---:|:---:| | `folders` | ✓ | | | `files` | ✓ | ✓ | | `account_space` | ✓ | | | `shared_folders` | ✓ | | | `folder_members` | | ✓ | FETCH on `files` supports recursive traversal or flat listing, with optional extension filtering. LOOKUP on `files` downloads the file content. LOOKUP on `folder_members` returns the member list for a shared folder. This connector is read-focused - Demiton does not write files to Dropbox. --- ## Integration model The adapter authenticates with a long-lived OAuth 2.0 refresh token and calls Dropbox API v2. FETCH on `files` supports recursive or flat listing with optional extension filtering; LOOKUP downloads file content or returns the member list of a shared folder. --- ## Connection setup Required values: - **App Key** - Dropbox app key - **App Secret** - Dropbox app secret - **Refresh Token** - obtained via the Dropbox OAuth flow --- ## Security **Access type:** Read-only Demiton reads files and folder metadata from Dropbox. No files are written or deleted. **Permissions required:** Dropbox OAuth app with access scoped to the folders your workflows need. Use the minimum Dropbox permission scope required - `files.content.read` and `sharing.read` for most workflows. **Data sensitivity:** Depends on the content stored. Document access in Demiton is subject to identity-bound access controls. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [SharePoint](/connectors/datasource/sharepoint) - alternative document store connector - [MCP Server](/access/mcp-server) - query Dropbox documents through Claude once connected - [Connect your operation](https://demiton.io/contact?ref=docs-dropbox) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Excel and static file upload connector Description: Excel and static file upload connector for reading spreadsheet worksheets into workflow pipelines. Read-only spreadsheet access. URL: https://docs.demiton.io/connectors/datasource/excel/ Excel and static file upload connector for ingesting structured spreadsheet data. Each worksheet in an uploaded file becomes a fetchable resource. Used for one-off data imports and bootstrapping workflows from existing spreadsheets. **Authentication:** None - file upload only **Connection type:** `STATIC_UPLOAD` Bring your spreadsheets into Claude with Demiton — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-excel). --- ## Supported resources Resources are discovered dynamically from the uploaded file - each worksheet name becomes a resource. | Resource | FETCH | LOOKUP | |---|:---:|:---:| | Per-sheet (dynamic) | ✓ | ✓ | FETCH reads the sheet as structured records. LOOKUP finds a row by matching a specific column value. A `DISCOVER_SCHEMA` command is available to inspect the sheet structure before building a workflow. This connector is read-only - no data is written back to the uploaded file. --- ## Integration model The adapter treats the workbook as a database: the workbook is the database and each worksheet is a table. The file is read from cloud storage into a pandas frame at fetch time, so the sheet structure is discovered rather than declared. A `DISCOVER_SCHEMA` command inspects a sheet's columns and types before a workflow is built against it. --- ## Connection setup No credentials are required. During connection setup, upload the Excel file directly. The file is stored encrypted in Demiton's secure storage and made available as a data source. --- ## Security **Access type:** One-way upload - no ongoing connection There is no persistent connection to an external system. The uploaded file is stored encrypted within Demiton's secure storage. No credentials are required or stored. Uploaded files are subject to the same identity-bound access controls as any other data source. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Uploading Your Data](/getting-started/uploading-your-data) - Insights customers use uploads instead of the Excel connector - [SharePoint](/connectors/datasource/sharepoint) - SharePoint is the preferred document store for large-scale deployments - [Connect your operation](https://demiton.io/contact?ref=docs-excel) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] SFTP connector for secure file transfer Description: Generic SFTP connector for secure file retrieval, delivery and directory management over SSH. Read and approved write access. URL: https://docs.demiton.io/connectors/datasource/sftp/ Generic SFTP connector for reading and writing files via secure file transfer. Used as a protocol connector for any system that exposes data over SFTP. **Authentication:** SSH key or password **Connection type:** `SFTP` Bring your SFTP files into Demiton workflows — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-sftp). --- ## Supported resources | Resource | FETCH | PUSH | LOOKUP | EXECUTE | |---|:---:|:---:|:---:|:---:| | `files` | ✓ | ✓ | ✓ | ✓ | FETCH supports two modes: - **EXPLORER** - recursive directory listing (up to 3 levels deep) - **CONTENT** - file download LOOKUP stats a single file path. EXECUTE supports the `DELETE` command. --- ## Integration model The adapter holds a `paramiko` SSH session for the connection and translates the standard EXPLORER and CONTENT modes onto SFTP list, stat and open calls. EXPLORER recursion is capped at three levels. Uploads and deletes are approved write operations and respect simulation mode: a dry run reports what would be transferred without touching the server. --- ## Connection setup Required values: - **Host** - **Port** - default 22 - **Username** - **Password** or **Private Key** (SSH key authentication) --- ## Security **Access type:** Read and approved write Demiton retrieves files and can deliver files (generated reports, payment files) back via approved workflows. Delete operations also go through approved workflows. **Permissions required:** SFTP account credentials scoped to the directories your workflows need. Use a dedicated SFTP user for Demiton. Use SSH key authentication over password where possible. Rotate credentials on a regular schedule. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [SQL](/connectors/datasource/sql) - for database-backed data sources - [Banking](/connectors/finance/banking) - SFTP is also used for banking file transfer - [Connect your operation](https://demiton.io/contact?ref=docs-sftp) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] SharePoint connector for construction documents Description: SharePoint connector for document retrieval, list access and approved site and library permission provisioning. Read and write. URL: https://docs.demiton.io/connectors/datasource/sharepoint/ Microsoft SharePoint connector for document retrieval, list access, and site administration via the Microsoft Graph API. All document retrieval is ACL-filtered per user identity - users see only documents their Entra group memberships grant access to. **Authentication:** OAuth 2.0 via Entra ID service principal **System type:** `SHAREPOINT` **Protocol:** Microsoft Graph API v1 **API reference:** [Microsoft Graph - SharePoint](https://learn.microsoft.com/en-us/graph/api/resources/sharepoint) See your SharePoint documents in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-sharepoint). --- ## Supported resources | Resource | FETCH | PUSH | LOOKUP | |---|:---:|:---:|:---:| | `sites` | ✓ | | | | `drives` | ✓ | | | | `documents` | ✓ | ✓ | ✓ | | `lists` | ✓ | | ✓ | | `site_by_path` | ✓ | | | | `site_collection` | | ✓ | | | `document_library` | | ✓ | | | `library_permission` | | ✓ | | | `file_to_library` | | ✓ | | LOOKUP on `documents` downloads a specific file. PUSH to `library_permission` binds an Entra security group to a library at a specified role (Read or Contribute). --- ## Integration model The adapter uses a service principal with application-level Graph API permissions. Only the sites and libraries you bind to the connector are read. Site provisioning operations (creating site collections, document libraries, and binding permissions) are used in project scaffolding workflows when a new project or opportunity is created. --- ## Connection setup Required values: - **Tenant ID** - **Client ID** - Entra app registration - **Client Secret** --- ## Security **Access type:** Read and provisioning write Demiton reads documents and lists from SharePoint. Document retrieval is ACL-filtered per user - each user sees only documents the Entra groups they belong to are permitted to access. The service principal's broad permissions are used only for administrative operations (site and library provisioning); individual user data access is always mediated through group membership. Provisioning writes (creating folder structures, setting library permissions) occur only through approved project scaffolding workflows. **Permissions required:** Service principal with `Sites.FullControl.All` via Microsoft Graph. **What Demiton does not touch:** Demiton does not modify document content, does not change user permissions directly, and does not access documents outside the group memberships of the requesting user. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Dropbox](/connectors/datasource/dropbox) - alternative document store connector - [MCP Server](/access/mcp-server) - query SharePoint documents through Claude once connected - [Connect your operation](https://demiton.io/contact?ref=docs-sharepoint) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] SQL Database connector for read-only queries Description: Generic SQL connector for read-only queries against PostgreSQL and Microsoft SQL Server tables and views. Read-only database access. URL: https://docs.demiton.io/connectors/datasource/sql/ Generic SQL connector for querying relational databases. Tables are discovered dynamically from the database schema. Supports PostgreSQL and Microsoft SQL Server. **Authentication:** Connection string (dialect, host, port, username, password, database) **Connection type:** `SQL` **Supported dialects:** PostgreSQL (`postgresql+psycopg2`), SQL Server (`mssql+pyodbc`) See your SQL database tables in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-sql). --- ## Supported resources Resources are discovered dynamically - each table in the target schema becomes a fetchable resource. | Resource | FETCH | LOOKUP | |---|:---:|:---:| | Per-table (dynamic) | ✓ | ✓ | FETCH runs `SELECT *` with a configurable row limit (default 100). LOOKUP retrieves rows matching a specific column/value pair. This connector is read-only - write and execute operations are not supported. --- ## Integration model The adapter builds a SQLAlchemy engine from the connection string and inspects the database schema to discover tables and views. Each table or view becomes a fetchable resource; nothing is declared in advance. FETCH runs a `SELECT` with a configurable row limit (default 100). LOOKUP retrieves rows matching a single column/value pair. Relationships between tables are not modelled - joins are expressed in the workflow, not the connector. --- ## Connection setup Required values: - **Dialect** - `postgresql` or `mssql` - **Host** - **Port** - **Username** - **Password** - **Database** - **Schema** *(optional)* - defaults to `public` for PostgreSQL --- ## Security **Access type:** Read-only Demiton queries your database using the credentials provided. No data is written. **Permissions required:** A database user with `SELECT` access on the specific tables or views your workflows query. Do not use an admin or owner account - create a dedicated read-only user for Demiton. **Best practice:** Connect Demiton to a read replica if one is available, to avoid any impact on production database performance. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [SFTP](/connectors/datasource/sftp) - file-based data source alternative - [MCP Server](/access/mcp-server) - query SQL data through Claude once connected - [Connect your operation](https://demiton.io/contact?ref=docs-sql) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Business Central connector for civil contractors Description: Microsoft Dynamics 365 Business Central connector for project financials, vendors, purchase orders, ledger and budget reads. URL: https://docs.demiton.io/connectors/erp/business-central/ Microsoft Dynamics 365 Business Central is a common ERP in civil construction. The adapter reads and writes Business Central data via OData v4, normalising responses before they enter the workflow runtime. **Authentication:** OAuth 2.0 via Entra ID service principal **System type:** `D365_BUSINESS_CENTRAL` **Protocol:** OData v4 **API reference:** [Business Central OData API](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/) See your Business Central data in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-business-central). --- ## Supported resources Resources are discovered dynamically from your Business Central environment's OData schema. Common resources used in construction workflows: | Resource | FETCH | PUSH | LOOKUP | |---|:---:|:---:|:---:| | `projects` | ✓ | | ✓ | | `vendors` | ✓ | ✓ | ✓ | | `project_ledger_entries` | ✓ | ✓ | | | `purchase_orders` | ✓ | ✓ | | | `items` | ✓ | ✓ | ✓ | | `customers` | ✓ | ✓ | ✓ | | `general_ledger_entries` | ✓ | | | Any entity exposed by your BC OData endpoint can be targeted in a workflow - the adapter probes the schema on first use. --- ## Integration model Authentication uses OAuth 2.0 client credentials - a service principal registered in Azure Entra ID is granted application-level access to the Business Central environment. The adapter probes BC's OData metadata endpoint to discover the available entities and their fields before execution. Writes are protected by a **Protocol Zero safety lock**: any write targeting a `PRODUCTION` environment requires explicit confirmation in the workflow configuration. All write operations support simulation mode - intent is logged and validated without committing to BC. --- ## Connection setup Required values: - **Tenant ID** - your Azure Entra ID tenant - **Client ID** - the Entra app registration client ID - **Client Secret** - the app registration secret - **Environment URL** - your BC environment URL (e.g. `https://api.businesscentral.dynamics.com/v2.0/{tenant}/production`) --- ## Example workflow ``` FETCH → assignar.site_diary TRANSFORM → extract_labour_entries TRANSFORM → normalize_cost_categories PUSH → business_central.profit_and_loss ``` --- ## Security **Access type:** Read and approved write Demiton reads project data, vendor records, job ledger entries, and purchase orders from Business Central. Writes occur only through approved workflows with explicit approval gates - Demiton never modifies BC data outside of a committed, audited workflow run. A Protocol Zero safety lock prevents any write to a PRODUCTION environment unless the workflow has been explicitly configured for production execution. **Permissions required:** OAuth 2.0 service principal with OData access scoped to the specific BC entities your workflows use. Assign the minimum BC permission sets needed - typically `Jobs`, `Purchase`, and `Vendor` for common construction workflows. **What Demiton does not touch:** BC user accounts and permission sets are owned by Business Central. Demiton reads BC permission sets to inform access resolution but never writes to them. - Create a dedicated Entra app registration for Demiton - one per environment (UAT and Production) - Restrict API scopes to required entities only - Rotate client secrets on a 90-day schedule or less - Always test workflows against a sandbox BC environment before enabling production execution --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Assignar](/connectors/operational/assignar) - the typical partner integration: site diaries and allocations cross-posted to BC - [MCP Server](/access/mcp-server) - query your BC financials through Claude once connected - [Connect your operation](https://demiton.io/contact?ref=docs-business-central) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Finance & Operations connector for enterprise ERP Description: Microsoft Dynamics 365 Finance & Operations connector for enterprise financial reads and approved OData batch writes to data entities. URL: https://docs.demiton.io/connectors/erp/finops/ Microsoft Dynamics 365 Finance & Operations (FinOps) connector for enterprise-scale financial data retrieval and posting. **Authentication:** OAuth 2.0 via Entra ID service principal **System type:** `D365_FINOPS` **Protocol:** OData v4 **API reference:** [Finance & Operations OData API](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/odata) See your Finance & Operations data in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-finops). --- ## Supported resources Resources are discovered from your Finance & Operations OData endpoint. The adapter supports batch fetch and batch write operations against standard F&O data entities. | Resource | FETCH | PUSH | |---|:---:|:---:| | OData entities (dynamic) | ✓ | ✓ | --- ## Integration model Uses OAuth 2.0 client credentials to authenticate against the F&O OData v4 endpoint. The adapter performs batch fetch and batch write operations. EXECUTE and LOOKUP verbs are not currently supported. This connector is in Beta - it is functional for read and batch write workflows but does not yet support the full feature set of the Business Central adapter. --- ## Connection setup Required values: - **Client ID** - the Entra app registration client ID - **Client Secret** - the app registration secret - **Environment URL** - your F&O OData endpoint --- ## Security **Access type:** Read and approved write Demiton reads and writes F&O data entities via OData. Writes occur only through approved workflows. Use a dedicated Entra service principal with the minimum data entity access required. **What Demiton does not touch:** F&O user accounts, security roles, and access control remain owned by Finance & Operations. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Business Central](/connectors/erp/business-central) - the stable companion ERP connector - [MCP Server](/access/mcp-server) - query your F&O data through Claude once connected - [Connect your operation](https://demiton.io/contact?ref=docs-finops) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Universal Banking connector for bank files Description: Universal Banking connector for SFTP statement retrieval and host-to-host payment file delivery with PGP. Read and write. URL: https://docs.demiton.io/connectors/finance/banking/ The Universal Banking connector handles SFTP-based bank file exchange - retrieving statements and delivering payment files to your bank's host-to-host (H2H) endpoint. Supported banks include Westpac, CommBiz, NAB, and ANZ. **Authentication:** SFTP - host, port, username, password; optional PGP public key for encrypted delivery **System type:** `BANKING_GENERIC` **Protocol:** SFTP with optional PGP encryption See your bank statements and balances in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-banking). --- ## Supported resources | Resource | FETCH | PUSH | EXECUTE | |---|:---:|:---:|:---:| | `files` | ✓ | ✓ | ✓ | FETCH supports two modes: - **EXPLORER** - recursive directory listing with file metadata - **CONTENT** - file download EXECUTE supports: `DOWNLOAD`, `DELETE`, `ECHO_TEST` --- ## Integration model The adapter connects to your bank's SFTP endpoint. Files can be retrieved (statements, reports) or uploaded (payment instructions, payroll files). When a PGP public key is configured, outbound files are encrypted before delivery. Payment files follow the naming convention `PAY_YYYYMMDD_HHMMSS` and are generated automatically. An echo test command is available to verify connectivity without transferring real data. --- ## Connection setup Required values: - **Host** - bank SFTP hostname - **Port** - typically 22 - **Username** - SFTP account username - **Password** - SFTP account password - **Bank Public Key** *(optional)* - PGP public key for encrypted file delivery --- ## Security **Access type:** Read and approved write Demiton retrieves bank files (statements, reports) and delivers payment files to the bank's SFTP endpoint. File uploads only occur through approved workflows with explicit approval gates. **Permissions required:** SFTP credentials with access to the directories your workflows use. Use a dedicated SFTP account for Demiton. **Data sensitivity:** Banking data is classified as financial domain - restricted to users with appropriate access. Payment files carry financial instructions and should be treated with the same care as other financial authorisations. Use SSH key authentication where your bank supports it. Rotate credentials on a regular schedule. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Employment Hero Payroll](/connectors/finance/keypay) - the payroll connector, typically used alongside banking - [Business Central](/connectors/erp/business-central) - reconcile bank transactions against your ERP ledger - [Connect your operation](https://demiton.io/contact?ref=docs-banking) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Employment Hero Payroll (KeyPay) connector for construction payroll Description: Employment Hero Payroll (KeyPay) connector for employees, pay runs, timesheets and leave. Payroll reads plus approved write-back for employees and timesheets. URL: https://docs.demiton.io/connectors/finance/keypay/ Employment Hero Payroll (formerly KeyPay) is a payroll platform used to manage employee pay runs, timesheets, leave, and employment agreements. Demiton integrates with Employment Hero Payroll to retrieve payroll records and reconcile labour costs against field data from Assignar, and to support workforce lifecycle workflows. **Authentication:** API key **System type:** `KEYPAY` **API reference:** [KeyPay API](https://keypay.yourpayroll.com.au/swagger) See your Employment Hero Payroll data in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-keypay). --- ## Supported resources | Resource | FETCH | PUSH | |---|:---:|:---:| | `employees` | ✓ | ✓ | | `payruns` | ✓ | | | `timesheets` | ✓ | ✓ | | `leaverequests` | ✓ | ✓ | | `locations` | ✓ | | | `paycategories` | ✓ | | | `leavecategories` | ✓ | | | `deductioncategories` | ✓ | | | `payschedules` | ✓ | | | `payrateschedules` | ✓ | | | `employmentagreements` | ✓ | | | `qualifications` | ✓ | | | `Business` | ✓ | | Pagination is handled automatically (100 records per page). All resources are scoped to your Employment Hero Payroll business ID. --- ## Integration model Records are retrieved and normalised into `PayrollRecord` business objects with fields: employee, period, hours, gross cost. Worker identities are resolved across systems using a stable employee ID as the cross-system join key. ### Labour reconciliation The primary use case is reconciling payroll totals against field system data: - Hours recorded in Assignar are compared against payroll hours - Discrepancies are surfaced as variance records for review - Simulation is not on by default; it is enabled per run, and production writes are queued for admin approval ### Workforce mirroring Demiton supports Employment Hero Payroll→Assignar employee mirroring as part of workforce lifecycle workflows. When an employee is added or updated in Employment Hero Payroll, the record can be propagated to Assignar - maintaining a consistent worker identity across payroll and field systems without manual data entry. Mirroring runs through the Workflow Runtime; simulation is not enabled by default. It is enabled per run, and production writes are queued for admin approval. --- ## Connection setup Required values: - **API Key** - an Employment Hero Payroll API key with access to your business - **Business ID** - the Employment Hero Payroll business the connector is scoped to --- ## Security **Access type:** Read and approved write Demiton reads the full range of payroll entities from Employment Hero Payroll. Write operations - creating or updating employee records, timesheets, and leave requests - occur only through approved workforce lifecycle workflows with explicit approval gates: simulation is not on by default, it is enabled per run, and production writes are queued for admin approval. **Permissions required:** Employment Hero Payroll API key with access to your business. Use a dedicated API user for Demiton. Grant the minimum access needed - for reconciliation-only workflows, read access to employees, pay runs, and timesheets is sufficient. **Data sensitivity:** Payroll data is the most sensitive data domain in Demiton. Access is restricted to payroll administrators and executives by default. Project Managers see aggregated labour cost totals for their projects but never individual pay records or rates. See the [Security Overview](/security) for the full payroll domain access model. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Assignar](/connectors/operational/assignar) - the reconciliation partner: Assignar hours vs Employment Hero Payroll hours - [Business Central](/connectors/erp/business-central) - full cost stack when ERP, field ops, and payroll are all connected - [Connect your operation](https://demiton.io/contact?ref=docs-keypay) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Xero connector for civil contractors Description: Xero accounting connector for invoices, contacts, reports and ledger reads, with approved invoice writes. Read and write. URL: https://docs.demiton.io/connectors/finance/xero/ Xero is a cloud accounting platform. Demiton reads financial data from Xero and can post invoices and contacts back via approved workflows. **Authentication:** OAuth 2.0 (authorisation code flow) **System type:** `XERO` **API reference:** [Xero Accounting API](https://developer.xero.com/documentation/api/accounting/overview) See your Xero data in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-xero). --- ## Supported resources | Resource | FETCH | PUSH | |---|:---:|:---:| | `Invoice` | ✓ | ✓ | | `Contact` | ✓ | ✓ | | `Payment` | ✓ | | | `Account` | ✓ | | | `BankTransaction` | ✓ | | | `PurchaseOrder` | ✓ | | | `Item` | ✓ | | | `CreditNote` | ✓ | | | `TrackingCategory` | ✓ | | | `Journal` | ✓ | | | `TaxRate` | ✓ | | | `Organisation` | ✓ | | | `Reports/ProfitAndLoss` | ✓ | | | `Reports/BalanceSheet` | ✓ | | | `Reports/CashSummary` | ✓ | | | `Reports/TrialBalance` | ✓ | | | `Reports/BudgetSummary` | ✓ | | | `Reports/AgedReceivablesByContact` | ✓ | | | `Reports/AgedPayablesByContact` | ✓ | | | `Budget` | ✓ | | --- ## Integration model Authentication uses Xero's standard OAuth 2.0 authorisation code flow - during connection setup you'll be redirected to Xero to authorise access. Tokens are rotated automatically by the adapter. Writes are limited to `Invoice` and `Contact` resources. All other resources are read-only. --- ## Connection setup Xero uses OAuth 2.0 - no API key is needed. During connection setup: 1. Enter your Xero app's **Client ID** and **Client Secret** (from [developer.xero.com](https://developer.xero.com)) 2. Click **Create Connector** - you'll be redirected to Xero to authorise 3. After authorising, Demiton stores the token and begins discovery --- ## Security **Access type:** Read and approved write (Invoices and Contacts only) Demiton reads the full range of Xero accounting data. Writes are limited to Invoice and Contact creation/updates through approved workflows with approval gates. **Permissions required:** Xero OAuth app with the minimum scopes your workflows need - typically `accounting.transactions`, `accounting.contacts`, and `accounting.reports.read`. **What Demiton does not touch:** Xero user accounts and access control remain owned by Xero. Demiton never modifies Xero user permissions. **Data sensitivity:** Xero financial data is classified as financial domain - restricted to users with appropriate ERP access or project-level allocation. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Business Central](/connectors/erp/business-central) - for organisations on Dynamics 365 rather than Xero - [MCP Server](/access/mcp-server) - query Xero financial data through Claude once connected - [Connect your operation](https://demiton.io/contact?ref=docs-xero) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Microsoft Entra ID connector for identity Description: Microsoft Entra ID connector for directory reads, group membership and workforce lifecycle write-back. Read and scoped write. URL: https://docs.demiton.io/connectors/identity/entra-id/ Microsoft Entra ID is the identity backbone of the Demiton platform. Beyond authentication (handled natively via OIDC), the Entra ID adapter enables workflows to read directory data, manage group membership, and write identity attributes as part of workforce lifecycle automation. **Authentication:** OAuth 2.0 via service principal (Microsoft Graph) **System type:** `ENTRA_ID` **Protocol:** Microsoft Graph API v1 **API reference:** [Microsoft Graph - Identity](https://learn.microsoft.com/en-us/graph/api/resources/azure-ad-overview) See your Entra ID users and groups in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-entra-id). --- ## Supported resources | Resource | FETCH | PUSH | LOOKUP | EXECUTE | License | |---|:---:|:---:|:---:|:---:|:---:| | `users` | ✓ | | ✓ | | Free | | `groups` | ✓ | | ✓ | | Free | | `group_members` | ✓ | | | | Free | | `group_membership` | ✓ | ✓ | | | Free | | `user_clearance` | | | ✓ | | Free | | `security_groups` | ✓ | | | ✓ | Free | | `directory_role_assignments` | ✓ | | | | Free | | `service_principals` | ✓ | | | | Free | | `signin_logs` | ✓ | | | | P1 | | `mfa_registration` | ✓ | | | | P1 | | `risky_users` | ✓ | | | | P2 | PUSH on `group_membership` adds or removes members in batch. LOOKUP on `user_clearance` resolves a user's transitive group memberships. EXECUTE on `security_groups` supports `create_group`, `add_member`, and `remove_member` commands. `signin_logs`, `mfa_registration`, and `risky_users` are used for security audit workflows. Resources marked P1/P2 return an empty dataset (not an error) on tenants without the required Entra ID licence - the audit report will note the gap rather than failing. --- ## Integration model Used in two contexts: **Access resolution** - Demiton reads Entra user attributes and group memberships at query time to determine what data each user is authorised to see. This happens automatically for every platform interaction. **Workforce lifecycle workflows** - When a new hire is created in Employment Hero Payroll, Demiton can add them to the Entra security groups their role requires, and on termination it removes them. Group membership is the write the adapter actually performs: `add_member_to_group`, `remove_member_from_group`, `create_group` and their batch forms. Demiton does not create Entra user accounts and does not write `accountEnabled` - accounts and their enabled state remain owned by Entra. The writer also defines an HR-attribute update covering `department`, `jobTitle`, `city`, `employeeType`, `employeeId` and manager, which has no live caller today. --- ## Connection setup Required values: - **Tenant ID** - **Client ID** - Entra app registration - **Client Secret** The Entra ID connector is typically configured during platform onboarding by your Customer Success Manager. --- ## Required Graph permissions Grant these on the app registration used by the Demiton service principal. All permissions are **application** type (not delegated). | Permission | Purpose | Minimum licence | |---|---|:---:| | `User.Read.All` | Directory user reads | Free | | `Group.Read.All` | Directory group reads | Free | | `RoleManagement.Read.Directory` | Directory role assignments | Free | | `Application.Read.All` | Service principals & enterprise apps | Free | | `GroupMember.ReadWrite.All` | Group membership write-back workflows | Free | | `User.ReadWrite.All` | HR attribute write-back workflows | Free | | `AuditLog.Read.All` | Sign-in logs and MFA registration reports | P1 | | `UserAuthenticationMethod.Read.All` | MFA registration details per user | P1 | | `IdentityRiskyUser.Read.All` | Identity Protection risky user data | P2 | **Minimum for read-only directory access:** `User.Read.All`, `Group.Read.All` **For security audit workflows:** additionally `RoleManagement.Read.Directory`, `Application.Read.All`, and the P1/P2 permissions above depending on your licence **For workforce lifecycle write-back:** additionally `User.ReadWrite.All`, `GroupMember.ReadWrite.All` To grant consent: open **Entra admin centre → App registrations → [your app] → API permissions → Add permission → Microsoft Graph → Application permissions**, add each permission, then **Grant admin consent**. --- ## Security **Access type:** Read and scoped write Demiton reads identity attributes and group memberships to enforce access controls. Writes are strictly scoped to security-group membership (add and remove members, and create groups) and an HR-attribute update for HR-owned profile fields (`department`, `jobTitle`, `city`, `employeeType`, `employeeId`, `manager`). Demiton does not create Entra user accounts and does not write the `accountEnabled` flag. **What Demiton never writes:** Application role assignments, conditional access policies, or any other Entra surface outside of HR attributes and explicitly configured group-management workflows. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Security Overview](/security) - how Demiton uses Entra identity for access control across all connectors - [Business Central](/connectors/erp/business-central) - ERP connector that also uses Entra for service principal authentication - [Connect your operation](https://demiton.io/contact?ref=docs-entra-id) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] ABR connector for ABN and GST lookups Description: Australian Business Register connector for ABN, ACN, GST registration status and business entity lookups. No credentials required. URL: https://docs.demiton.io/connectors/intelligence/abr/ Australian Business Register (ABR) connector for retrieving ABN, ACN, GST status, and business entity data. Used in vendor onboarding and compliance workflows to verify supplier details against the register. **Authentication:** Platform-managed - no setup required **System type:** `ABR` **API reference:** [ABR API](https://abr.business.gov.au/Tools/AbrApi) Try it on the free Public tier - [Quickstart](/start-here/quickstart) shows real contractor ABN data from AusTender contracts. When you're ready to verify your own supplier base, [sign up for Insights](https://demiton.io/insights?ref=docs-abr). --- ## Supported resources | Resource | FETCH | LOOKUP | |---|:---:|:---:| | `lookup_by_abn` | ✓ | ✓ | | `lookup_by_acn` | ✓ | ✓ | | `search_by_name` | ✓ | ✓ | --- ## Integration model ABR is a lookup API: the adapter sends an ABN, ACN or name and returns the register's entity record. Demiton maintains the API registration centrally, so there is no per-tenant authentication step. --- ## Connection setup The ABR connector is **platform-managed** - no credentials required on your side. Demiton maintains the API registration centrally. Browse and pin ABR datasets from the Open Data Catalog (`/hq-platform/catalog` for platform administrators, or query the curated set on Insights+). --- ## Example queries via MCP Once connected through the MCP server, you can ask Claude: - *"Is [Supplier Name] GST-registered? What's their entity type?"* - *"Look up ABN 12 345 678 901 - what is this entity?"* - *"Which of our vendors have cancelled ABNs?"* - *"Verify the ACN for [company] against the register."* --- ## Security **Access type:** Read-only (public data) The ABR exposes publicly available business registry data. All data retrieved is publicly accessible - no private or sensitive information is involved. No credentials are required or stored on your account. --- ## Next steps - [MCP Server](/access/mcp-server) - connect Claude or ChatGPT to query ABR directly - [AusTender](/connectors/intelligence/austender) - cross-reference ABN data against government contract awards - [Sign up for Insights](https://demiton.io/insights?ref=docs-abr-footer) - use ABR data alongside your uploaded vendor and contract data --- ## [CONNECTOR] AusTender connector for government tender data Description: AusTender connector for Australian Government tender notices, contract awards, amendments and supplier records. No credentials. URL: https://docs.demiton.io/connectors/intelligence/austender/ AusTender is the Australian Government's procurement information system. The adapter retrieves tender notices, contract awards, contract amendments, and supplier data for use in estimating and opportunity workflows. **Authentication:** None - public API **System type:** `AUSTENDER` **API reference:** [AusTender OCDS API](https://www.tenders.gov.au/) Try this connector on real data - see [Quickstart](/start-here/quickstart) to get started. A free Demiton account is required to query via MCP - [sign up free](https://app.demiton.io/auth/register?ref=docs-austender). When you're ready to overlay AusTender data against your own contracts and rates, [sign up for Insights](https://demiton.io/insights?ref=docs-austender). --- ## Supported resources | Resource | FETCH | |---|:---:| | `awarded_contracts` | ✓ | | `contract_amendments` | ✓ | | `contract_by_id` | ✓ | | `active_tenders` | ✓ | | `agencies` | ✓ | | `contractors` | ✓ | Uses dual protocol support - OCDS v1 (Open Contracting Data Standard) for structured contract data, and RSS v2 for live tender feeds. Pagination is handled automatically. --- ## Integration model The adapter reads AusTender over two protocols: OCDS v1 for structured contract data and RSS v2 for live tender feeds. Responses are normalised before they enter the workflow runtime, and pagination is handled by the adapter. --- ## Connection setup No credentials are required - AusTender is a public API and Demiton maintains the registration centrally. There is nothing to configure on your side. --- ## Example queries via MCP Once connected through the MCP server, you can ask Claude: - *"Which civil contractors were awarded packages on Cross River Rail?"* - *"Show me federal road contracts awarded in Queensland over $5M in the last 12 months."* - *"Which agencies are the top spenders on earthworks and civil construction?"* - *"Has [Supplier Name] been awarded any government contracts in the last two years?"* --- ## Security **Access type:** Read-only (public data) AusTender is a public government API. No credentials are required or stored. All data retrieved is publicly available. --- ## Next steps - [MCP Server](/access/mcp-server) - connect Claude or ChatGPT to query AusTender directly - [ABR](/connectors/intelligence/abr) - cross-reference suppliers against the Australian Business Register - [Open Data (CKAN)](/connectors/intelligence/open-data) - Queensland and federal project datasets - [Sign up for Insights](https://demiton.io/insights?ref=docs-austender-footer) - overlay AusTender data against your uploaded contract rates --- ## [CONNECTOR] BOM Weather connector for site conditions Description: Bureau of Meteorology connector for weather observations, daily and hourly forecasts and warnings. No credentials required. URL: https://docs.demiton.io/connectors/intelligence/bom-weather/ Bureau of Meteorology (BOM) connector for retrieving weather observations, forecasts, and warnings. Used to add weather context to site diaries, assess weather impact on project delivery, and filter operational data by weather conditions. **Authentication:** None - public API **System type:** `BOM_WEATHER` **API reference:** [BOM Weather API](https://api.weather.bom.gov.au/v1/) Try it on the free Public tier - see [Quickstart](/start-here/quickstart) to overlay weather observations against project timelines. When you're ready to correlate weather data against your own site records, [sign up for Insights](https://demiton.io/insights?ref=docs-bom) or [connect your field systems](https://demiton.io/contact?ref=docs-bom-connected) on Connected. --- ## Supported resources | Resource | FETCH | LOOKUP | |---|:---:|:---:| | `location_search` | ✓ | | | `observations` | ✓ | ✓ | | `daily_forecast` | ✓ | | | `hourly_forecast` | ✓ | | | `warnings` | ✓ | | LOOKUP on `observations` retrieves current conditions by geohash (location code). --- ## Integration model The adapter calls the Bureau of Meteorology's public weather API. Location search resolves a place to a geohash, which the observation, forecast and warning resources then use. --- ## Connection setup No credentials are required - the Bureau of Meteorology API is public and Demiton maintains the registration centrally. --- ## Example queries via MCP Once connected through the MCP server, you can ask Claude: - *"What were the weather conditions at the Cunningham Gap site last month?"* - *"Were there any weather warnings active during the week of 10 March for postcode 4000?"* - *"What is the forecast for our Morningside site this week?"* - *"How many wet-weather days did we have at Burringbar in Q1?"* On Connected tier, weather data can be correlated directly against site diary entries from Assignar - ask *"Which days did weather delays get recorded in site diaries and what were the BOM conditions?"* --- ## Security **Access type:** Read-only (public data) The Bureau of Meteorology provides publicly available weather data. No credentials are required or stored. No private or organisation-specific data is involved. --- ## Next steps - [MCP Server](/access/mcp-server) - connect Claude or ChatGPT to query BOM data directly - [Assignar](/connectors/operational/assignar) - correlate weather conditions against site diaries on Connected tier - [Sign up for Insights](https://demiton.io/insights?ref=docs-bom-footer) - overlay weather data against your uploaded project timelines - [Connect your operation](https://demiton.io/contact?ref=docs-bom-connected-footer) - live BOM correlation against Assignar site diaries on Connected tier --- ## [CONNECTOR] Open Data Catalog for Australian public data Description: Browse, pin and query curated Australian government datasets from CKAN, AusTender, ABR and BOM. No credentials required. URL: https://docs.demiton.io/connectors/intelligence/catalog/ The Open Data Catalog is the Demiton surface for browsing and pinning curated Australian government datasets. All connectors in the Public Data category - CKAN state portals, AusTender, ABR, and BOM - are managed centrally by the Demiton platform. No credentials or connector configuration required on your side. --- ## Four sources, one catalog | Source | What it holds | System types | |---|---|---| | **CKAN portals** | State and federal open data - infrastructure registers, project datasets, spatial data | `CKAN_AU` | | **AusTender** | Federal contract awards, tender notices, supplier data | `AUSTENDER` | | **ABR** | ABN/ACN lookup, GST status, business entity type | `ABR` | | **BOM** | Weather observations, forecasts, and warnings by location | `BOM_WEATHER` | Each source is a platform-owned connector. Demiton maintains the API registrations - your account inherits access automatically on signup. --- ## Connection setup No credentials or connector configuration are required. Every source in the catalog is platform-managed, so access is inherited on signup and there is nothing for a customer to set up. --- ## Browsing the catalog **For Insights+ customers:** public data is available through the MCP server immediately on signup. Query any of the four sources through Claude or ChatGPT with no setup step. **For platform administrators:** the catalog browser at `/hq-platform/catalog` shows all available CKAN packages across registered portals. From this surface you can: - Browse datasets by portal, organisation, or keyword - Pin frequently used packages to a named alias for easier workflow targeting - Track a package - making it available in Insights+ customer queries - Untrack packages to remove them from the queryable set The `/hq-platform/catalog` surface is only visible to users of the Demiton Platform organisation with the `platform:manage_workflows` permission. If you are a customer rather than a platform administrator, your access to curated datasets is through the MCP server and the Studio chat interface. --- ## Querying via MCP All public data sources are available through the standard MCP tools. Example queries: - *"Which civil contractors were awarded Cross River Rail packages?"* - AusTender - *"Is [Supplier ABN] GST-registered? What is their entity type?"* - ABR - *"What were the weather conditions at the Cunningham Gap site last month?"* - BOM - *"Search data.qld.gov.au for infrastructure project datasets in southeast Queensland."* - CKAN --- ## What changes between tiers | Tier | Public data access | |---|---| | Public | 10 ad-hoc searches per month, 3 saved watchlists | | Insights | Expanded query access + overlay against your uploaded contract data | | Connected | Full access + live correlation against your integrated operational data | --- ## Next steps - [AusTender](/connectors/intelligence/austender) - government procurement data - [ABR](/connectors/intelligence/abr) - business register lookups - [BOM Weather](/connectors/intelligence/bom-weather) - weather observations and forecasts - [Open Data (CKAN)](/connectors/intelligence/open-data) - state and federal government datasets - [MCP Server](/access/mcp-server) - connect Claude or ChatGPT to query the catalog --- ## [CONNECTOR] Australian Open Data connector for CKAN portals Description: CKAN open data connector for Australian federal and state government portals and their published datasets. No credentials. URL: https://docs.demiton.io/connectors/intelligence/open-data/ A single CKAN adapter covers all Australian government open data portals. Every portal shares the one system type, `CKAN_AU` - the portal is selected per connection rather than being registered as a separate system type. **Authentication:** None for public portals (API key optional for rate-limit increase) **System type:** `CKAN_AU` **API reference:** [CKAN API](https://docs.ckan.org/en/latest/api/) Try querying open government data on the free Public tier - see [Quickstart](/start-here/quickstart) - project datasets, infrastructure registers, and spatial data. When you're ready to combine open data with your own contracts, [sign up for Insights](https://demiton.io/insights?ref=docs-opendata). --- ## Supported portals | Portal | `portal` value | |---|---| | data.gov.au | `federal` | | data.qld.gov.au | `qld` | | data.nsw.gov.au | `nsw` | | discover.data.vic.gov.au | `vic` | | data.sa.gov.au | `sa` | | catalogue.data.wa.gov.au | `wa` | | Any other CKAN 3.x portal | `custom` (with a base URL) | --- ## Supported resources | Resource | FETCH | LOOKUP | |---|:---:|:---:| | `search_datasets` | ✓ | | | `get_dataset` | ✓ | ✓ | | `datastore_query` | ✓ | | | `list_organizations` | ✓ | | | `list_groups` | ✓ | | | Pinned datasets (dynamic) | ✓ | | Pinned datasets are aliases you can configure per portal - frequently used datasets appear as named resources for easier targeting in workflows. --- ## Integration model One adapter serves every CKAN 3.x portal. It calls the portal's Action API for dataset search, dataset retrieval, datastore queries, and organisation and group listings; pinned packages are addressed as named resources. --- ## Connection setup No credentials are required for the public portals listed above. An optional API key can be supplied per portal for a higher rate limit; it is not needed for normal use. --- ## Example queries via MCP Once connected through the MCP server, you can ask Claude: - *"Search data.qld.gov.au for infrastructure project datasets in southeast Queensland."* - *"What road construction datasets are available on data.gov.au?"* - *"Pull the latest construction industry employment data from the ABS dataset on data.gov.au."* - *"Find spatial datasets covering the Cunningham Highway corridor."* --- ## Security **Access type:** Read-only (public data) All CKAN portals expose publicly available government datasets. No private or organisation-specific data is involved. An API key is optional and only needed for higher rate limits on specific portals. --- ## Next steps - [MCP Server](/access/mcp-server) - connect Claude or ChatGPT to query government data portals directly - [AusTender](/connectors/intelligence/austender) - government procurement data - [ABR](/connectors/intelligence/abr) - business register lookups - [Sign up for Insights](https://demiton.io/insights?ref=docs-opendata-footer) - combine government datasets with your uploaded contract and estimating data --- ## [CONNECTOR] Government tender and pipeline sources Description: State and territory government tender and infrastructure pipeline sources that feed Demiton's public registers. No credentials. URL: https://docs.demiton.io/connectors/intelligence/tender-portals/ Beyond [AusTender](/connectors/intelligence/austender), Demiton reads the state, territory and national tender and infrastructure-pipeline sources that have no page of their own. Each source is its own system type and its own read-only adapter. All are public; no credentials are required. They land in two public registers: active tender opportunities in [platform_tender](/registers/platform_tender), and forward procurement pipelines in [platform_planning](/registers/platform_planning). **Authentication:** None - public portals and publications **System types:** `NSW_ETENDER` · `VIC_TENDERS` · `WA_TENDERS` · `SA_TENDERS` · `TAS_TENDERS` · `VENDOR_PANEL` · `TENDERLINK` · `WESTERN_POWER` · `QLD_FPP` · `NSW_INFRA_PIPELINE` · `ANZIP` · `AER_DETERMINATIONS` --- ## Tender sources | Portal | System type | What it reads | Register | |---|---|---|---| | NSW eTendering (`tenders.nsw.gov.au`) | `NSW_ETENDER` | Open tender notices, pre-procurement planning notices and standing offer notices, via the public NSW eTendering API | [platform_tender](/registers/platform_tender) · [platform_planning](/registers/platform_planning) | | Buying for Victoria (`tenders.vic.gov.au`) | `VIC_TENDERS` | Active tender notices from the TenderSearch portal | [platform_tender](/registers/platform_tender) | | Tenders WA (`tenders.wa.gov.au`) | `WA_TENDERS` | Active tender notices from the WA Tenders application | [platform_tender](/registers/platform_tender) | | SA Tenders (`tenders.sa.gov.au`) | `SA_TENDERS` | Active tender notices from the TenderSearch portal | [platform_tender](/registers/platform_tender) | | Tasmanian Government Tenders (`tenders.tas.gov.au`) | `TAS_TENDERS` | Open-for-bids tender list | [platform_tender](/registers/platform_tender) | | VendorPanel | `VENDOR_PANEL` | Active opportunities from the public tender RSS feed; local government buyers by default, all buyers on request | [platform_tender](/registers/platform_tender) | | Tenderlink (`illion.tenderlink.com.au`) | `TENDERLINK` | Open civil engineering, electrical and cabling, and utilities tenders | [platform_tender](/registers/platform_tender) | | Western Power (`westernpower.com.au`) | `WESTERN_POWER` | Supplier tenders from the WA transmission and distribution network operator | [platform_tender](/registers/platform_tender) | ## Pipeline and planning sources | Source | System type | What it reads | Register | |---|---|---|---| | Queensland Forward Procurement Pipeline (`data.qld.gov.au`) | `QLD_FPP` | Queensland works-to-tender planning notices | [platform_planning](/registers/platform_planning) | | NSW Infrastructure Pipeline (`infrastructure.nsw.gov.au`) | `NSW_INFRA_PIPELINE` | The forward infrastructure programme across transport, health, education, social housing and justice | [platform_planning](/registers/platform_planning) | | ANZIP (`infrastructurepipeline.org`) | `ANZIP` | Energy infrastructure projects - wind, solar, battery storage, transmission and hydro | [platform_planning](/registers/platform_planning) | | AER Revenue Determinations (`aer.gov.au`) | `AER_DETERMINATIONS` | Five-year regulatory capex envelopes per distribution and transmission network | [platform_planning](/registers/platform_planning) | --- ## Integration model Each source on this page is a platform-owned, read-only adapter resolved by its own system type, and there are no tenant credentials to configure. The platform binds each adapter to `platform_tender` or `platform_planning` through `PlatformShelfBinding` (`packages/api/app/shelves/models.py`), which pairs the system type and register with the resource that adapter serves. --- ## How the sources differ **NSW eTendering** is the only source here that fills both registers: it serves tender, planning and standing-offer resources from the same public API. The adapter notes the portal is IP-rate-limited and should be harvested on a daily cadence. **VIC and SA** run the TenderSearch platform; **WA** runs its own Tenders application. **TAS** is an ASP.NET open-for-bids list. **Western Power** and **ANZIP** are read from their published pages, and Tenderlink is read through its embedded search API across three target categories. **SA Tenders is blocked at source.** Since 2026-09-01 the SA open-tender search redirects an anonymous client to a login wall, so the adapter fails loudly on every run. That is a registration decision rather than a parser bug; until access is arranged, SA contributes no records. **AER determinations are a seed registry, not a scrape.** Regulatory determinations change once per five-year period, so the adapter carries a hard-coded registry rather than reading aer.gov.au live. Awarded contracts are out of scope here. For NSW, awarded contracts come from the OpenContractsAU NSW source rather than this adapter, keeping the awarded-contract and active-tender data types separate. --- ## Connection setup No credentials are required or stored for any source on this page. Each connector is platform-managed and enabled centrally, so there is nothing for a customer to configure. --- ## Security **Access type:** Read-only (public data) Every source on this page is publicly accessible. No credentials are required or stored. Tender and planning facts are gated in Demiton and filtered from the unauthenticated public market endpoint at read time. --- ## Next steps - [AusTender](/connectors/intelligence/austender) - federal tender notices and contract awards - [Open Data (CKAN)](/connectors/intelligence/open-data) - the underlying datasets for several of these sources - [platform_tender register](/registers/platform_tender) - the published contract for active tenders - [MCP Server](/access/mcp-server) - query tender and pipeline data through Claude --- ## [CONNECTOR] Assignar connector for civil contractors Description: Assignar field execution connector for site diaries, labour, allocations, workforce records, plant and dynamic forms across projects. URL: https://docs.demiton.io/connectors/operational/assignar/ Assignar is a field execution platform for civil contractors. It records site diaries, labour entries, equipment usage, safety inspections, allocations, and custom form submissions. Demiton integrates with Assignar to retrieve operational data, align it with financial systems, and write allocations back when scheduling workflows are active. **Authentication:** OAuth 2.0 (client credentials) **System type:** `ASSIGNAR` **API reference:** [Assignar API](https://support.assignar.com/portal/en/kb/articles/api-overview) See your Assignar data in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-assignar). --- ## Supported resources | Resource | FETCH | PUSH | |---|:---:|:---:| | `projects` | ✓ | | | `workers` | ✓ | ✓ | | `assets` | ✓ | | | `clients` | ✓ | | | `suppliers` | ✓ | | | `activities` | ✓ | | | `allocations` | ✓ | ✓ | | `dockets` | ✓ | | | `timesheets-expanded` | ✓ | | | `leave-requests` | ✓ | | | `pay-codes` | ✓ | | | `competencies` | ✓ | | | `skills` | ✓ | | | `workers_with_competencies` | ✓ | | | `workers_with_inductions` | ✓ | | | `workers_with_skills` | ✓ | | | `project_inductions` | ✓ | | | Dynamic forms (`form_N_*`) | ✓ | | Dynamic forms are discovered at runtime - each form configured in your Assignar account becomes a fetchable resource. Forms include site diaries, daily pre-starts, safety observations, incident reports, and any custom forms your organisation has created. --- ## Integration model Authentication uses OAuth 2.0 client credentials. Records are normalised into the platform's standard response wrapper before entering the workflow runtime. The adapter supports a range of enrichment resources (`workers_with_competencies`, `workers_with_inductions`, `workers_with_skills`, `project_inductions`) that join Assignar data server-side to produce pre-joined datasets. For large datasets, the adapter uses progress callbacks and fan-out batch operations. Dynamic value resolution is supported - parameters like `NOW_MINUS_30_DAYS` are resolved at execution time, so workflow templates can reference relative time windows without hardcoded dates. ### Forms Target any Assignar form by its form ID: ``` FETCH → assignar.form_37 params: form_id: 37 ``` An all-forms sweep fetches submissions across every form in your account, useful for building a unified document index. ### Labour extraction Labour entries appear within site diary records. A transform step extracts them as structured records: ``` FETCH → assignar.timesheets-expanded TRANSFORM → extract_labour_entries ``` Each `LabourEntry` includes: worker, project, date, hours, cost category. --- ## Typical pipeline ``` FETCH → assignar.site_diary TRANSFORM → extract_labour_entries TRANSFORM → normalize_cost_categories LOGIC_GATE → validate_project_mapping PUSH → business_central.profit_and_loss ``` --- ## Connection setup Assignar uses OAuth 2.0 client credentials - no redirect is needed. Provide the **Client ID** and **Client Secret** for the API user that acts for Demiton. Use a dedicated API user to simplify credential rotation and audit. --- ## Security **Access type:** Read and approved write (allocations and worker records) Demiton reads the full range of operational data from Assignar. Writes are scoped to two resources: `allocations` (scheduling workflows) and `workers` (workforce lifecycle workflows). Demiton does not modify project definitions, form configurations, safety records, or any other Assignar data. **Permissions required:** OAuth 2.0 client credentials with access to your Assignar organisation. Use a dedicated API user for Demiton to simplify credential rotation and audit. **Data sensitivity:** Assignar data is classified as operational domain - broadly visible within your operational team, but subject to Demiton's identity-bound access controls. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Business Central](/connectors/erp/business-central) - the typical partner integration: Assignar labour entries cross-posted to BC project ledger - [Employment Hero Payroll](/connectors/finance/keypay) - reconcile Assignar allocations against payroll records - [MCP Server](/access/mcp-server) - query site diaries, workforce, and allocations through Claude once connected - [Connect your operation](https://demiton.io/contact?ref=docs-assignar) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Hilti ON!Track connector for tool tracking Description: Hilti ON!Track connector for reading tool, equipment, location, worker, quantity and transfer records from the asset platform. URL: https://docs.demiton.io/connectors/operational/hilti-ontrack/ Hilti ON!Track is Hilti's asset management platform for tracking tools and equipment across construction sites. Demiton reads asset, location, worker, and transfer data from ON!Track for use in operational and allocation workflows. **Authentication:** Resource Owner Password Credentials (ROPC) - client ID, secret, username, password **System type:** `HILTI_ONTRACK` **API reference:** [Hilti Developer Portal](https://developer.hilti.com/) See your Hilti ON!Track data in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-hilti-ontrack). --- ## Supported resources | Resource | FETCH | |---|:---:| | `assets` | ✓ | | `locations` | ✓ | | `workers` | ✓ | | `transfers` | ✓ | | `quantity-items` | ✓ | This connector is read-only - Demiton does not write back to ON!Track. --- ## Integration model Uses ROPC authentication (username and password alongside client credentials). The adapter handles page/offset translation automatically - you can use standard pagination parameters and the adapter converts them to ON!Track's offset/limit format. --- ## Connection setup Required values: - **Client ID** - your ON!Track API client ID - **Client Secret** - your ON!Track API client secret - **Username** - ON!Track account username - **Password** - ON!Track account password --- ## Security **Access type:** Read-only Demiton retrieves asset, location, worker, and transfer records from ON!Track. No data is written back. **Permissions required:** ON!Track account credentials with read access to asset tracking data. Create a dedicated service account for Demiton. **Data sensitivity:** Equipment tracking data is classified as operational domain. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Assignar](/connectors/operational/assignar) - the field execution connector for site diaries and allocations - [MCP Server](/access/mcp-server) - query asset tracking and equipment data through Claude once connected - [Connect your operation](https://demiton.io/contact?ref=docs-hilti-ontrack) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Navman connector for fleet telematics Description: Navman TN360 fleet connector for vehicles, meters, GPS, driver, speeding and driving-behaviour event reads. Read-only telematics. URL: https://docs.demiton.io/connectors/operational/navman/ The Navman connector reads fleet telematics from Navman TN360: the vehicle list, the driver directory, odometer/fuel/engine-hours meter snapshots, and time-windowed ignition, driver, speeding and engine-management events. It is read-only - Demiton does not write back to Navman. **Authentication:** Integration API key sent as a static Bearer token (no OAuth exchange) **System type:** `NAVMAN` **Protocol:** TN360 REST v1 See your Navman fleet data in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-navman). --- ## Supported resources | Resource | FETCH | |---|:---:| | `vehicles` | ✓ | | `users` | ✓ | | `vehicle_meters` | ✓ | | `ignition_events` | ✓ | | `driver_events` | ✓ | | `speed_events` | ✓ | | `engine_management_events` | ✓ | `users` is the TN360 driver/operator directory - id, name, email, mobile, status, type and rulesets. It accepts a `drivers_only` filter that keeps only users with a fatigue ruleset membership, the population driver events fire for. `vehicle_meters` is a current odometer, fuel and engine-hours snapshot per vehicle. The four event resources require `from_date` and `to_date`. Dates are `YYYY-MM-DD` or DSL tokens (`TODAY`, `NOW_MINUS_14_DAYS`, `NOW_MINUS_DAYS:N`). Spans longer than seven days are chunked automatically. `engine_management_events` is filtered to harsh braking (HB) and harsh acceleration (EA) only; idle-time actions from the same TN360 endpoint are excluded. This connector is read-only - no resource supports PUSH. --- ## Integration model The API key is injected into every request header as a Bearer token; there is no token exchange or refresh. Date tokens in query parameters are resolved to concrete dates at execution time. Requests time out after 90 seconds and retry twice on timeout only, so a call can make up to three attempts. TN360 is inconsistent about returning some numeric attributes as JSON numbers or strings on the same field; the adapter coerces them at its boundary so downstream measures receive numbers. --- ## Connection setup Required values: - **API Key** - the Navman TN360 Integration API key Optional: - **Base URL** - override the default `https://api-au.telematics.com/v1` to target a non-AU region or a test environment --- ## Security **Access type:** Read-only Demiton reads vehicles, the driver directory, meter snapshots and event records from Navman TN360. No data is written back. **Permissions required:** A TN360 Integration API key with read access to the fleet. Use a dedicated integration key for Demiton. **Data sensitivity:** Fleet and driver telematics is classified as operational domain and is subject to Demiton's identity-bound access controls. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Hilti ON!Track](/connectors/operational/hilti-ontrack) - tool and equipment tracking - [Trimble](/connectors/operational/trimble) - equipment, assignment and timesheet reads - [Connect your operation](https://demiton.io/contact?ref=docs-navman) - talk to us about scoping a Connected deployment --- ## [CONNECTOR] Trimble connector for equipment and timesheets Description: Trimble construction connector for reading equipment, assignments, timesheets and project records. This connector is read-only. URL: https://docs.demiton.io/connectors/operational/trimble/ Trimble construction management connector for reading equipment, assignment, timesheet, and project data. **Authentication:** OAuth 2.0 (client credentials) **System type:** `TRIMBLE` **API reference:** [Trimble Developer Portal](https://developer.trimble.com/) See your Trimble data in Claude — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-trimble). --- ## Supported resources | Resource | FETCH | |---|:---:| | `equipment` | ✓ | | `assignments` | ✓ | | `timesheet` | ✓ | | `projects` | ✓ | This connector is read-only. It is in Beta - resource discovery is functional but the connector does not yet implement the full Demiton adapter interface. --- ## Integration model The adapter exchanges client credentials for a token at Trimble's identity service, then calls the Trimble Construction Cloud REST API. Each supported resource maps to one API path: `equipment`, `assignments` (`/equipment/assignments`), `timesheet` (`/equipment/timesheets`) and `projects`. The connector is read-only - no resource has a write path. --- ## Connection setup Required values: - **Client ID** - **Client Secret** - **Tenant ID** - **Base URL** - your Trimble environment URL --- ## Security **Access type:** Read-only Demiton reads equipment, assignment, timesheet, and project data from Trimble. No data is written back. **Permissions required:** OAuth 2.0 credentials with read access to the Trimble data entities your workflows use. **Data sensitivity:** Trimble project and equipment data is classified as operational domain. --- ## Next steps - [Connecting a System](/getting-started/connecting-a-system) - step-by-step wizard for setting up the connector - [Assignar](/connectors/operational/assignar) - the field execution connector for site diaries and allocations - [MCP Server](/access/mcp-server) - query Trimble project and equipment data through Claude once connected - [Connect your operation](https://demiton.io/contact?ref=docs-trimble) - talk to us about scoping a Connected deployment --- ## [TECHNICAL_REFERENCE] Connectors Overview Description: Demiton connectors across ERP, operational, finance, identity, data sources, communications, AI, intelligence, and platform categories. URL: https://docs.demiton.io/connectors/overview/ Connectors are the integration layer between Demiton workflows and external systems. Each adapter exposes resources that workflows can **FETCH** from, **PUSH** to, **LOOKUP** against, or **EXECUTE** operations on. Connectors are how data gets into [Civil Memory](/start-here/civil-memory). Demiton reads from your systems - it does not replace them - and projects what it reads into the sourced record that [Studio](/surfaces/studio) and [Ask Demiton](/surfaces/ask-demiton) answer from. The more you connect, the more complete the memory becomes. Connectors split into two categories based on how they're accessed and which tier they're available on: - **Public data connectors** - read-only access to Australian government APIs (AusTender, ABR, BOM, CKAN). No credentials required. Available on every tier - Public tier users have monthly query quotas; Insights tier and above have expanded access. - **Private system connectors** - require credentials and configuration against your own systems (Business Central, Assignar, Employment Hero Payroll, SharePoint, and others). Available on the **Connected** tier. --- ## Public data connectors (all tiers) No credentials required - these adapters call public Australian government APIs directly. Available on every tier. Public tier includes 10 ad-hoc searches and 3 saved watchlists per month; [Insights tier](https://demiton.io/insights?ref=docs-connectors-overview) provides expanded query access alongside your uploaded contract data. --- ## Private system connectors (Connected) Require credentials and a one-off configuration step. These connect to your operational and financial systems. --- ## All connectors | Connector | Category | Tier | System type | Auth | |---|---|---|---|---| | [AusTender](/connectors/intelligence/austender) | Public Data | All tiers | `AUSTENDER` | Platform-managed | | [ABR](/connectors/intelligence/abr) | Public Data | All tiers | `ABR` | Platform-managed | | [BOM Weather](/connectors/intelligence/bom-weather) | Public Data | All tiers | `BOM_WEATHER` | Platform-managed | | [Open Data (CKAN)](/connectors/intelligence/open-data) | Public Data | All tiers | `CKAN_AU` | Platform-managed | | [Open Data Catalog](/connectors/intelligence/catalog) | Public Data | All tiers | `CKAN_AU` · `AUSTENDER` · `ABR` · `BOM_WEATHER` | Platform-managed | | [Government tender and pipeline sources](/connectors/intelligence/tender-portals) | Public Data | All tiers | `NSW_ETENDER` · `VIC_TENDERS` · `WA_TENDERS` · `SA_TENDERS` · `TAS_TENDERS` · `VENDOR_PANEL` · `TENDERLINK` · `WESTERN_POWER` · `QLD_FPP` · `NSW_INFRA_PIPELINE` · `ANZIP` · `AER_DETERMINATIONS` | Platform-managed | | [Business Central](/connectors/erp/business-central) | ERP | Connected | `D365_BUSINESS_CENTRAL` | OData / OAuth 2.0 | | [Finance & Operations](/connectors/erp/finops) | ERP | Connected | `D365_FINOPS` | OAuth 2.0 | | [Assignar](/connectors/operational/assignar) | Operational | Connected | `ASSIGNAR` | OAuth 2.0 | | [Hilti ON!Track](/connectors/operational/hilti-ontrack) | Operational | Connected | `HILTI_ONTRACK` | ROPC | | [Navman](/connectors/operational/navman) | Operational | Connected | `NAVMAN` | API key | | [Trimble](/connectors/operational/trimble) | Operational | Connected | `TRIMBLE` | OAuth 2.0 | | monday.com | Operational | Connected | `MONDAY` | API token | | [Employment Hero Payroll](/connectors/finance/keypay) | Finance & Payroll | Connected | `KEYPAY` | API key | | [Xero](/connectors/finance/xero) | Finance & Payroll | Connected | `XERO` | OAuth 2.0 (auth code) | | [Universal Banking](/connectors/finance/banking) | Finance & Payroll | Connected | `BANKING_GENERIC` | SFTP + PGP | | [SharePoint](/connectors/datasource/sharepoint) | Data Sources | Connected | `SHAREPOINT` | OAuth 2.0 | | [Dropbox](/connectors/datasource/dropbox) | Data Sources | Connected | `DROPBOX` | OAuth 2.0 | | [SQL](/connectors/datasource/sql) | Data Sources | Connected | `SQL` | Connection string | | [SFTP](/connectors/datasource/sftp) | Data Sources | Connected | `SFTP` | Host / credentials | | [Excel](/connectors/datasource/excel) | Data Sources | Connected | `M365_EXCEL` | File upload | | [Dataverse](/connectors/datasource/dataverse) | Data Sources | Connected | `DATAVERSE` | OAuth 2.0 | | [Microsoft Teams](/connectors/comms/teams) | Communications | Connected | `MS_TEAMS` | Webhook / OAuth 2.0 | | Microsoft 365 mail | Communications | Connected | `GRAPH_MAIL` | OAuth 2.0 via Entra ID | | [SMTP](/connectors/comms/smtp) | Communications | Connected | `SMTP` | Host / credentials | | [SendGrid](/connectors/comms/sendgrid) | Communications | Connected | `SENDGRID` | API key | | [Discord](/connectors/comms/discord) | Communications | Connected | `DISCORD` | Webhook + bot token | | [Entra ID](/connectors/identity/entra-id) | Identity | Connected | `ENTRA_ID` | OAuth 2.0 | | HubSpot | CRM | Connected | `HUBSPOT` | Bearer token | | [Azure AI Foundry](/connectors/cognitive/azure-ai-foundry) | AI & Cognitive | Connected | `AZURE_FOUNDRY` | Platform-managed | | [Claude Enterprise](/connectors/platform/claude-enterprise) | AI & Cognitive | Connected | `CLAUDE_ENTERPRISE` | Admin API key | | [Azure Maps](/connectors/platform/azure-maps) | Platform | Connected | `AZURE_MAPS` | Platform-managed | | [Platform Storage](/connectors/platform/storage) | Platform | Connected | `DEMITON_STORAGE` | Platform-managed | --- ## How connectors work **Verb model** - every resource supports a subset of standard verbs: | Verb | What it does | |---|---| | `FETCH` | Retrieve a dataset - paginated, filterable | | `PUSH` | Write or update records | | `LOOKUP` | Point lookup by key - returns a single record | | `EXECUTE` | Trigger an operation (send, delete, create index, etc.) | **Register bindings** - a connector is bound to the registers it serves, each binding pairing a register with the adapter resource and any routing hints needed to fetch it. Postgres owns that binding data, not the adapter code. A workflow targeting a register the connector is not bound to fails at pre-flight, not mid-run. **Simulation mode** - every write adapter supports dry-run mode. Simulation runs log what would happen without touching the external system. To connect your first system, see [Connecting a System](/getting-started/connecting-a-system). If you're on Insights, see [Uploading Your Data](/getting-started/uploading-your-data) instead. --- ## [CONNECTOR] Azure Maps connector for geocoding Description: Azure Maps connector for geocoding addresses, reverse geocoding coordinates and location-aware lookups. Platform-managed. URL: https://docs.demiton.io/connectors/platform/azure-maps/ Azure Maps connector for geospatial operations - geocoding addresses to coordinates, reverse geocoding coordinates to addresses, and location-aware workflow steps. **Authentication:** Platform-managed **System type:** `AZURE_MAPS` **API reference:** [Azure Maps REST API](https://learn.microsoft.com/en-us/rest/api/maps/) Add geocoding to your Demiton workflows — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-azure-maps). --- ## Supported resources | Resource | FETCH | |---|:---:| | `geocode` | ✓ | | `reverse_geocode` | ✓ | Both resources support batch operations. A country parameter is available to constrain geocoding results. --- ## Integration model This connector is platform-managed - no tenant credentials are required. The adapter uses the platform's Azure Maps service instance. It operates in two modes: live (real Azure Maps calls) and fixture (for testing, returns deterministic results without making API calls). --- ## Connection setup No tenant credentials are required or accepted. The adapter uses the platform's Azure Maps service instance; access is enabled on your behalf, so contact your Customer Success Manager to turn the connector on. --- ## Security **Access type:** Platform-managed - read-only (lookups) Demiton sends address or coordinate data to Azure Maps for geocoding. No data is stored by Azure Maps beyond the API request lifetime. Contact your Customer Success Manager to enable this connector. --- ## Next steps - [MCP Server](/access/mcp-server) - geolocation powers `query_workers_near_postcode` and similar spatial MCP tools - [Connect your operation](https://demiton.io/contact?ref=docs-azure-maps) - Azure Maps is platform-managed as part of your Connected deployment --- ## [CONNECTOR] Claude Enterprise connector for org admin Description: Anthropic Claude Enterprise connector for org users, invitations, API key enumeration and compliance data. Read-only admin access. URL: https://docs.demiton.io/connectors/platform/claude-enterprise/ The Claude Enterprise adapter connects Demiton to Anthropic's Admin API and Compliance API, allowing workflows to enumerate organisation members, manage invitations, audit API key usage, and ingest conversation transcripts for the memory framework. **Authentication:** Anthropic admin API key **System type:** `CLAUDE_ENTERPRISE` **API reference:** [Anthropic API](https://docs.anthropic.com/en/api/getting-started) Manage your Claude Enterprise organisation through Demiton — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-claude-enterprise). --- ## Supported resources ### Admin API | Resource | FETCH | LOOKUP | |---|:---:|:---:| | `users` | ✓ | ✓ | | `invites` | ✓ | | | `api_keys` | ✓ | | ### Compliance API | Resource | FETCH | |---|:---:| | `conversations` | ✓ | | `activity_events` | ✓ | The Compliance API resources are not yet implemented in the adapter - FETCH calls to `conversations` or `activity_events` raise rather than returning data, with or without a compliance key. --- ## Integration model The adapter talks to two Anthropic APIs through separate clients: the Admin API for `users`, `invites` and `api_keys`, and a Compliance API client for `conversations` and `activity_events`. The Admin API is live; the Compliance API is stubbed until its specification is available, so those two resources cannot yet return records. `organization_id` is stored for reference only and is not sent to Anthropic. --- ## Connection setup | Credential | Required | Description | |---|:---:|---| | `admin_api_key` | Yes | `sk-ant-admin...` key from the Claude console | | `compliance_api_key` | No | Required to activate Compliance API resources | | `organization_id` | No | Stored for reference; not sent to Anthropic | --- ## Security **Access type:** Read-only (Admin API - user and key enumeration); Compliance API - conversation ingestion The Admin API exposes organisation-level management data: user accounts, pending invitations, and API key metadata. This data is scoped to your Anthropic organisation. The Compliance API (when enabled) ingests conversation transcripts for the Demiton memory framework. No conversation data is written back to Anthropic - it flows inbound only. Your `admin_api_key` is stored encrypted in Demiton's credential store and used only at workflow execution time. --- ## Next steps - [MCP Server](/access/mcp-server) - Claude Enterprise is the AI backbone behind MCP queries - [Security Overview](/security) - identity-bound execution model governing all MCP tool calls - [Connect your operation](https://demiton.io/contact?ref=docs-claude-enterprise) - Claude Enterprise is platform-managed; contact us to enable or modify it --- ## [CONNECTOR] Demiton Storage connector for workflow artifacts Description: Demiton Storage connector for writing workflow artifacts such as PDFs, reports, datasets and payment files. Write-only storage. URL: https://docs.demiton.io/connectors/platform/storage/ The Demiton Storage adapter writes pipeline-generated artifacts - PDFs, reports, exported datasets, payment files - to Demiton's Azure Blob Storage. It is provisioned automatically for every organisation; no connection setup is required. **Authentication:** Platform-managed (managed identity) **System type:** `DEMITON_STORAGE` Store your workflow artefacts in Demiton — [book a 30-minute call](https://demiton.io/contact?ref=docs-connector-storage). --- ## Supported resources | Resource | PUSH | |---|:---:| | `artifacts` | ✓ | `artifacts` is the only resource. Each workflow run that produces file output pushes records here; the adapter detects binary content by finding keys ending in `_base64`, decodes them, and uploads each file individually. --- ## Integration model This connector is platform-managed - no tenant credentials are required or accepted. The adapter uses Demiton's Azure Storage account via the `blob_service` singleton, which authenticates with managed identity. Blob paths are organisation-scoped: ``` org_{org_id}/artifacts/{resource}/{uuid}_{filename} ``` UUID prefixes prevent filename collisions across concurrent runs. If no filename is provided in the record, a random `.bin` name is generated. A SHA-256 hash is computed over the raw bytes before upload and returned in the response manifest, allowing downstream steps to verify artifact integrity. Simulation mode is supported - dry-run calls return a manifest describing what would be uploaded without touching storage. --- ## Connection setup No connection setup is required. Demiton Storage is provisioned automatically for every organisation, and the adapter authenticates with Demiton's managed identity. --- ## Security **Access type:** Platform-managed - write-only (artifact storage) Artifacts are stored in Demiton's Azure Blob Storage, encrypted at rest with AES-256. Access is scoped by organisation - one customer's stored data is never accessible to another. No external system credentials are involved. The platform's managed identity governs all storage operations. --- ## Next steps - [MCP Server](/access/mcp-server) - platform storage is used for workflow artefact handling - [SharePoint](/connectors/datasource/sharepoint) - primary document store for customer-controlled files - [Connect your operation](https://demiton.io/contact?ref=docs-storage) - platform storage is included in your Connected deployment --- ## [DOCUMENTATION] Page not found Description: That page does not exist or has moved. Start from the documentation home, the register contracts, or the connector reference. URL: https://docs.demiton.io/404/ --- ## [GLOSSARY] What do these construction and Civil Memory terms mean? Description: Plain-language definitions of the construction, procurement and Demiton terms used across these docs, from register and ingest group to NPS and OC4IDS. URL: https://docs.demiton.io/glossary/ Construction has its own vocabulary, and Demiton adds a small one of its own. This page defines both in plain language, with a link to the page that explains each one in full. A word written with a capital - Register, Market, Memory, Projects - is the name of a thing in the Demiton app. The same word in lower case is the everyday construction meaning. --- ## The memory model | Term | What it means | |---|---| | **Civil Memory** | The one continuous, sourced record of a civil job that every register, connector and surface feeds or reads from - from the public market through the award into your delivery. Demiton is built on it, but it isn't a thing you buy on its own. See [How your registers become one record](/start-here/civil-memory). | | **Register** | One kind of record, kept current in one agreed format, however many systems produced it - site diaries, timesheets, budget lines. It is the same idea as the plant register or drawing register you already keep. See [What a register is](/concepts/registers). | | **Register contract** | The published JSON Schema behind a register: the fields a record carries, which are required, their units, and an example. Every published contract is listed in the [register contract reference](/registers), which carries the live count. | | **Ingest group** | The pipe that writes records into a register - a connector, a harvester, or a computed reconciliation. It carries the routing, entitlement and provenance for everything it writes. See [Ingest groups](/concepts/ingest-groups). | | **Shelf** | The API and MCP name for a register. The `shelf` parameter on Ask Demiton takes a register ID such as `site_diary`. The word differs; the thing is the same. See [Registers](/concepts/registers). | | **Provenance** | Where a record came from: which system, which connector, and which run wrote it. Provenance is stamped on every record, so an answer can always be traced back to its source. See [Ingest groups](/concepts/ingest-groups). | | **Entity** | The canonical thing a record is about - a worker, a project, an asset, an organisation. Records attach to entities rather than to system-specific IDs, so memory survives a system migration. See [Memory](/memory/overview). | ## The public market and delivery | Term | What it means | |---|---| | **OCDS** | The Open Contracting Data Standard: the open schema Australian governments publish planning notices, tenders and awards under. It shapes the pre-award half of Civil Memory. See [OCDS](/standards/ocds). | | **OCID** | The Open Contracting Identifier: the globally unique ID an OCDS release gives one contracting process. It is how Demiton follows a single job from planning notice through tender to award without confusing it with a similarly named package. | | **OC4IDS** | The Open Contracting for Infrastructure Data Standard: the delivery record for work you have won and are delivering. It is produced only through a contractor-initiated, consented, audited emission - never by default. See [OC4IDS](/standards/oc4ids). | | **Award seam** | The point where a public tender becomes your private delivery project. Public market data (OCDS) hands off to your operational record when a pursuit is linked to the contract that was won. | | **Per-project P&L** | Profit and loss for one job: budget, actual cost, commitments, contract value and gross margin, drawn from your ERP and refreshed nightly. The register is `profit_and_loss`. See [Registers](/registers/profit_and_loss). | | **SoR / schedule of rates** | A client's priced list of work items - the rates a contract is measured and paid against. In Demiton, a schedule of rates can be checked against tender drawings by independent measurement; see `sor_verification` in the [register catalog](/concepts/register-catalog). | ## Prequalification, compliance and commercial | Term | What it means | |---|---| | **Prequalification** | A client's or road authority's process for deciding in advance which contractors may bid for which work and at what value. It is the eligibility lens that sits before the market, and the standing it declares is what Protection's lapsed compliance disease watches. The stand-alone Prequalification surface was retired in September 2026. | | **NPS** | The Austroads National Prequalification System, used across Australian road authorities to classify contractors. Your NPS standing is recorded as classifications and expiry dates against your schemes. | | **R / B / F / A** | The four NPS classification families: R for road construction, B for bridge, F for financial capacity, and A for asphalt. Levels sit inside each family - R1 to R5, B1 to B4, and A1 to A4 - while the financial level is stated as a value such as F25. | | **Retention** | Money a client withholds from progress payments as security for defects, released under the contract. The `retention_position` register holds what is currently withheld on a job. See the [register catalog](/concepts/register-catalog). | | **Security of payment** | The legislation that gives a contractor a right to a payment schedule and adjudication when a claim is not paid on time. The `payment_schedule` register is defined for it; see the [register catalog](/concepts/register-catalog). | ## Obligations and protections | Term | What it means | |---|---| | **Obligation** | One duty a published document places on you for a job, with its clause, its window and what happens if you miss it. Section 76 of Queensland's BIF Act, a payment schedule within 15 business days of a claim, is one. See [Obligations](/concepts/obligations). | | **Source** | One of the seven places a job's duties come from: contract, law, principal, approvals, counterparties, workforce, and your own commitments. A standard such as AS or ISO is not a source; it enters through the contract or principal that calls it up. See [Obligations](/concepts/obligations#the-seven-sources). | | **Instrument** | One published document inside a source: an Act, a regulation, a contract form, a principal's specification, a permit. The Building Industry Fairness (Security of Payment) Act 2017 (Qld) is one instrument. | | **Obligation library** | The public set of instruments and their obligations that Demiton reads, one file per instrument, each obligation cited to its clause. It lives in the [demitonapp/registers](https://github.com/demitonapp/registers) repository, and anyone can propose an addition. It is not complete, and Demiton never says it is. | | **Protection** | One obligation switched on for one of your jobs. It runs every day from the day it is switched on. | | **Protection type** | How a protection runs, one of four: **watch** (a window opens when something happens and its deadline is tracked), **countdown** (a fixed date, flagged at 90, 30 and 7 days), **check** (evidence that must exist is looked for on a cadence), **threshold** (a measure is tracked against the line it must not cross). | | **Disease** | Which of the five a protection guards against: rework, missed claims, disputes, cost drift or lapsed compliance. It is set on the obligation, separately from the protection type. See [The five diseases](/start-here/diseases). | | **Ready state** | Whether a protection can run today. When it cannot, the register it reads is empty, and it names the kind of system that would fill it ("your finance system") before any vendor. | ## How Demiton behaves | Term | What it means | |---|---| | **MCP** | The Model Context Protocol: the open protocol that lets Claude, ChatGPT or an IDE call Demiton's tools. A connection lists four tools - `ask_demiton`, `tell_demiton`, `instruct_demiton` and `switch_org`. See [MCP tools](/access/mcp-tools). | | **Simulation mode** | A dry run for any write. The workflow evaluates and logs exactly what it would write, and to which system, without changing anything. See [Security and governance](/security). | | **Register status: Available** | The register is filled today from connected systems, uploads, or Demiton's own public data. | | **Register status: Declared** | The register and its contract exist, and it fills as soon as a source or feature produces its first record. A Declared register can legitimately be empty. | | **Register status: Planned** | The register is defined as a contract, ahead of the connector that will fill it. | --- ## Next steps - [Register catalog](/concepts/register-catalog) - every register, grouped by domain - [Register contracts](/registers) - fields, requiredness and an example record for each register - [Obligations](/concepts/obligations) - where a job's duties come from and how each becomes a protection - [What is Demiton](/overview/platform) - the product and the tier model

Still unsure what a term means, or want it defined for your own systems?{' '} Ask us.

--- ## [ROADMAP] Roadmap Description: What Demiton is building next, in priority order - platform stability, durable agent runs, and more construction systems connected. URL: https://docs.demiton.io/roadmap/ Demiton's public roadmap — a living record of what we're building and the order we're building it in, kept in the open so you can see where the product is heading. A roadmap is direction, not a promise. Priorities change as we learn — items can move between buckets, and nothing here commits to a specific date. ## How to read it Items sit in four buckets, in priority order: - **Now** — actively being built this cycle. - **Next** — up next, once what's in Now ships. - **Later** — committed direction, not yet scheduled. - **Someday** — ideas we want to explore; no commitment. --- ## Now Hardening the platform for multi-tenant scale — reliability under load, faster pages, and clear operational signals when something goes wrong, so every organisation added runs on the same dependable base. --- ## Next Letting new capabilities be added to Studio without rebuilding the surface. Today a new panel or tool means a release; the direction is a runtime where a capability can be registered, discovered and turned on per organisation — so what you need appears without waiting on a version upgrade. Rebuilding our [agent and ML workflows](https://temporal.io) on Temporal for durable, long-running execution — so a run survives restarts, resumes after failure, and every step stays observable. Investigating the [Agent Client Protocol (ACP)](https://agentclientprotocol.com) — the open standard for connecting AI clients to agents — as a complement to our [MCP server](/access/mcp-server): a step toward letting any ACP-capable client drive Demiton's agents. --- ## Later Answers that are more than text: charts, forms, calculators and small dashboards rendered inside a reply, with the values you enter flowing back into the conversation. The goal is for a rate comparison to arrive as something you can adjust, not a paragraph you have to re-ask. Native drawing review inside Studio — open a civil drawing, measure against it, and ask questions about geometry and dimensions without leaving the conversation or exporting to a separate tool. Connecting the systems civil contractors run beyond today's [connectors](/connectors/overview): Procore, Oracle Aconex, Sitemate, Payapps, HammerTech, SignOnSite, Mitti, MapTrack, Geotab, EROAD, MYOB Business, MYOB Acumatica, Xero Accounting and Xero Payroll AU. Each is built on one declarative connector pack, so a system's authentication, paging, rate limits and usage terms are declared rather than hand-coded, and each fills the registers in the [register catalog](/concepts/register-catalog). Where a vendor's API cannot supply a record, Demiton says so instead of quietly returning nothing. --- ## Someday Nothing here yet. This is where ideas live before we commit to them — a record of where we might head, with no commitment made. --- Questions or feedback? [Talk to us](https://demiton.io/contact). --- ## [POLICY_REFERENCE] Security Overview Description: How Demiton enforces identity-bound access - the governing principle, data domains, credential handling, and audit trail. URL: https://docs.demiton.io/security/ Demiton is built on a single governing principle: **your connected systems define access; Demiton enforces it.** Every operation is identity-bound, every decision is auditable, and no action executes without a traceable identity. Evaluating Demiton for a security review? Request the Security Whitepaper. --- ## How does Demiton enforce identity-bound execution? Every operation in Demiton - AI queries, workflow runs, data retrievals, writes to connected systems - is attributed to the user or system identity that initiated it. If identity cannot be determined, execution stops. This means: - API requests are authenticated via your API key, which carries your organisation's identity context - MCP tool calls are bound to the user identity that established the session - Automated workflows record the identity that triggered them - human or system - No operation is anonymous --- ## How does Demiton determine what data a user can access? Demiton does not maintain its own role-to-data mapping. Access to data in your connected systems is derived from the authoritative systems you already use: | What you want access to | Authority | |---|---| | Financial data (budgets, actuals, ledger) | Your ERP (Business Central, Finance & Operations) | | Project allocation and operational scope | Your field management system (Assignar) | | Payroll records | Your payroll system (Employment Hero Payroll) | | Documents and files | Your document management system (SharePoint, Dropbox) | | Identity and organisational attributes | Microsoft Entra ID | When a user queries Demiton - through Studio, the MCP server, or a workflow - Demiton resolves that user's access against each relevant authority and filters results accordingly. A user who cannot see a project's financial data in Business Central will not see it in Demiton. ### Zero-trust default If access cannot be positively confirmed, access is denied. An unavailable system authority, a missing identity binding, or an unresolvable permission - all fail closed. Users see a clear error rather than partial or incorrect data. --- ## What are the three data domains? Demiton recognises three data domains, each with a distinct access profile: | Domain | What it covers | Default access | |---|---|---| | **Operations** | Site diaries, forms, allocations, schedules, equipment | Broad - visible within your functional team and region | | **Financials** | Project budgets, actuals, variance, purchase orders, progress claims | Project-scoped - derived from your allocation or ERP permission sets | | **Payroll** | Pay records, individual hours, cost rates, workforce costs | Restricted - payroll administrators, executives, and self-service for own data | Project Managers see aggregated labour costs for their projects (financials domain) but not individual pay rates or records. Payroll data is never surfaced to general users regardless of what question they ask. --- ## What does each connector read or write? Different connectors carry different access profiles. Some are read-only; others support approved writes. The access profile is documented in the Security section of each connector's reference page. As a rule: - **ERP connectors** (Business Central, Finance & Operations) support reads and approved writes - writes occur only through workflows with approval gates - **Field systems** (Hilti OnTrack, Trimble) are read-only - Demiton retrieves operational data but does not write back - **Assignar** supports approved writes for workforce lifecycle workflows (worker mirroring, allocation management) - all writes require explicit approval and occur through the Workflow Runtime - **Payroll connectors** (Employment Hero Payroll) support reads and approved writes - creating or updating employee records, timesheets, and leave requests - only through approval-gated workforce lifecycle workflows - **Communications connectors** (Teams, SendGrid, SMTP, Discord) are write-only - Demiton sends outbound messages but reads nothing - **Document stores** (SharePoint, Dropbox) are read-only except for SharePoint, which supports approved writes for document uploads and site and document-library provisioning - **Public data sources** (AusTender, ABR, BOM, CKAN) are read-only - no credentials required or stored - **Identity** (Entra ID) - Demiton reads identity attributes and group memberships, and supports approved writes for group membership (adding and removing members, creating security groups) and HR-owned profile fields (department, job title, city, employment type, employee ID, manager) as part of workforce lifecycle workflows --- ## How are credentials stored and protected? Credentials you provide when connecting a system are: - Encrypted at rest using AES-256 - Never logged in plaintext - Processed in memory only during connection setup and test - never written to disk as plaintext - Rotatable at any time from the Systems page without re-entering other configuration For API keys and client secrets specifically: if you suspect a credential has been compromised, rotate it in the source system and update the connector. Demiton immediately begins using the new credential. Treat your Demiton API key with the same care as any other credential. It carries your organisation's identity and access scope. Rotate it from HQ → API Keys if you believe it has been exposed. --- ## Simulation mode Every write-capable connector supports a simulation (dry-run) mode. When a workflow runs in simulation mode, every intended write is evaluated and logged - but nothing is committed to the connected system. The log shows exactly what would have been written, to what resource, and under what identity. Simulation mode is not on by default - it must be enabled for each run. Production execution requires an explicit confirmation step: a proposed write to a connected system is queued for admin approval at **HQ → Approvals** before anything is written. --- ## Audit trail Every access decision and every operation in Demiton is logged: - **What** was accessed or written - **Who** requested it (user identity, including Entra OID) - **When** it happened - **Why** access was granted or denied (the reasoning trail, not just the decision) - **What** the outcome was **Retention target: seven years**, aligned with Australian financial record-keeping requirements and the seven-year retention cycle used by Tier-1 head contractors for substantiation against subcontract and head-contract claims. This is a design target rather than an enforced purge: audit records are append-only and are not automatically deleted today, and no scheduled job trims the audit tables. Scheduled retention jobs do exist for other stores - for example, evaluation-harness chat rows are purged after 30 days. The dimension audit log is accessible from the **Audit → Dimensions** page (`/audit/dimensions`). --- ## Connector security reference Each connector's documentation includes a Security section covering the specific permissions Demiton requests, what it reads, and what (if anything) it writes. See the [Connectors](/connectors/erp/business-central) section for per-system detail. --- # Register contracts Demiton publishes 180 register contracts as JSON Schema (draft 2020-12). Each entry below gives the register ID you ask for, what it holds, and the fields it requires. ## allocation - Allocation Holds: Who and what is rostered on which job, and when. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: hours, project, external_id, occurred_at, financial_period Filled today by: Assignar Contract: https://docs.demiton.io/registers/allocation/ JSON Schema: https://docs.demiton.io/registers/allocation/v1.json ## asbestos_register - Asbestos register Holds: The asbestos register work health and safety regulations require. Status: Planned Domain: Safety Data: tenant Required fields: workplace Contract: https://docs.demiton.io/registers/asbestos_register/ JSON Schema: https://docs.demiton.io/registers/asbestos_register/v1.json ## asset_disposal - Asset disposal Holds: Plant and equipment written off, sold or scrapped. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: asset, external_id, occurred_at, disposed_item_description Filled today by: Assignar, Business Central Contract: https://docs.demiton.io/registers/asset_disposal/ JSON Schema: https://docs.demiton.io/registers/asset_disposal/v3.json ## asset_meter_reading - Asset meter reading Holds: Odometer and engine-hour readings, as recorded. Status: Planned Domain: Assets Data: tenant Required fields: asset, read_at Filled today by: Navman Contract: https://docs.demiton.io/registers/asset_meter_reading/ JSON Schema: https://docs.demiton.io/registers/asset_meter_reading/v1.json ## asset_utilisation - Asset utilisation Holds: Engine hours and utilisation for plant and equipment. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: asset, odometer, occurred_at, engine_hours Filled today by: Hilti ON!Track, Navman Contract: https://docs.demiton.io/registers/asset_utilisation/ JSON Schema: https://docs.demiton.io/registers/asset_utilisation/v1.json ## attendance_record - Attendance record Holds: Who actually attended site, and when, as distinct from planned allocation. Status: Planned Domain: Workforce Data: tenant Required fields: project, signed_in_at Contract: https://docs.demiton.io/registers/attendance_record/ JSON Schema: https://docs.demiton.io/registers/attendance_record/v1.json ## bank_accounts - Bank accounts Holds: Bank accounts registered in your ERP. Each record is: State Status: Available Domain: Counterparties Data: tenant Required fields: account_name, canonical_key Filled today by: Universal Banking, Business Central Contract: https://docs.demiton.io/registers/bank_accounts/ JSON Schema: https://docs.demiton.io/registers/bank_accounts/v2.json ## bank_guarantee - Bank guarantee Holds: Bank guarantees and other security instruments given or held under a contract. Status: Planned Domain: Counterparties Data: tenant Required fields: amount, issuer, direction, counterparty Contract: https://docs.demiton.io/registers/bank_guarantee/ JSON Schema: https://docs.demiton.io/registers/bank_guarantee/v2.json ## bid_no_bid_verdict - Bid no bid verdict Holds: A bid/no-bid verdict for an open tender, weighing your prequalifications and certifications against its requirements. Each record is: Event Status: Available Domain: Opportunities Data: tenant Required fields: score, unmet, verdict, rationale, decided_at, source_ocid, held_posture, requirements, tender_title Contract: https://docs.demiton.io/registers/bid_no_bid_verdict/ JSON Schema: https://docs.demiton.io/registers/bid_no_bid_verdict/v1.json ## budget_vs_actual - Budget vs actual Holds: Budget against actual spend for the organisation, by expense category. Each record is: State Status: Declared Domain: Financials Data: tenant Required fields: actual_amount, budget_amount, legal_entity_id, expense_category, financial_period Filled today by: Business Central, Dynamics 365 Finance & Operations, Xero Contract: https://docs.demiton.io/registers/budget_vs_actual/ JSON Schema: https://docs.demiton.io/registers/budget_vs_actual/v1.json ## cash_position - Cash position Holds: Current cash balances across bank accounts. Each record is: State Status: Available Domain: Financials Data: tenant Required fields: as_of, accounts, total_cash_aud, legal_entity_id, accounts[].balance, accounts[].account_no, accounts[].account_name Filled today by: Universal Banking, Business Central, Xero Contract: https://docs.demiton.io/registers/cash_position/ JSON Schema: https://docs.demiton.io/registers/cash_position/v1.json ## certification_register - Certification register Holds: Worker credentials and their expiry, as safety and site-access systems hold them. Status: Planned Domain: Workforce Data: tenant Required fields: holder, external_id, credential_type Contract: https://docs.demiton.io/registers/certification_register/ JSON Schema: https://docs.demiton.io/registers/certification_register/v1.json ## change_event - Change event Holds: The early warning of a potential change, before it is priced as a variation. Status: Planned Domain: Contracts Data: tenant Required fields: title, status, project, external_id Contract: https://docs.demiton.io/registers/change_event/ JSON Schema: https://docs.demiton.io/registers/change_event/v2.json ## chart_of_accounts - Chart of accounts Holds: Your general ledger accounts. Each record is: State Status: Available Domain: Financials Data: tenant Required fields: external_id, account_name, account_number, account_category Filled today by: Business Central Contract: https://docs.demiton.io/registers/chart_of_accounts/ JSON Schema: https://docs.demiton.io/registers/chart_of_accounts/v1.json ## claim_line_observation - Claim line observation Data: tenant Contract: https://docs.demiton.io/registers/claim_line_observation/ JSON Schema: https://docs.demiton.io/registers/claim_line_observation/v1.json ## claim_window_verdict - Claim window verdict Data: tenant Required fields: detail, status, due_date, obligation, trigger_fact_id, trigger_shelf_type Contract: https://docs.demiton.io/registers/claim_window_verdict/ JSON Schema: https://docs.demiton.io/registers/claim_window_verdict/v1.json ## competency_verification - Competency verification Holds: Verification-of-competency assessments per worker. Each record is: Event Status: Available Domain: Workforce Data: tenant Required fields: worker, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/competency_verification/ JSON Schema: https://docs.demiton.io/registers/competency_verification/v1.json ## compliance_certifications - Compliance certifications Holds: Your organisation's compliance certificates: prequalifications, ISO certifications, statutory registrations. Each record is: Event Status: Available Domain: Safety Data: tenant Required fields: title, holder, expiry_date, _source_path, certifying_body Contract: https://docs.demiton.io/registers/compliance_certifications/ JSON Schema: https://docs.demiton.io/registers/compliance_certifications/v2.json ## compliance_documents - Compliance documents Holds: Safety and compliance documents attached to projects or workers. Each record is: Event Status: Available Domain: Safety Data: tenant Required fields: project, external_id, occurred_at, document_title Filled today by: Assignar, Azure AI Search, Dropbox, SharePoint Contract: https://docs.demiton.io/registers/compliance_documents/ JSON Schema: https://docs.demiton.io/registers/compliance_documents/v1.json ## compliance_evidence - Compliance evidence Holds: Evidence backing a compliance record: certificates, audit reports, licences. Each record is: State Status: Declared Domain: Safety Data: tenant Required fields: subject_entity_id, source_external_id Contract: https://docs.demiton.io/registers/compliance_evidence/ JSON Schema: https://docs.demiton.io/registers/compliance_evidence/v1.json ## compliance_gate_verdict - Compliance gate verdict Data: tenant Required fields: verdict, due_date, days_until_due, obligation_ref, source_fact_id, obligation_type, source_shelf_type Contract: https://docs.demiton.io/registers/compliance_gate_verdict/ JSON Schema: https://docs.demiton.io/registers/compliance_gate_verdict/v1.json ## compliance_prequal - Compliance prequal Holds: A counterparty's prequalification under a scheme, used to judge subcontractor or supplier eligibility. Each record is: State Status: Declared Domain: Safety Data: tenant Required fields: abn, scheme, classification Contract: https://docs.demiton.io/registers/compliance_prequal/ JSON Schema: https://docs.demiton.io/registers/compliance_prequal/v1.json ## compliance_state - Compliance state Holds: Current compliance status for one area of a legal entity: a scheme, obligation or requirement. Each record is: State Status: Declared Domain: Safety Data: tenant Required fields: as_of, title, status, cadence, declared, fact_key, is_active, scheme_key, shelf_type, record_kind, jurisdictions, obligation_key, requirement_id, subject_entity_id, max_contract_value Contract: https://docs.demiton.io/registers/compliance_state/ JSON Schema: https://docs.demiton.io/registers/compliance_state/v1.json ## construction_methodology - Construction methodology Holds: Work method statements and construction methodology held as reference for a project. Each record is: Procedure Status: Available Domain: Projects Data: tenant Required fields: title, hazards, source_path, method_steps Contract: https://docs.demiton.io/registers/construction_methodology/ JSON Schema: https://docs.demiton.io/registers/construction_methodology/v1.json ## contract_award_match - Contract award match Data: tenant Contract: https://docs.demiton.io/registers/contract_award_match/ JSON Schema: https://docs.demiton.io/registers/contract_award_match/v1.json ## contract_link - Contract link Holds: A verified link from one of your projects to a public government contracting record. Each record is: State Status: Declared Domain: Contracts Data: tenant Required fields: ocid, link_id, verified, created_at, link_state, updated_at, project_entity_id Contract: https://docs.demiton.io/registers/contract_link/ JSON Schema: https://docs.demiton.io/registers/contract_link/v1.json ## contract_notice - Contract notice Data: tenant Required fields: project, direction, served_on, external_id, notice_kind Contract: https://docs.demiton.io/registers/contract_notice/ JSON Schema: https://docs.demiton.io/registers/contract_notice/v1.json ## contract_penalty - Contract penalty Data: tenant Required fields: penalty_type, rate_currency, milestone_name Contract: https://docs.demiton.io/registers/contract_penalty/ JSON Schema: https://docs.demiton.io/registers/contract_penalty/v1.json ## contract_terms - Contract terms Holds: Commercial terms extracted from each contract document: payment terms, retention, notice windows, and liquidated damages (contract-wide and per milestone). Each record is: State Status: Declared Domain: Contracts Data: tenant Required fields: security, contract_sum, ld_milestones[].penalty_type, ld_milestones[].milestone_name, retention_pct, payment_timing_days, service_for_notices[].methods, service_for_notices[].party_role, service_for_notices[].email_basis, service_for_notices[].email_permitted, practical_completion_date Contract: https://docs.demiton.io/registers/contract_terms/ JSON Schema: https://docs.demiton.io/registers/contract_terms/v1.json ## cost_element - Cost element Holds: Posted job cost lines from your ERP job ledger. Each record is: Event Status: Available Domain: Financials Data: tenant Required fields: amount, project, currency, entry_no, occurred_at, financial_period Filled today by: Business Central Contract: https://docs.demiton.io/registers/cost_element/ JSON Schema: https://docs.demiton.io/registers/cost_element/v1.json ## credit_note - Credit note Holds: Credit notes issued against invoices. Status: Planned Domain: Financials Data: tenant Required fields: total, status, currency, direction, issued_on, external_id, counterparty Contract: https://docs.demiton.io/registers/credit_note/ JSON Schema: https://docs.demiton.io/registers/credit_note/v2.json ## customer_list - Customer list Holds: Customers registered in your ERP. Each record is: State Status: Available Domain: Counterparties Data: tenant Required fields: customer_entity_id Filled today by: Business Central, Dynamics 365 Finance & Operations, HubSpot Contract: https://docs.demiton.io/registers/customer_list/ JSON Schema: https://docs.demiton.io/registers/customer_list/v2.json ## daily_log - Daily log Holds: A structured daily log, distinct from a form-shaped site diary. Status: Planned Domain: Projects Data: tenant Required fields: project, log_date, external_id Contract: https://docs.demiton.io/registers/daily_log/ JSON Schema: https://docs.demiton.io/registers/daily_log/v1.json ## day_works_docket - Day works docket Holds: Day works dockets for extra or variation work. Each record is: Event Status: Available Domain: Contracts Data: tenant Required fields: project, work_date, description, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/day_works_docket/ JSON Schema: https://docs.demiton.io/registers/day_works_docket/v2.json ## diary_compliance_assessment - Diary compliance assessment Data: tenant Contract: https://docs.demiton.io/registers/diary_compliance_assessment/ JSON Schema: https://docs.demiton.io/registers/diary_compliance_assessment/v1.json ## diary_photo_observation - Diary photo observation Holds: What a site diary photo shows (subject, work type, quality, concerns), read from the image. Each record is: Event Status: Declared Domain: Projects Data: tenant Required fields: caption, subject, fact_class, occurred_at, photo_index, observation_id, financial_period, parent_diary_source_id Contract: https://docs.demiton.io/registers/diary_photo_observation/ JSON Schema: https://docs.demiton.io/registers/diary_photo_observation/v1.json ## dimension_set_entry - Dimension set entry Holds: The finance dimension values (such as equipment) attached to ERP postings. Each record is: Event Status: Available Domain: Financials Data: tenant Required fields: external_id, legal_entity, dimension_code, dimension_set_id, dimension_value_code Filled today by: Business Central Contract: https://docs.demiton.io/registers/dimension_set_entry/ JSON Schema: https://docs.demiton.io/registers/dimension_set_entry/v1.json ## document_filing_convention - Document filing convention Holds: Your conventions for where each document type is expected to live. Each record is: State Status: Available Domain: Platform Data: tenant Required fields: _authored, stage_roots, opportunity_ref_pattern Contract: https://docs.demiton.io/registers/document_filing_convention/ JSON Schema: https://docs.demiton.io/registers/document_filing_convention/v1.json ## document_list - Document list Holds: Documents and files in your connected storage. Live, bound to connected storage, but with no published contract yet. Each record is: State Status: Live - no contract yet Domain: Documents Data: tenant Filled today by: Azure AI Search, Microsoft Dataverse, Demiton Storage, Dropbox, GitHub, SharePoint Contract: https://docs.demiton.io/registers/document_list/ JSON Schema: https://docs.demiton.io/registers/document_list/v1.json ## document_location - Document location Holds: Where an entity's source documents live: a SharePoint or Dropbox folder. Each record is: State Status: Declared Domain: Documents Data: tenant Required fields: system, sources, entity_type, connector_ref, coordinate_key Contract: https://docs.demiton.io/registers/document_location/ JSON Schema: https://docs.demiton.io/registers/document_location/v1.json ## document_location:asset - Document location (asset) Holds: The document folder bound to a plant or equipment asset. Each record is: State Status: Declared Domain: Documents Data: tenant Required fields: system, sources, entity_type, connector_ref, coordinate_key Contract: https://docs.demiton.io/registers/document_location--asset/ JSON Schema: https://docs.demiton.io/registers/document_location--asset/v1.json ## document_location:opportunity - Document location (opportunity) Holds: The document folder bound to a tender or opportunity. Each record is: State Status: Available Domain: Documents Data: tenant Required fields: sources, entity_type, coordinate_key, sources[].system, sources[].connector_ref Contract: https://docs.demiton.io/registers/document_location--opportunity/ JSON Schema: https://docs.demiton.io/registers/document_location--opportunity/v1.json ## document_location:project - Document location (project) Holds: The document folder bound to a project. Each record is: State Status: Available Domain: Documents Data: tenant Required fields: sources, entity_type, sources[].system, sources[].connector_ref Contract: https://docs.demiton.io/registers/document_location--project/ JSON Schema: https://docs.demiton.io/registers/document_location--project/v1.json ## document_transmittal - Document transmittal Holds: Transmittals recording which documents went to whom, and when. Status: Planned Domain: Documents Data: tenant Required fields: number, status, project, sent_at, subject, external_id Contract: https://docs.demiton.io/registers/document_transmittal/ JSON Schema: https://docs.demiton.io/registers/document_transmittal/v1.json ## drawing_register - Drawing register Holds: The drawing register: each drawing, its revision and status. Status: Planned Domain: Projects Data: tenant Required fields: title, project, revision, external_id, drawing_number Contract: https://docs.demiton.io/registers/drawing_register/ JSON Schema: https://docs.demiton.io/registers/drawing_register/v1.json ## driving_behaviour_event - Driving behaviour event Holds: Harsh braking, acceleration and cornering events from telematics. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: asset, category, external_id, occurred_at, acceleration_g, deceleration_g Filled today by: Navman Contract: https://docs.demiton.io/registers/driving_behaviour_event/ JSON Schema: https://docs.demiton.io/registers/driving_behaviour_event/v1.json ## dropbox_document_routing - Dropbox document routing Holds: Your rules for routing an incoming Dropbox document to the right folder. Each record is: Procedure Status: Available Domain: Documents Data: tenant Required fields: rules, scope, default_action, dropbox_prefix, subject_entity_id Contract: https://docs.demiton.io/registers/dropbox_document_routing/ JSON Schema: https://docs.demiton.io/registers/dropbox_document_routing/v1.json ## employee_contact_detail - Employee contact detail Holds: Employee contact and emergency-contact details from payroll. Readable only by roles permitted to see personal information. Each record is: Event Status: Available Domain: Workforce Data: tenant Required fields: worker, external_id Filled today by: Employment Hero Payroll Contract: https://docs.demiton.io/registers/employee_contact_detail/ JSON Schema: https://docs.demiton.io/registers/employee_contact_detail/v1.json ## employee_hr_records - Employee hr records Holds: HR record events for a worker: leave, disciplinary action, personnel file changes. Each record is: Event Status: Available Domain: Workforce Data: tenant Required fields: worker, start_date, external_id, family_name, occurred_at, employment_basis Filled today by: Assignar Contract: https://docs.demiton.io/registers/employee_hr_records/ JSON Schema: https://docs.demiton.io/registers/employee_hr_records/v1.json ## employee_list - Employee list Holds: Employees registered in your payroll system. Each record is: State Status: Available Domain: Workforce Data: tenant Required fields: display_name, employment_type, worker_entity_id, source_external_id, employment_start_date Filled today by: Dynamics 365 Finance & Operations, Employment hero, Employment Hero Payroll, Navman Contract: https://docs.demiton.io/registers/employee_list/ JSON Schema: https://docs.demiton.io/registers/employee_list/v1.json ## entity_attribute - Entity attribute Holds: One key/value attribute on a project, worker, asset or other entity, such as a project's stage. Each record is: State Status: Declared Domain: Counterparties Data: tenant Required fields: value, shelf_type, asserted_at, attribute_key, subject_entity_id Contract: https://docs.demiton.io/registers/entity_attribute/ JSON Schema: https://docs.demiton.io/registers/entity_attribute/v1.json ## entity_link_origin - Entity link origin Holds: Where a record's link to an opportunity or customer came from in your CRM or ERP. Each record is: State Status: Available Domain: Counterparties Data: tenant Required fields: relation, computed_at, object_entity_id, subject_entity_id, link_source_system, object_entity_type, object_external_id, subject_entity_type Filled today by: Business Central, HubSpot Contract: https://docs.demiton.io/registers/entity_link_origin/ JSON Schema: https://docs.demiton.io/registers/entity_link_origin/v2.json ## environmental_aspect - Environmental aspect Holds: The environmental aspects and impacts register an ISO 14001 system keeps. Status: Planned Domain: Safety Data: tenant Required fields: aspect, impact, activity Contract: https://docs.demiton.io/registers/environmental_aspect/ JSON Schema: https://docs.demiton.io/registers/environmental_aspect/v1.json ## environmental_observation - Environmental observation Holds: Environmental observations on site: dust, noise, water, spills. Status: Planned Domain: Safety Data: tenant Required fields: project, description, external_id, observed_on Contract: https://docs.demiton.io/registers/environmental_observation/ JSON Schema: https://docs.demiton.io/registers/environmental_observation/v1.json ## equipment_assignment - Equipment assignment Holds: Current and past equipment assignments to projects and sites. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: asset, hours, project, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/equipment_assignment/ JSON Schema: https://docs.demiton.io/registers/equipment_assignment/v1.json ## equipment_list - Equipment list Holds: The plant and equipment register across your operational systems. Each record is: State Status: Available Domain: Assets Data: tenant Required fields: asset, label, occurred_at, source_record_id Filled today by: Assignar, Hilti ON!Track, Trimble Contract: https://docs.demiton.io/registers/equipment_list/ JSON Schema: https://docs.demiton.io/registers/equipment_list/v1.json ## equipment_transfer - Equipment transfer Holds: Plant and equipment moves between sites. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: asset, external_id, occurred_at, to_location, from_location Filled today by: Hilti ON!Track Contract: https://docs.demiton.io/registers/equipment_transfer/ JSON Schema: https://docs.demiton.io/registers/equipment_transfer/v1.json ## estimating_email - Estimating email Holds: Emails in your estimating mailbox, filed against the opportunity they concern. Each record is: Event Status: Available Domain: Opportunities Data: tenant Required fields: id, from, subject, email_id, polarity, attachments, reason_code, received_at, conversation_id, has_attachments Filled today by: Microsoft 365 mail Contract: https://docs.demiton.io/registers/estimating_email/ JSON Schema: https://docs.demiton.io/registers/estimating_email/v1.json ## evidence_gap_verdict - Evidence gap verdict Data: tenant Required fields: grade, detail, status, consequence, dispute_type, source_title, standard_key, source_clause Contract: https://docs.demiton.io/registers/evidence_gap_verdict/ JSON Schema: https://docs.demiton.io/registers/evidence_gap_verdict/v1.json ## expense_claims - Expense claims Holds: Employee expense claims, by worker and period. Each record is: Event Status: Available Domain: Payroll Data: tenant Required fields: worker_id, external_id, claim_amount, submitted_time Filled today by: Assignar Contract: https://docs.demiton.io/registers/expense_claims/ JSON Schema: https://docs.demiton.io/registers/expense_claims/v1.json ## extraction_procedure - Extraction procedure Holds: How a document type is parsed into structured facts. Each record is: Procedure Status: Available Domain: Platform Data: tenant Required fields: methods, doc_type, org_entity_id Contract: https://docs.demiton.io/registers/extraction_procedure/ JSON Schema: https://docs.demiton.io/registers/extraction_procedure/v1.json ## financial_period_list - Financial period list Holds: Accounting periods from your ERP. Each record is: State Status: Available Domain: Financials Data: tenant Required fields: period, period_start Filled today by: Business Central Contract: https://docs.demiton.io/registers/financial_period_list/ JSON Schema: https://docs.demiton.io/registers/financial_period_list/v1.json ## fixed_asset_list - Fixed asset list Holds: Fixed assets from your ERP, with cost, book value and depreciation. Each record is: State Status: Available Domain: Assets Data: tenant Required fields: external_id, asset_class_code Filled today by: Business Central Contract: https://docs.demiton.io/registers/fixed_asset_list/ JSON Schema: https://docs.demiton.io/registers/fixed_asset_list/v2.json ## fuel_transaction - Fuel transaction Holds: Individual fuel purchases and fills from fleet systems. Status: Planned Domain: Assets Data: tenant Required fields: asset, quantity, transacted_at Contract: https://docs.demiton.io/registers/fuel_transaction/ JSON Schema: https://docs.demiton.io/registers/fuel_transaction/v2.json ## gl_journal_entry - Gl journal entry Holds: General ledger journal entries: payroll, payables, receivables and manual postings. Each record is: Event Status: Available Domain: Financials Data: tenant Required fields: gl_account, external_id, occurred_at, debit_amount, credit_amount, financial_period Filled today by: Business Central, Dynamics 365 Finance & Operations, Xero Contract: https://docs.demiton.io/registers/gl_journal_entry/ JSON Schema: https://docs.demiton.io/registers/gl_journal_entry/v1.json ## gps_event - Gps event Holds: GPS events: ignition, speed, geofence crossings. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: asset, event_type, occurred_at Filled today by: Navman, Trimble Contract: https://docs.demiton.io/registers/gps_event/ JSON Schema: https://docs.demiton.io/registers/gps_event/v1.json ## group_members - Group members Holds: Members of each group in your identity directory. Each record is: State Status: Declared Domain: Counterparties Data: tenant Required fields: observed_at, group_source_id, member_entity_id, member_source_id Filled today by: Microsoft Entra ID Contract: https://docs.demiton.io/registers/group_members/ JSON Schema: https://docs.demiton.io/registers/group_members/v1.json ## health_screening - Health screening Holds: Fitness-for-work and fatigue screening results, by worker and project. Each record is: Event Status: Available Domain: Workforce Data: tenant Required fields: worker, form_title, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/health_screening/ JSON Schema: https://docs.demiton.io/registers/health_screening/v1.json ## hilti_location - Hilti location Holds: Where a tool tracked in Hilti ON!Track is located. Each record is: State Status: Declared Domain: Assets Data: tenant Required fields: label, location, occurred_at, source_record_id Filled today by: Hilti ON!Track Contract: https://docs.demiton.io/registers/hilti_location/ JSON Schema: https://docs.demiton.io/registers/hilti_location/v1.json ## implementation_request - Implementation request Data: tenant Required fields: status, register, hours_logs, requested_at, project_entity_id, rate_aud_per_hour Contract: https://docs.demiton.io/registers/implementation_request/ JSON Schema: https://docs.demiton.io/registers/implementation_request/v1.json ## induction_onboarding - Induction onboarding Holds: Site induction and onboarding acknowledgements. Each record is: Event Status: Available Domain: Workforce Data: tenant Required fields: worker, form_id, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/induction_onboarding/ JSON Schema: https://docs.demiton.io/registers/induction_onboarding/v1.json ## inspection_test_result - Inspection test result Holds: Soil and concrete test results (AS 1289, AS 1012). Each record is: Event Status: Declared Domain: Safety Data: tenant Required fields: project, material, tested_on, result_unit, test_method, result_value Contract: https://docs.demiton.io/registers/inspection_test_result/ JSON Schema: https://docs.demiton.io/registers/inspection_test_result/v1.json ## insurance_certificate - Insurance certificate Holds: A counterparty's certificates of currency, which gate site access. Status: Planned Domain: Counterparties Data: tenant Required fields: expires_on, insured_party, insurance_type Contract: https://docs.demiton.io/registers/insurance_certificate/ JSON Schema: https://docs.demiton.io/registers/insurance_certificate/v2.json ## intercompany_transaction - Intercompany transaction Holds: Transactions between companies in your group, for elimination on consolidation. Status: Planned Domain: Financials Data: tenant Required fields: amount, direction, posted_on, external_id, legal_entity, partner_entity Contract: https://docs.demiton.io/registers/intercompany_transaction/ JSON Schema: https://docs.demiton.io/registers/intercompany_transaction/v2.json ## invoice_issued - Invoice issued Holds: Invoices your organisation has issued to customers. Each record is: Event Status: Available Domain: Financials Data: tenant Required fields: issue_date, tax_amount, customer_ref, currency_code, invoice_number, document_concept, financial_period, tax_jurisdiction, amount_excluding_tax, amount_including_tax Filled today by: Business Central, Dynamics 365 Finance & Operations, Xero Contract: https://docs.demiton.io/registers/invoice_issued/ JSON Schema: https://docs.demiton.io/registers/invoice_issued/v2.json ## job_budget - Job budget Holds: Job budgets per project, by expense category. Each record is: State Status: Available Domain: Financials Data: tenant Required fields: project_id, legal_entity_id, financial_period, total_budget_aud Filled today by: Business Central Contract: https://docs.demiton.io/registers/job_budget/ JSON Schema: https://docs.demiton.io/registers/job_budget/v1.json ## job_progress - Job progress Holds: Job progress from your ERP: percent complete and percent invoiced. Each record is: State Status: Available Domain: Projects Data: tenant Required fields: job_no, project_id, percent_invoiced, percent_completed Filled today by: Business Central Contract: https://docs.demiton.io/registers/job_progress/ JSON Schema: https://docs.demiton.io/registers/job_progress/v1.json ## leave_balance - Leave balance Holds: Current leave balances per employee and leave category. Each record is: Event Status: Available Domain: Workforce Data: tenant Required fields: worker_ref, balance_as_of, leave_category, accrued_balance, leave_category_name Filled today by: Employment Hero Payroll Contract: https://docs.demiton.io/registers/leave_balance/ JSON Schema: https://docs.demiton.io/registers/leave_balance/v1.json ## leave_category_list - Leave category list Holds: Leave types defined in your payroll and operational systems. Each record is: State Status: Available Domain: Workforce Data: tenant Required fields: code, name, unit_type, source_external_id, leave_category_type, leave_code_entity_id Filled today by: Assignar, Employment hero, Employment Hero Payroll Contract: https://docs.demiton.io/registers/leave_category_list/ JSON Schema: https://docs.demiton.io/registers/leave_category_list/v1.json ## leave_request - Leave request Holds: Leave requests and their approval status. Each record is: Event Status: Available Domain: Workforce Data: tenant Required fields: hours, worker, to_date, from_date, leave_type, is_approved, source_record_id Filled today by: Assignar, Employment Hero Payroll Contract: https://docs.demiton.io/registers/leave_request/ JSON Schema: https://docs.demiton.io/registers/leave_request/v1.json ## legal_entities - Legal entities Holds: The operating companies in your group: the root every worker, project and cost code belongs to. Each record is: State Status: Available Domain: Counterparties Data: tenant Required fields: legal_name, external_id, base_currency Filled today by: Business Central, Employment Hero Payroll Contract: https://docs.demiton.io/registers/legal_entities/ JSON Schema: https://docs.demiton.io/registers/legal_entities/v2.json ## maintenance_record - Maintenance record Holds: Plant service and maintenance records. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: asset, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/maintenance_record/ JSON Schema: https://docs.demiton.io/registers/maintenance_record/v2.json ## margin_driver_contribution - Margin driver contribution Holds: Predicted contribution of each cost or revenue driver to a project's margin, by period. Each record is: Event Status: Declared Domain: Projects Data: tenant Required fields: fact_class, project_id, model_version, financial_period, driver_delay_hours, driver_labour_hours, predicted_margin_pct, driver_cost_growth_pct, driver_variation_count Contract: https://docs.demiton.io/registers/margin_driver_contribution/ JSON Schema: https://docs.demiton.io/registers/margin_driver_contribution/v1.json ## margin_watch_learning - Margin watch learning Holds: Lessons and observability gaps Margin Watch has found on a project, awaiting review. Each record is: State Status: Declared Domain: Projects Data: tenant Required fields: summary, promotion_gate, lesson_candidates, subject_entity_id, lesson_candidates[].cause, observability_gaps_ranked, lesson_candidates[].statement, observability_gaps_ranked[].gap, lesson_candidates[].promotion_gate, observability_gaps_ranked[].months, lesson_candidates[].provenance.month, lesson_candidates[].provenance.evidence, lesson_candidates[].provenance.drift_pts, observability_gaps_ranked[].margin_points_obscured Contract: https://docs.demiton.io/registers/margin_watch_learning/ JSON Schema: https://docs.demiton.io/registers/margin_watch_learning/v1.json ## market_intelligence - Market intelligence Holds: Demand, competition and pricing signals for a sector or region. Each record is: State Status: Declared Domain: Opportunities Data: tenant Required fields: sources, shelf_type, memory_type, snapshot_id, generated_at, contract_count, organization_id, total_value_aud, subject_entity_id Contract: https://docs.demiton.io/registers/market_intelligence/ JSON Schema: https://docs.demiton.io/registers/market_intelligence/v1.json ## market_opportunity_fit_score - Market opportunity fit score Data: tenant Contract: https://docs.demiton.io/registers/market_opportunity_fit_score/ JSON Schema: https://docs.demiton.io/registers/market_opportunity_fit_score/v1.json ## memory_recall - Memory recall Holds: Conclusions Ask Demiton and your workflows have written back to memory. Each record is: Event Status: Available Domain: Platform Data: tenant Required fields: content, confidence, occurred_at, subject_entity_id Contract: https://docs.demiton.io/registers/memory_recall/ JSON Schema: https://docs.demiton.io/registers/memory_recall/v1.json ## opportunities - Opportunities Holds: Your commercial pipeline: won, lost and in-flight opportunities from CRM or ERP. Each record is: State Status: Available Domain: Opportunities Data: tenant Required fields: as_at, title, amount, status, currency, value_basis, opportunity_number Filled today by: Business Central, HubSpot Contract: https://docs.demiton.io/registers/opportunities/ JSON Schema: https://docs.demiton.io/registers/opportunities/v2.json ## opportunity - Opportunity Holds: Changes to a pipeline opportunity over time. Each record is: Event Status: Available Domain: Opportunities Data: tenant Required fields: title, value, outcome, currency, bid_status, external_id, occurred_at Filled today by: Business Central, HubSpot Contract: https://docs.demiton.io/registers/opportunity/ JSON Schema: https://docs.demiton.io/registers/opportunity/v2.json ## opportunity_specifications - Opportunity specifications Holds: Technical and scope specifications extracted from an opportunity's tender documents. Each record is: State Status: Available Domain: Opportunities Data: tenant Required fields: issuing_body, specifications, specification_code, source_document_path, specification_description Contract: https://docs.demiton.io/registers/opportunity_specifications/ JSON Schema: https://docs.demiton.io/registers/opportunity_specifications/v1.json ## opportunity_win_probability - Opportunity win probability Holds: Predicted probability of winning a pipeline opportunity. Each record is: Event Status: Declared Domain: Opportunities Data: tenant Required fields: p_win, n_wins, currency, n_losses, scored_at, model_version, training_as_of, n_training_rows, subject_opportunity_ref Contract: https://docs.demiton.io/registers/opportunity_win_probability/ JSON Schema: https://docs.demiton.io/registers/opportunity_win_probability/v2.json ## overrun_risk_verdict - Overrun risk verdict Data: tenant Required fields: basis, detail, cost_code, budget_aud, variance_aud Contract: https://docs.demiton.io/registers/overrun_risk_verdict/ JSON Schema: https://docs.demiton.io/registers/overrun_risk_verdict/v1.json ## overstaffing_verdict - Overstaffing verdict Holds: Whether a project's actual crew exceeds its tendered labour schedule. Each record is: State Status: Declared Domain: Opportunities Data: tenant Required fields: verdict, burn_pct, assessed_at, elapsed_pct, project_ref, actual_hours, budget_hours, run_rate_pct Contract: https://docs.demiton.io/registers/overstaffing_verdict/ JSON Schema: https://docs.demiton.io/registers/overstaffing_verdict/v1.json ## overstaffing_verdict:overstaffing_verdict - Overstaffing verdict (instances) Holds: Per-project instances of the overstaffing verdict. Each record is: State Status: Declared Domain: Opportunities Data: tenant Required fields: verdict, burn_pct, assessed_at, elapsed_pct, project_ref, actual_hours, budget_hours, run_rate_pct Contract: https://docs.demiton.io/registers/overstaffing_verdict--overstaffing_verdict/ JSON Schema: https://docs.demiton.io/registers/overstaffing_verdict--overstaffing_verdict/v1.json ## pay_categories - Pay categories Holds: Pay category definitions, with rates and award mappings. Each record is: State Status: Available Domain: Payroll Data: tenant Required fields: statutory_income_type, pay_category_entity_id Filled today by: Employment Hero Payroll Contract: https://docs.demiton.io/registers/pay_categories/ JSON Schema: https://docs.demiton.io/registers/pay_categories/v1.json ## payable_entry - Payable entry Holds: Outstanding supplier bills and the aged payables balance. Each record is: Event Status: Available Domain: Counterparties Data: tenant Required fields: amount, vendor, due_date, remaining, external_id, occurred_at, financial_period Filled today by: Business Central, Dynamics 365 Finance & Operations, Xero Contract: https://docs.demiton.io/registers/payable_entry/ JSON Schema: https://docs.demiton.io/registers/payable_entry/v2.json ## payment_schedule - Payment schedule Holds: The payment schedule answering a progress claim under Security of Payment legislation. Status: Planned Domain: Contracts Data: tenant Required fields: claim, project, currency, issued_on, external_id, jurisdiction, scheduled_amount Contract: https://docs.demiton.io/registers/payment_schedule/ JSON Schema: https://docs.demiton.io/registers/payment_schedule/v2.json ## payroll_run - Payroll run Holds: Completed pay runs with gross and net totals. Each record is: Event Status: Available Domain: Payroll Data: tenant Required fields: total_net, external_id, occurred_at, total_gross, is_finalised, legal_entity, financial_period, pay_period_start Filled today by: Employment Hero Payroll Contract: https://docs.demiton.io/registers/payroll_run/ JSON Schema: https://docs.demiton.io/registers/payroll_run/v2.json ## permit_to_work - Permit to work Holds: Permits controlling hazardous work. Status: Planned Domain: Safety Data: tenant Required fields: status, project, reference, external_id, permit_type Contract: https://docs.demiton.io/registers/permit_to_work/ JSON Schema: https://docs.demiton.io/registers/permit_to_work/v1.json ## plant_fuel_usage - Plant fuel usage Holds: Plant and vehicle fuel usage per project, for fuel tax credit claims. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: item, litres, project, external_id, occurred_at, claim_amount_aud Contract: https://docs.demiton.io/registers/plant_fuel_usage/ JSON Schema: https://docs.demiton.io/registers/plant_fuel_usage/v1.json ## plant_prestart - Plant prestart Holds: Daily plant and equipment pre-start checks: condition, defects, compliance. Each record is: Event Status: Available Domain: Safety Data: tenant Required fields: asset, external_id, occurred_at, flagged_count Filled today by: Assignar Contract: https://docs.demiton.io/registers/plant_prestart/ JSON Schema: https://docs.demiton.io/registers/plant_prestart/v2.json ## plant_registration - Plant registration Holds: Plant item registrations (AS 2550 item registers). Status: Planned Domain: Assets Data: tenant Required fields: asset, regulator, jurisdiction, registration_kind, registration_number Contract: https://docs.demiton.io/registers/plant_registration/ JSON Schema: https://docs.demiton.io/registers/plant_registration/v2.json ## plant_risk_assessment - Plant risk assessment Holds: Plant and equipment risk assessments. Each record is: Event Status: Available Domain: Safety Data: tenant Required fields: worker, form_title, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/plant_risk_assessment/ JSON Schema: https://docs.demiton.io/registers/plant_risk_assessment/v1.json ## plant_snapshot - Plant snapshot Holds: The plant register at a project location at a point in time. Each record is: Event Status: Declared Domain: Assets Data: tenant Required fields: assets, project, asset_count, external_id, occurred_at Contract: https://docs.demiton.io/registers/plant_snapshot/ JSON Schema: https://docs.demiton.io/registers/plant_snapshot/v1.json ## platform_award - Platform award Holds: Awarded government civil contracts, from AusTender and state sources. Each record is: Event Status: Available Domain: Platform Data: platform Required fields: ocid, agency_id, award_date, agency_name, external_id, observed_at, source_dataset, platform_project_id, supplier_identification Filled today by: AusTender, OpenContractsAU Contract: https://docs.demiton.io/registers/platform_award/ JSON Schema: https://docs.demiton.io/registers/platform_award/v2.json ## platform_contractor_stats - Platform contractor stats Holds: Per-contractor statistics rolled up from awarded contracts. Each record is: State Status: Available Domain: Platform Data: platform Required fields: series_key, window_end, observed_at, value_basis, window_start, last_win_date, contractor_abn, source_dataset, contract_count_3yr, contractor_entity_id, total_awarded_aud_3yr Contract: https://docs.demiton.io/registers/platform_contractor_stats/ JSON Schema: https://docs.demiton.io/registers/platform_contractor_stats/v1.json ## platform_entity_attr - Platform entity attr Holds: ABR registration details for a contractor ABN. Each record is: State Status: Available Domain: Platform Data: platform Required fields: abn, status, entity_name, entity_type, observed_at, gst_registered, source_dataset Filled today by: Australian Business Register Contract: https://docs.demiton.io/registers/platform_entity_attr/ JSON Schema: https://docs.demiton.io/registers/platform_entity_attr/v2.json ## platform_evidence_standard - Platform evidence standard Data: platform Required fields: kind, grade, register, consequence, dispute_type, jurisdiction, source_title, standard_key, source_clause, applies_to_form Contract: https://docs.demiton.io/registers/platform_evidence_standard/ JSON Schema: https://docs.demiton.io/registers/platform_evidence_standard/v1.json ## platform_obligation - Platform obligation Data: platform Required fields: duty, kind, grade, source, disease, register, severity, source_url, consequence, dispute_type, jurisdiction, source_title, standard_key, evidence_kind, instrument_id, applies_to_form, protection_type, citation_access_date Contract: https://docs.demiton.io/registers/platform_obligation/ JSON Schema: https://docs.demiton.io/registers/platform_obligation/v1.json ## platform_planning - Platform planning Holds: Forward programme and works-to-tender notices from government pipelines. Each record is: Event Status: Available Domain: Platform Data: platform Required fields: ocid, stage, title, agency_id, source_id, project_id, shelf_type, agency_name, occurred_at, source_dataset Filled today by: Australian Energy Regulator, ANZ Infrastructure Pipeline, NSW eTendering, NSW Infrastructure Pipeline, Queensland Forward Procurement Pipeline Contract: https://docs.demiton.io/registers/platform_planning/ JSON Schema: https://docs.demiton.io/registers/platform_planning/v2.json ## platform_prequal - Platform prequal Holds: A contractor's status on government prequalification registers. Each record is: Event Status: Available Domain: Platform Data: platform Required fields: abn, scheme, status, observed_at, classification, source_dataset Filled today by: GitHub Contract: https://docs.demiton.io/registers/platform_prequal/ JSON Schema: https://docs.demiton.io/registers/platform_prequal/v2.json ## platform_rate - Platform rate Holds: Economic series: RBA cash and lending rates, ABS price and wage indices. Each record is: State Status: Available Domain: Platform Data: platform Required fields: label, value, period, series_key, observed_at, indicator_ref, source_dataset, jurisdiction_code Filled today by: Reserve Bank of Australia, Australian Bureau of Statistics Contract: https://docs.demiton.io/registers/platform_rate/ JSON Schema: https://docs.demiton.io/registers/platform_rate/v2.json ## platform_research_finding - Platform research finding Data: platform Required fields: label, confidence, metric_key, source_org, source_url, disease_key, source_title, exposure_kind, exposure_unit, exposure_basis, exposure_value Contract: https://docs.demiton.io/registers/platform_research_finding/ JSON Schema: https://docs.demiton.io/registers/platform_research_finding/v2.json ## platform_tender - Platform tender Holds: Open government civil tender notices. Each record is: Event Status: Available Domain: Platform Data: platform Required fields: ocid, title, close_date, external_id, occurred_at, source_dataset, platform_project_id Filled today by: AusTender, NSW eTendering, SA Tenders, Tasmanian Government Tenders, Tenderlink, VendorPanel, Buying for Victoria, Tenders WA, Western Power Contract: https://docs.demiton.io/registers/platform_tender/ JSON Schema: https://docs.demiton.io/registers/platform_tender/v2.json ## platform_weather - Platform weather Holds: Current Bureau of Meteorology observations by region. Each record is: Event Status: Available Domain: Platform Data: platform Required fields: geohash, observed_at, region_code, temperature_c, source_dataset, jurisdiction_code Filled today by: Bureau of Meteorology Contract: https://docs.demiton.io/registers/platform_weather/ JSON Schema: https://docs.demiton.io/registers/platform_weather/v2.json ## policy_acknowledgements - Policy acknowledgements Holds: A worker's sign-off that a policy or procedure was read and accepted. Each record is: Event Status: Available Domain: Workforce Data: tenant Required fields: worker, form_id, external_id, occurred_at, acknowledged Filled today by: Assignar Contract: https://docs.demiton.io/registers/policy_acknowledgements/ JSON Schema: https://docs.demiton.io/registers/policy_acknowledgements/v1.json ## portal_document - Portal document Holds: Documents downloaded from a client or tender portal, by project. Each record is: Event Status: Declared Domain: Projects Data: tenant Required fields: name, sha256, fact_class, size_bytes, external_id, occurred_at, source_portal, financial_period Contract: https://docs.demiton.io/registers/portal_document/ JSON Schema: https://docs.demiton.io/registers/portal_document/v2.json ## prequalification_answer - Prequalification answer Holds: Your answers to a prequalification questionnaire. Status: Planned Domain: Safety Data: tenant Required fields: form_id, question_id Contract: https://docs.demiton.io/registers/prequalification_answer/ JSON Schema: https://docs.demiton.io/registers/prequalification_answer/v1.json ## profit_and_loss - Profit and loss Holds: Profit and loss for a period. Each record is: State Status: Available Domain: Financials Data: tenant Required fields: project_id, actual_amount, budget_amount, financial_period Filled today by: Business Central, Dynamics 365 Finance & Operations, Xero Contract: https://docs.demiton.io/registers/profit_and_loss/ JSON Schema: https://docs.demiton.io/registers/profit_and_loss/v2.json ## programme - Programme Holds: A construction programme extracted from an uploaded schedule document. Each record is: State Status: Available Domain: Projects Data: tenant Required fields: source_document Contract: https://docs.demiton.io/registers/programme/ JSON Schema: https://docs.demiton.io/registers/programme/v1.json ## progress_claim - Progress claim Holds: Progress claims issued per project: claimed, certified, paid and retention held. Each record is: Event Status: Available Domain: Contracts Data: tenant Required fields: amount, project, quantity, external_id, occurred_at, financial_period Filled today by: Business Central, Xero Contract: https://docs.demiton.io/registers/progress_claim/ JSON Schema: https://docs.demiton.io/registers/progress_claim/v2.json ## project_details - Project details Holds: Details of active and completed projects from your operational and ERP systems. Each record is: State Status: Available Domain: Projects Data: tenant Required fields: name, job_number Filled today by: Assignar, Business Central, Dynamics 365 Finance & Operations, Employment Hero Payroll, monday.com, Trimble, Xero Contract: https://docs.demiton.io/registers/project_details/ JSON Schema: https://docs.demiton.io/registers/project_details/v2.json ## project_list - Project list Holds: Active and completed projects from your operational and ERP systems. Each record is: State Status: Available Domain: Projects Data: tenant Required fields: project_entity_id Filled today by: Assignar, Business Central, Dynamics 365 Finance & Operations, Employment Hero Payroll, monday.com, Trimble, Xero Contract: https://docs.demiton.io/registers/project_list/ JSON Schema: https://docs.demiton.io/registers/project_list/v2.json ## project_milestone - Project milestone Holds: Delivery milestones: planned and actual dates for practical completion, defects liability and other key dates. Each record is: State Status: Declared Domain: Projects Data: tenant Required fields: name, source, planned_date Contract: https://docs.demiton.io/registers/project_milestone/ JSON Schema: https://docs.demiton.io/registers/project_milestone/v1.json ## project_obligation - Project obligation Data: tenant Required fields: source, visibility, switched_on, obligation_key Contract: https://docs.demiton.io/registers/project_obligation/ JSON Schema: https://docs.demiton.io/registers/project_obligation/v1.json ## project_outcome - Project outcome Holds: A project's actual financial outcome at close-out or a reporting point. Each record is: Event Status: Declared Domain: Projects Data: tenant Required fields: project, margin_pct, external_id, occurred_at, recorded_at, revenue_actual, cost_growth_pct, financial_period Contract: https://docs.demiton.io/registers/project_outcome/ JSON Schema: https://docs.demiton.io/registers/project_outcome/v2.json ## project_performance_record - Project performance record Holds: A project's performance summary for a period: margin, schedule and quality signals. Each record is: State Status: Declared Domain: Projects Data: tenant Required fields: subject, summary, claim_cycle, margin_alerts, outcome.budget, schema_version, outcome.margin_pct, claim_cycle.curve[], classification.name, outcome.cost_actual, divergence_attribution, data_quality.confidence, outcome.cost_growth_pct, provenance.generated_at, claim_cycle.curve[].month, claim_cycle.curve[].cum_cost, margin_alerts.active_alerts[], data_quality.sources_missing[], data_quality.sources_present[], claim_cycle.curve[].cum_claimed, divergence_attribution.cycles[], data_quality.source_coverage_pct, margin_alerts.active_alerts[].rule, margin_alerts.active_alerts[].level, margin_alerts.active_alerts[].month, divergence_attribution.cycles[].month, claim_cycle.curve[].margin_to_date_pct, divergence_attribution.cycles[].drift_pts, divergence_attribution.cycles[].causes[].cause Contract: https://docs.demiton.io/registers/project_performance_record/ JSON Schema: https://docs.demiton.io/registers/project_performance_record/v2.json ## protection - Protection Data: tenant Required fields: disease, severity, ready_state, obligation_key, protection_type Contract: https://docs.demiton.io/registers/protection/ JSON Schema: https://docs.demiton.io/registers/protection/v1.json ## punch_list - Punch list Holds: Completion defects to close out before handover. Status: Planned Domain: Projects Data: tenant Required fields: name, status, project, external_id Contract: https://docs.demiton.io/registers/punch_list/ JSON Schema: https://docs.demiton.io/registers/punch_list/v1.json ## purchase_line - Purchase line Holds: Job-linked purchase order and invoice lines. Each record is: Event Status: Available Domain: Financials Data: tenant Required fields: amount, project, currency, quantity, unit_cost, order_date, line_number, document_type, document_number, unit_of_measure, financial_period Filled today by: Business Central Contract: https://docs.demiton.io/registers/purchase_line/ JSON Schema: https://docs.demiton.io/registers/purchase_line/v2.json ## purchase_order - Purchase order Holds: Purchase orders raised against suppliers: committed spend not yet posted. Each record is: Event Status: Available Domain: Financials Data: tenant Required fields: amount, vendor, external_id, occurred_at Filled today by: Business Central, Xero Contract: https://docs.demiton.io/registers/purchase_order/ JSON Schema: https://docs.demiton.io/registers/purchase_order/v2.json ## receivable_entry - Receivable entry Holds: Outstanding customer invoices and the aged receivables balance. Each record is: Event Status: Available Domain: Counterparties Data: tenant Required fields: amount, customer, due_date, remaining, external_id, occurred_at, financial_period Filled today by: Business Central, Dynamics 365 Finance & Operations, Xero Contract: https://docs.demiton.io/registers/receivable_entry/ JSON Schema: https://docs.demiton.io/registers/receivable_entry/v2.json ## retention_position - Retention position Holds: Retention currently withheld on a job, and its status. Each record is: State Status: Available Domain: Contracts Data: tenant Required fields: project_ref, retention_held Filled today by: Business Central, Xero Contract: https://docs.demiton.io/registers/retention_position/ JSON Schema: https://docs.demiton.io/registers/retention_position/v2.json ## rework_risk_verdict - Rework risk verdict Data: tenant Required fields: kind, detail, item_key, last_seen, first_seen, occurrences, line_cost_aud Contract: https://docs.demiton.io/registers/rework_risk_verdict/ JSON Schema: https://docs.demiton.io/registers/rework_risk_verdict/v1.json ## rfi - Rfi Holds: Requests for information, with status, response and cost or schedule impact. Status: Planned Domain: Projects Data: tenant Required fields: status, project, subject, external_id Contract: https://docs.demiton.io/registers/rfi/ JSON Schema: https://docs.demiton.io/registers/rfi/v1.json ## safety_incident - Safety incident Holds: Safety incidents and near misses on site. Each record is: Event Status: Available Domain: Safety Data: tenant Required fields: form_id, form_title, external_id, occurred_at, financial_period Filled today by: Assignar Contract: https://docs.demiton.io/registers/safety_incident/ JSON Schema: https://docs.demiton.io/registers/safety_incident/v2.json ## safety_ncr - Safety ncr Holds: Non-conformance reports raised on site, for quality and safety. Each record is: Event Status: Available Domain: Safety Data: tenant Required fields: form_id, form_title, external_id, occurred_at, financial_period Filled today by: Assignar Contract: https://docs.demiton.io/registers/safety_ncr/ JSON Schema: https://docs.demiton.io/registers/safety_ncr/v2.json ## site_activity - Site activity Holds: Daily site activity: crew, plant and progress. Each record is: Event Status: Declared Domain: Projects Data: tenant Required fields: project, occurred_on Filled today by: Assignar Contract: https://docs.demiton.io/registers/site_activity/ JSON Schema: https://docs.demiton.io/registers/site_activity/v1.json ## site_bore_reference - Site bore reference Holds: Borehole records referenced for a site. Each record is: State Status: Declared Domain: Projects Data: tenant Required fields: source, content, project, radius_m, horizontal_datum, bores_within_radius, nearest_bore_distance_m, nearest_bore_rock_depth_m, logged_bores_within_radius Contract: https://docs.demiton.io/registers/site_bore_reference/ JSON Schema: https://docs.demiton.io/registers/site_bore_reference/v2.json ## site_diary - Site diary Holds: Daily site diaries: delays, weather, productivity, variations. Each record is: Event Status: Available Domain: Projects Data: tenant Required fields: content, external_id, occurred_on Filled today by: Assignar Contract: https://docs.demiton.io/registers/site_diary/ JSON Schema: https://docs.demiton.io/registers/site_diary/v1.json ## site_geology - Site geology Holds: Ground conditions and geology recorded for a site. Each record is: State Status: Declared Domain: Projects Data: tenant Required fields: content, project, map_source, formation_name Contract: https://docs.demiton.io/registers/site_geology/ JSON Schema: https://docs.demiton.io/registers/site_geology/v1.json ## site_inspection - Site inspection Holds: Vehicle and plant inspection checklists. Each record is: Event Status: Available Domain: Safety Data: tenant Required fields: asset, form_title, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/site_inspection/ JSON Schema: https://docs.demiton.io/registers/site_inspection/v1.json ## site_requisitions - Site requisitions Holds: Site requisitions for materials, plant or resources, by worker and project. Each record is: Event Status: Available Domain: Projects Data: tenant Required fields: worker, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/site_requisitions/ JSON Schema: https://docs.demiton.io/registers/site_requisitions/v1.json ## sor_outturn_comparison - Sor outturn comparison Data: tenant Contract: https://docs.demiton.io/registers/sor_outturn_comparison/ JSON Schema: https://docs.demiton.io/registers/sor_outturn_comparison/v1.json ## sor_verification - Sor verification Holds: A client's schedule of rates checked against the tender drawings by independent measurement. Each record is: State Status: Available Domain: Contracts Data: tenant Required fields: status, summary, findings, line_items, agent_run_id, review_state, opportunity_ref, findings[].title, line_items[].uom, pricing_document, findings[].detail, findings[].severity, line_items[].sor_qty, line_items[].verdict, line_items[].item_ref, line_items[].derivations, line_items[].description, line_items[].variance_pct, line_items[].derivations[].unit, line_items[].derivations[].value, line_items[].derivations[].method, line_items[].derivations[].caveats, line_items[].verification_strength, line_items[].derivations[].citation, line_items[].derivations[].confidence, line_items[].derivations[].evidence_url Contract: https://docs.demiton.io/registers/sor_verification/ JSON Schema: https://docs.demiton.io/registers/sor_verification/v1.json ## sor_verification_tendered - Sor verification tendered Holds: The same schedule-of-rates check run on tendered jobs, compared against your own submitted rates. Each record is: State Status: Available Domain: Contracts Data: tenant Required fields: status, summary, line_items, agent_run_id, review_state, opportunity_ref, subject_entity_id, line_items[].sor_qty, line_items[].verdict, line_items[].item_ref Contract: https://docs.demiton.io/registers/sor_verification_tendered/ JSON Schema: https://docs.demiton.io/registers/sor_verification_tendered/v1.json ## speeding_event - Speeding event Holds: Speeding events from telematics. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: asset_id, position, speed_kmh, duration_s, external_id, occurred_at, position_datum, speed_offset_kmh, speed_threshold_kmh Filled today by: Navman Contract: https://docs.demiton.io/registers/speeding_event/ JSON Schema: https://docs.demiton.io/registers/speeding_event/v1.json ## subcontract - Subcontract Holds: The subcontract itself: the instrument, not the subcontractor or the claim. Status: Planned Domain: Contracts Data: tenant Required fields: status, project, external_id, subcontractor Contract: https://docs.demiton.io/registers/subcontract/ JSON Schema: https://docs.demiton.io/registers/subcontract/v2.json ## subcontractor_list - Subcontractor list Holds: Subcontractors engaged on your projects. Each record is: State Status: Available Domain: Counterparties Data: tenant Required fields: name, canonical_key, counterparty_role, source_external_id, subcontractor_entity_id Filled today by: Assignar Contract: https://docs.demiton.io/registers/subcontractor_list/ JSON Schema: https://docs.demiton.io/registers/subcontractor_list/v1.json ## superannuation_fund - Superannuation fund Holds: Superannuation funds and fund products employees are paid into. Status: Planned Domain: Payroll Data: tenant Required fields: name, external_id Contract: https://docs.demiton.io/registers/superannuation_fund/ JSON Schema: https://docs.demiton.io/registers/superannuation_fund/v1.json ## survey_control - Survey control Holds: Survey control marks in GDA2020 / MGA2020. Status: Planned Domain: Projects Data: tenant Required fields: mark_id, project Contract: https://docs.demiton.io/registers/survey_control/ JSON Schema: https://docs.demiton.io/registers/survey_control/v1.json ## tender_baseline - Tender baseline Data: tenant Contract: https://docs.demiton.io/registers/tender_baseline/ JSON Schema: https://docs.demiton.io/registers/tender_baseline/v1.json ## tender_baseline_active - Tender baseline active Holds: Which tender baseline is the current reference for a project. Each record is: State Status: Declared Domain: Opportunities Data: tenant Required fields: active_version_id Contract: https://docs.demiton.io/registers/tender_baseline_active/ JSON Schema: https://docs.demiton.io/registers/tender_baseline_active/v1.json ## tender_brief - Tender brief Holds: A cited brief on a tender: everything known about it and how you are placed to pursue it. Each record is: State Status: Declared Domain: Opportunities Data: tenant Required fields: status, headline, sections, briefed_at, review_state, data_coverage, sections[].key, citations[].ref, citations[].kind, open_question_count, sections[].markdown, sections[].citations, source_opportunity_ref, data_coverage.conduits_empty, data_coverage.documents_read, data_coverage.conduits_consulted Contract: https://docs.demiton.io/registers/tender_brief/ JSON Schema: https://docs.demiton.io/registers/tender_brief/v2.json ## tender_column_mapping - Tender column mapping Data: tenant Contract: https://docs.demiton.io/registers/tender_column_mapping/ JSON Schema: https://docs.demiton.io/registers/tender_column_mapping/v1.json ## tender_incoming - Tender incoming Holds: Client-issued documents for a tender you are estimating: brief, scope, pricing schedule. Each record is: State Status: Available Domain: Opportunities Data: tenant Required fields: title, client, work_types, closing_date, scope_summary, source_document_path, source_document_file_name Contract: https://docs.demiton.io/registers/tender_incoming/ JSON Schema: https://docs.demiton.io/registers/tender_incoming/v2.json ## tender_outcome - Tender outcome Data: tenant Contract: https://docs.demiton.io/registers/tender_outcome/ JSON Schema: https://docs.demiton.io/registers/tender_outcome/v1.json ## tender_post_mortem - Tender post mortem Data: tenant Contract: https://docs.demiton.io/registers/tender_post_mortem/ JSON Schema: https://docs.demiton.io/registers/tender_post_mortem/v1.json ## tender_register_upload - Tender register upload Data: tenant Contract: https://docs.demiton.io/registers/tender_register_upload/ JSON Schema: https://docs.demiton.io/registers/tender_register_upload/v1.json ## tender_source_link - Tender source link Data: tenant Contract: https://docs.demiton.io/registers/tender_source_link/ JSON Schema: https://docs.demiton.io/registers/tender_source_link/v1.json ## tender_source_link:crm - Tender source link (crm) Data: tenant Contract: https://docs.demiton.io/registers/tender_source_link--crm/ JSON Schema: https://docs.demiton.io/registers/tender_source_link--crm/v1.json ## tender_source_link:documents - Tender source link (documents) Data: tenant Contract: https://docs.demiton.io/registers/tender_source_link--documents/ JSON Schema: https://docs.demiton.io/registers/tender_source_link--documents/v1.json ## tender_submission - Tender submission Holds: Tenders you have already submitted: scope, pricing and outcome. Each record is: State Status: Available Domain: Opportunities Data: tenant Required fields: outcome, win_themes, methodology_ref, submitted_amount, source_document_path, source_document_file_name Contract: https://docs.demiton.io/registers/tender_submission/ JSON Schema: https://docs.demiton.io/registers/tender_submission/v2.json ## tendered_budget - Tendered budget Holds: Tendered budget lines across all cost categories, from the winning estimate. Each record is: State Status: Available Domain: Opportunities Data: tenant Required fields: category, coverage, sections, entity_id, total_aud, line_count, source_format, grand_total_aud, financial_period Contract: https://docs.demiton.io/registers/tendered_budget/ JSON Schema: https://docs.demiton.io/registers/tendered_budget/v1.json ## tendered_rate_observation - Tendered rate observation Holds: One priced line from a tender you submitted: item, unit, rate and quantity. Each record is: Event Status: Available Domain: Opportunities Data: tenant Required fields: rate, citation, work_item, unit_normalized Contract: https://docs.demiton.io/registers/tendered_rate_observation/ JSON Schema: https://docs.demiton.io/registers/tendered_rate_observation/v1.json ## timesheet_code_list - Timesheet code list Holds: Timesheet and pay codes: award codes, allowances and the like. Each record is: State Status: Available Domain: Payroll Data: tenant Required fields: code, name, source_external_id, timesheet_code_entity_id Filled today by: Assignar Contract: https://docs.demiton.io/registers/timesheet_code_list/ JSON Schema: https://docs.demiton.io/registers/timesheet_code_list/v1.json ## timesheet_entry - Timesheet entry Holds: Timesheet submissions, with hours by date and pay category. Each record is: Event Status: Available Domain: Payroll Data: tenant Required fields: hours, worker, occurred_at, financial_period Filled today by: Assignar, Employment Hero Payroll Contract: https://docs.demiton.io/registers/timesheet_entry/ JSON Schema: https://docs.demiton.io/registers/timesheet_entry/v1.json ## toolbox_talk - Toolbox talk Holds: Toolbox talks and pre-work safety meetings. Each record is: Event Status: Available Domain: Safety Data: tenant Required fields: title, project, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/toolbox_talk/ JSON Schema: https://docs.demiton.io/registers/toolbox_talk/v1.json ## traffic_management_plan - Traffic management plan Holds: Traffic management plans (AS 1742.3). Status: Planned Domain: Projects Data: tenant Required fields: project, plan_kind, plan_reference Contract: https://docs.demiton.io/registers/traffic_management_plan/ JSON Schema: https://docs.demiton.io/registers/traffic_management_plan/v2.json ## training_records - Training records Holds: Training logs and training requests, by worker. Each record is: Event Status: Available Domain: Workforce Data: tenant Required fields: worker, external_id, occurred_at, training_kind, training_title Filled today by: Assignar Contract: https://docs.demiton.io/registers/training_records/ JSON Schema: https://docs.demiton.io/registers/training_records/v1.json ## trial_balance - Trial balance Holds: Debit and credit balance per general ledger account. Each record is: Event Status: Available Domain: Financials Data: tenant Required fields: balance, net_change, external_id, snapshot_at, account_number, legal_entity_id Filled today by: Business Central, Dynamics 365 Finance & Operations, Xero Contract: https://docs.demiton.io/registers/trial_balance/ JSON Schema: https://docs.demiton.io/registers/trial_balance/v2.json ## user_list - User list Holds: Users in your identity directory and operational systems. Each record is: State Status: Available Domain: Counterparties Data: tenant Required fields: display_name, worker_entity_id, source_external_id Filled today by: Assignar, Microsoft Entra ID, Employment Hero Payroll, monday.com Contract: https://docs.demiton.io/registers/user_list/ JSON Schema: https://docs.demiton.io/registers/user_list/v1.json ## utility_location - Utility location Holds: Subsurface utilities on a site, with their AS 5488 quality level. Status: Planned Domain: Projects Data: tenant Required fields: project, utility_type, quality_level, quality_level_scheme Contract: https://docs.demiton.io/registers/utility_location/ JSON Schema: https://docs.demiton.io/registers/utility_location/v1.json ## variations - Variations Holds: Approved contract variations: scope change, value and approval status. Each record is: State Status: Declared Domain: Contracts Data: tenant Required fields: pca_ref, doc_kind, line_items, _source_path, _source_file_name, acceptance_status Contract: https://docs.demiton.io/registers/variations/ JSON Schema: https://docs.demiton.io/registers/variations/v1.json ## vehicle_list - Vehicle list Holds: Vehicles registered in your telematics system. Each record is: State Status: Available Domain: Assets Data: tenant Required fields: vin, asset, label, occurred_at, source_record_id Filled today by: Navman, Trimble Contract: https://docs.demiton.io/registers/vehicle_list/ JSON Schema: https://docs.demiton.io/registers/vehicle_list/v2.json ## vehicle_location - Vehicle location Holds: Last-known GPS position of each vehicle. Each record is: Event Status: Available Domain: Assets Data: tenant Required fields: asset, occurred_at Filled today by: Navman, Trimble Contract: https://docs.demiton.io/registers/vehicle_location/ JSON Schema: https://docs.demiton.io/registers/vehicle_location/v1.json ## vendor_list - Vendor list Holds: Vendors and suppliers registered in your ERP. Each record is: State Status: Available Domain: Counterparties Data: tenant Required fields: vendor_entity_id Filled today by: Business Central, Dynamics 365 Finance & Operations, HubSpot Contract: https://docs.demiton.io/registers/vendor_list/ JSON Schema: https://docs.demiton.io/registers/vendor_list/v2.json ## work_activity_categories - Work activity categories Holds: Job tasks normalised to a standard work activity taxonomy: piling, anchors and so on. Each record is: State Status: Available Domain: Financials Data: tenant Required fields: label, canonical_key, work_activity_id, source_external_id Filled today by: Business Central Contract: https://docs.demiton.io/registers/work_activity_categories/ JSON Schema: https://docs.demiton.io/registers/work_activity_categories/v1.json ## worker_qualification - Worker qualification Holds: Competencies, certificates and licences held by workers: rigging, EWP, first aid and so on. Each record is: Event Status: Available Domain: Workforce Data: tenant Required fields: worker, competency, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/worker_qualification/ JSON Schema: https://docs.demiton.io/registers/worker_qualification/v1.json ## worker_training_session - Worker training session Data: tenant Required fields: worker, external_id, occurred_at Filled today by: Assignar Contract: https://docs.demiton.io/registers/worker_training_session/ JSON Schema: https://docs.demiton.io/registers/worker_training_session/v1.json