Machine-consumable compliance infrastructure

Compliance infrastructure starts below the form.

Machines cannot build reliable compliance systems on PDFs, field names or vendor labels alone.

They need source-bound units they can inspect, combine, hash, challenge and trace. ActProof calls those units source atoms.

See atom combinations →Open atoms NDJSON →Open page JSON →Atom lifecycle →

Recorded atoms26

Used by fields25

Gap signal1 unused

Current rolemachine substrate

01 / The machine-consumption problem

Compliance systems keep starting too high in the stack.

A bank may already have GRC tooling, incident workflows, evidence tasks, dashboards and internal forms. That does not mean the source layer is controlled. A workflow can move a report through departments without proving why each field exists or which source fragment supports it.

ActProof attacks the unoccupied layer: below GRC workflow, above raw law, at the source-bound unit of meaning.

What machines struggle with

full legal acts are too large and ambiguous for precise field operations
field names are local labels, not authority
vendor schemas are private and often unmapped to public source
legal interpretations arrive too late in the chain for safe automation

INPUTS MACHINES ARE GIVEN PDF regulation too broad field name too weak vendor schema too private workflow dashboard too late SOURCE ATOM small · locatable · hashable · composable

Quick read

Seven reasons atoms work better for machines.

Before the detailed matrix, this is the practical point. Atoms give machines smaller, source-bound, recomputable and composable records they can use without pretending a field name or dashboard is the source of truth.

Smaller than regulationsA machine can consume one source fragment instead of a whole legal act.
Source-boundEach atom points back to an official instrument and locator before interpretation starts.
RecomputableWhere text is captured, the official text hash can be checked again.
ComposableA field can combine obligation, template cell, glossary, timing and classification atoms.
Expose missingnessCoverage can show recorded source atoms not yet represented by fields.
Improve schema mappingBanks and vendors can map by source basis, not by name similarity alone.
Make agents saferAn agent gets a bounded proof object with provenance, dependencies and non-claims before it acts.

02 / Why atoms are better machine elements

Atoms give machines bounded legal-source objects, not loose compliance prose.

Each atom carries source identity, legal locator, role, weight, maturity status, hash information and dependencies. That makes it safer for software, agents and auditors to consume than a paragraph copied into a presentation or a private field label inside a vendor tool.

Source identityCELEX, ELI, instrument, authority

A machine can tell which official source is being referenced before interpretation begins.

Exact locatorarticle, paragraph, annex, template cell

The atom has an addressable legal or template location, not just a topic label.

Text integrityofficial_text_sha256 where captured

Text-captured atoms can be recomputed under a documented normalization rule.

Meaning boundaryatom type, role, normative weight

A template field, glossary entry and base obligation are not treated as the same kind of thing.

Dependency graphwhich fields consume this atom

When an atom changes, downstream fields, mappings and overlays can be reviewed.

Missingness signalunused atoms and coverage gaps

The system can show recorded source material that is not yet represented by a field.

Stable retrievalsmall records, stable IDs, line-by-line feeds

Agents can cache, compare and re-fetch atom records without loading a full regulation.

Provenance trailsource → capture → hash → dependency

Each atom can carry the evidence chain a tool or reviewer needs before acting.

Change impacthash and maturity changes trigger review

A changed atom can be traced upward into fields, mappings, overlays and reports.

Safe agent useboundaries, non-claims and next-step guidance

Agents can know what they may explain, what they must not claim, and which endpoint to call next.

Agents are looking for proof

For agentic systems, context is not enough. They need evidence they can cite, provenance they can trace and boundaries they can obey.

Atoms are designed to give agents compact proof-carrying records: official source identity, locator, maturity state, text hash where captured, dependencies and explicit non-claims. That lets an agent ground an answer, stop early, recover from uncertainty and avoid turning a compliance hint into a legal conclusion.

This matters most when an agent acts rather than answers. As agents move from recommendation into initiating workflows, the requirement shifts from a final citation to provenance that can be checked at the level of the specific field and source it depends on, before the action runs. An atom is that check: an agent can recompute official_text_sha256 and confirm it is standing on the exact official provision a field rests on, then proceed or stop. Proof before the action, not a log after it.

03 / Combination is the power

One atom rarely equals one compliance requirement.

