Obligations Atlas

Tests Licence: Apache 2.0

The Atlas sets out AI governance obligations by jurisdiction, maps them to standardised AI use cases (UC1 to UC10), and tags each by the tier of its source:

• Binding: law or prudential standard in force;
• Expected: regulator expectation, guidance or recognised standard;
• Anticipated: made but not yet in force, under consultation, or a pending bill.

It is built for AI, technology and regulatory lawyers in external counsel firms. It serves the same records three ways: a web app, a REST API and an MCP server.

Records state what sources say and how they are classified. They are not legal advice and do not say what the law requires of any particular client; counsel decides what applies.

How it fits together

flowchart LR
  R["Research and update agent"] -- "change proposals<br/>(governance interface 1.0)" --> F["Reasoning Fabric<br/>(closed)"]
  V["Named reviewer<br/>(reasoning-fabric-app /admin/connector)"] -- "review decisions" --> F
  F -- "snapshot: governed records<br/>+ provenance" --> A["Atlas<br/>web app, REST API, MCP"]
  M["Triodian Metamodel<br/>(open schemas, policy)"] -.-> F
  M -.-> A

• Data model: the open Triodian Metamodel, vendored and pinned in vendor/triodian-metamodel (npm run sync-metamodel). Records are Obligations, External Organizations, Use Cases, Data Flows (monitored sources) and Triggers (instrument changes).
• Governance: every record goes through the Reasoning Fabric connector under the AI Obligations Atlas dataset policy (kept in reasoning_fabric policies/, and served in every snapshot and at /api/v1/policy). Nothing that sets a status, a date or a tier is published without a named approver. Every record carries a hash-chained provenance trail.
• Data in this repo:
  • data/research/ holds the research: the seed of 27 October 2026, and later rounds, each with its brief (for example BRIEF-2026-11-general-and-2026.md).
  • data/seed/build-seed.mjs turned the seed research into connector proposals. data/seed/build-submission.mjs <research file> does the same for each later round, and writes the reviewer's notes on records already held beside it.
  • The update agent submits a round with node scripts/connector.js submit <file> --url … --token … in reasoning_fabric. Every proposal goes to the review queue or becomes a lead; nothing is published without a named reviewer.
  • data/snapshot/ holds what the Fabric returns. ai-obligations-atlas.json has the published records only. ai-obligations-atlas.preview.json adds records still waiting for review, marked pendingReview.

Run it

npm ci
npm run dev                     # http://localhost:8787, published records only
ATLAS_PREVIEW=true npm run dev  # include records waiting for review, with a preview banner
npm test                        # API, MCP, matter brief, language rules, provenance, keys, rate limits
npm run data:check              # every snapshot record against its schema, language rules and hashes

Deploy (Cloudflare Workers)