A report field is usually a composition: base obligation + template cell + glossary/context + classification or timing rule.

This is where ActProof becomes more than a source inventory. It builds derivations from atoms, and those derivations let machines reason about fields without treating a field name as authority.

Choose a field composition

Loading…

required—

interpretive_load—

binding—

04 / Where this sits next to OSCAL and Rules-as-Code

Atoms anchor the source beneath structured compliance systems.

OSCAL, Rules-as-Code and policy-as-code structure controls, requirements, assessments and executable compliance logic. ActProof atoms sit one layer earlier: they make the official legal or template fragment itself machine-consumable and verifiable.

The distinction is simple: controls and rules are structured interpretations. Atoms are source anchors. A control, rule, assessment or agent workflow can point to an atom when it needs to show what official material it rests on.

LAYER              PRIMARY OBJECT              SOURCE ROLE
Policy-as-code     executable policy logic      should cite source
Rules-as-Code      machine-readable rule        should cite source
OSCAL              controls and assessments     can reference supporting resources
ActProof atom      official source fragment     source anchor + locator + hash

The point

ActProof does not replace OSCAL. It gives compliance systems a source object to point at.

The rule remains the interpretation. The atom remains the proof object it must answer to.

05 / Why this becomes infrastructure

The library is not built on a form. It is built on a source graph.

Once atoms are the bedrock, every upper layer inherits source discipline. This is why strengthening atoms strengthens everything else.

01Source atoms

Official fragment identity and locator.

02Derivations

Field draws from atoms with review status.

03Profile view

Renderable public projection.

04Schema mapping

External fields become review candidates.

05Bank overlay

Bank records its local decisions.

06Impact report

Changed atoms/fields trigger re-review.

07POC pack

Local review bundle.

08Internal API

Private execution surface.

06 / Agents and bots

Agents prefer proof-carrying, small, explicit, recoverable context.

An atom record tells an agent what source fragment it is looking at, whether text is captured, which fields depend on it, what can be safely explained, and what must not be claimed. This is far better than forcing an agent to infer meaning from a long legal page or a marketing paragraph.

In regulated workflows, the useful agent input is not just text. It is a source-bound evidence object with provenance, dependency edges, maturity status and machine-readable limits.

{"record_type":"source_atom",
 "source_atom_id":"src.eu.dora...annexI.entity_lei",
 "celex":"32025R0302",
 "locator":{"annex":"I","field":"Legal entity identifier"},
 "official_text_sha256":"sha256:... or null",
 "used_by_fields":["entity_legal_identifier"],
 "agent_guidance":{"do_not_claim":"compliance certification"}}

Machine surfaces

Atoms NDJSON Atoms JSON Profile stream Agent card llms.txt

The page is human-readable, but the same logic is exposed as JSON and NDJSON so crawlers, agents and internal tools can consume it directly.

07 / Visible maturity

ActProof does not hide the atom maturity state.

Some atoms are only locator-bound. Some are identity-hashed. Some are text-captured and official-text-hashed. The maturity state is part of the object so a bank, auditor or agent does not mistake a provisional atom for a fully reviewed source-text object.

M1Locator-bound

CELEX/ELI and structured locator captured.

M2Identity-hashed

Atom identity hash recomputes.

M3Rule-bound

Extraction boundary rule documented.

M4Text-captured

Official excerpt is present.

M5Text-hashed

official_text_sha256 recomputes.

M6Maintainer-reviewed

Locator/text/role reviewed internally.

M7Independent review

External review possible later.

08 / Consume the substrate

Build on the atom layer without pretending it is legal certification.

ActProof’s infrastructure claim is deliberately bounded: source fragments become machine-consumable elements for mapping, pre-validation, review and change control. They do not become legal advice or supervisory approval.

Use atoms for

source-grounded field derivations
agent-readable compliance context
schema mapping evidence
bank overlay review decisions
source-atom coverage and missingness signals
change impact review when profiles evolve

Do not use atoms as

legal advice
proof of compliance
supervisory acceptance
a claim that a profile is exhaustive
a substitute for bank SME or legal review

Give machines better elements than PDFs and field labels.

Inspect the atom lifecycle, stream the atom feed, or open the DORA profile that consumes these source-bound units.

Stream atoms →Atom lifecycle →Live DORA profile →Bank demo →