Workers Builds deploys main. wrangler.jsonc serves public/ as static assets, and runs /api/*, /mcp and /healthz in src/handler.js. One Worker serves both domains:

Domain	Shows
obligations-atlas.triodian.com	Published records only. With the FABRIC_READ_TOKEN secret set, they are read live from the Reasoning Fabric (FABRIC_URL) and cached for ATLAS_CACHE_SECONDS. Without it, or if the Fabric cannot be reached, the bundled data/snapshot/ai-obligations-atlas.json is used
obligations-atlas-test.triodian.com (ATLAS_PREVIEW_HOSTS)	The bundled preview snapshot, including records waiting for review, under a preview banner

Attach both domains under Settings → Domains & Routes → Custom domain. Set the secrets under Settings → Variables and Secrets:

• FABRIC_READ_TOKEN: the read-only obligations-atlas governance token;
• ATLAS_API_KEYS: optional, [{"firm":"…","keySha256":"…","perMinute":600}].

Starting jurisdiction and regulated sector

The register and the matter brief open in the jurisdiction and regulated sector set by two variables in wrangler.jsonc: DEFAULT_JURISDICTION (AU or SG, default AU) and DEFAULT_SECTOR (a sector id such as AU-SUPERANNUATION, or empty for none). The installer sets both. Users can change either at any time from the register's filters or the brief's step 2, and the browser keeps their choice. The sectors come from the Metamodel's reference-data/regulated-sectors.json.

/healthz reports which data a domain is serving (fabric, bundled or bundled-preview), and the last error reading from the Fabric, if any.

Refresh the data

The reviewer approves in the review console. The live site then reads the approved records from the Fabric straight away.

The test site, and the live site's fallback, read the snapshots in data/snapshot/. To refresh them, run Actions → Refresh snapshots → Run workflow (it also runs every Monday). It fetches both snapshots from the Fabric, checks them with the data check and tests, and opens a pull request when they changed; merging it redeploys the sites. Opening the pull request needs "Allow GitHub Actions to create and approve pull requests" in the organisation's and the repository's Actions settings; without it, the job pushes the branch and its run summary links to open the pull request by hand. It uses the repository secret FABRIC_PREVIEW_TOKEN, a Fabric token with the read and preview scopes only, which can read records waiting for review but cannot submit, list or decide proposals.

To refresh by hand instead: FABRIC_PREVIEW_TOKEN=… node scripts/refresh-snapshots.mjs.

Interfaces

Channel	Calls
Web app	Register (query by tier, jurisdiction, entity, use case), record pages with provenance, use cases, changes, matter brief, API and MCP page
REST API	/api/v1/obligations, /obligations/{id}, /instruments, /changes?since=, /provenance/{ref}, /use-cases, /jurisdictions, /organizations, /policy, /solution-set, /solution-set/table, /openapi.json
MCP (Streamable HTTP at /mcp)	find_obligations, get_obligation, list_changes, explain_provenance

Free entry point (keyless tier). No key is needed for the REST API or the MCP server: each caller may make ATLAS_KEYLESS_PER_MINUTE requests a minute (60 by default) and reads the published records for Australia, Singapore and the international standards. Over the limit, the answer says when to retry and how a registered firm gets its own key and a higher limit. server.json lists the MCP server in the official MCP Registry (publish it with Actions → Publish to MCP Registry); docs/mcp-directories.md is the listing checklist.

Privacy.

• The web app downloads the whole public dataset once and filters it in the browser. The matter brief is built and kept there too, in the format in schemas/matter-brief.schema.json. No client facts reach the server unless the lawyer chooses to share a brief's scope with Triodian (see below). The matter label is never sent.
• The client portfolio keeps one brief per client in the browser (localStorage), matched by the matter label. Opening a client restores its choices and rebuilds the brief from the current records. Export portfolio downloads it as a file (triodian.atlasPortfolio/1) and Import portfolio merges such a file into another browser, keeping the newer copy of each client. None of this is sent to the server.
• public/_headers sets a Content-Security-Policy, so the page runs only its own scripts and connects only to its own API. An analytics beacon injected by Cloudflare can't load. Turn off Web Analytics for the Atlas hostnames in Cloudflare as well.

Firm registration and Bring in Triodian.

• A lawyer registers their firm from a matter brief or the Your firm page. The registration goes to the Reasoning Fabric's firm registry (/firms/v1), and a named reviewer approves it in the review console (/admin/firms).
• After approval, the browser collects the firm's API key once. From any matter brief, the lawyer can then bring in Triodian, with a note and, if they tick the box, the brief's scope.
• Keys issued this way are read from the Fabric with the snapshot and accepted by the REST API and MCP server.
• The Worker uses FABRIC_READ_TOKEN, which needs the firms.submit scope. /healthz reports how many firm keys are loaded.

Solution set and the routing table. src/core/solution-set.js holds one routing table: who the person is, what prompted them, the organisation's size, the two routes (financially regulated, or not) and what each engagement needs (people, documents, sessions). /api/v1/solution-set?role=&entityType=&sector=&jurisdiction=&size=&prompt= answers with the engagements in the order the work is done, why each fits, the person's usual role in each, and a link that opens the matter brief with the same scope (#/brief/j=…&e=…&s=…&u=…). The matter brief routes from the same table, so the two always agree; test/solution-set.test.js checks every combination of role, entity type and jurisdiction, with each prompt. The front door (Triodian Start, development plan phase 5) asks its questions from /api/v1/solution-set/table. Both are open without a key.

Use cases and "any AI use". A record mapped to every standardised use case (UC1–UC10) applies to any AI use, such as board accountability or risk management, rather than to particular uses. When a lawyer filters by use case, records specific to it come first and records that apply to any AI use follow. They appear in a folded group in the register and a separate list in the brief. The API marks them appliesToAnyAIUse; includeAnyUse=false leaves them out.

Coverage. The Atlas covers Australia, Singapore and international standards. Asking the API or MCP server about another jurisdiction (EU, GB, NZ, US) returns a coverage note saying it isn't covered yet, so an empty result isn't read as "no obligations".

Language rules. Every API and MCP response is checked against the dataset's language rules before it leaves. A response that fails the check is withheld.

Part of the Triodian AI governance apps

App	What it is for
AI Obligations Atlas	The AI governance obligations that apply by jurisdiction and use case, tiered by source, with a matter brief for counsel
AI Board Direction	A board sets its direction on AI: where to use it, what to rule out, what comes back to the board
AI Risk Appetite	A regulated entity settles its appetite for AI risk, for the board to approve
AI Use Assessment	The AI in a regulated entity's supply chain, measured against that appetite
AI Confidentiality Exposure Assessment	Where confidential information in one transaction can reach an external AI model
Installer and suite test	Puts the apps a client needs into a Cloudflare account, and tests them together

A matter brief routes by the client's entity type and sector: a financially regulated client to AI Risk Appetite, AI Use Assessment and AI Board Direction in connected mode; any other client to AI Board Direction in standalone mode and AI Confidentiality Exposure Assessment. With neither chosen, the use cases decide.

The engagement apps are separate, each with its own repo and database. Deployed together they share one sign-in and reach each other through Cloudflare service bindings.

Contributing

Contributions are welcome: see CONTRIBUTING.md and the code of conduct. Report security problems privately, as SECURITY.md describes, not as issues.

Supporting the project

Use it, review it, tell us you use it, or fund its upkeep: see SUPPORTING.md. Reviewers and organisations stay private unless they choose otherwise.

Licence

AI Obligations Atlas is open source under the Apache License, Version 2.0. Copyright 2026 Triodian Pty Ltd. Third-party components bundled with it keep their own licences; see NOTICE.