Specification

The OpenSAFR Specification

Tracks SAFR whitepaper 1.0 (July 2026)

The SAFR whitepaper defines what should hold for every agent action: it is declared, its agent is verified, it is assessed against controls, it receives one of four outcomes, and it is recorded. It deliberately leaves the form of implementation to each institution.

That flexibility has a cost. If every institution designs its own envelope and log format, the fragmentation problem the whitepaper describes simply moves one layer down. OpenSAFR's first priority is a shared, language-agnostic schema for the Governance Envelope and the Audit Log record, with a conformance suite to check implementations against it. The disposition engine is where institutions differentiate. The record format is where they should agree.

Artefacts

SchemaStatus: Draft

Audit Record Schema

Record format for every disposition, including hash-chain and controls-version fields.

ConformanceStatus: Planned

Conformance Suite

Test vectors and runner for schema validity and disposition behaviour.

SDK · PythonStatus: Planned

opensafr-python

Emit envelopes, validate records, verify chains.

SDK · TypeScriptStatus: Planned

opensafr-ts

TypeScript equivalent for agent platforms and gateways.

Reference implementationStatus: Prototype

Reference Gate

Disposition engine with tiered policy pack, from the SingHacks build.

Working systems built on SAFR concepts: Implementations →

Design principles

  • Paper-faithful. Every schema element maps to a concept in the whitepaper, or is explicitly marked as an extension.
  • Language-agnostic. The spec lives in its own repository. SDKs live in separate repositories and follow the spec.
  • Deterministic core, labelled judgement. Fields record whether a control was deterministic or involved probabilistic or semantic assessment, as the whitepaper distinguishes.
  • Per-action by construction. One envelope, one disposition, one record. No workflow-level authorisation fields.
  • Tamper-evident by default. Records carry hash-chain fields so integrity can be verified independently.
  • Versioned controls. Every record references the version of the controls in force at decision time, so past decisions can be reconstructed exactly.
  • Extensible, not forkable. Institutions add fields through a namespaced extension mechanism rather than modifying core fields.

Versioning and governance

  • Semantic versioning. Pre-1.0 releases may break compatibility.
  • Changes proposed as RFCs in the spec repository, with a comment period before merging.
  • Each release notes which whitepaper version it tracks.

[TODO: state the licences once decided (e.g. CC BY 4.0 for the spec, Apache 2.0 for code).]

Comment or contribute

Reviewing the draft schema is the most valuable contribution right now. Open issues, comment on RFCs, or tell us where the envelope or record format doesn't fit your use case. See Get involved.

[TODO: link GitHub discussions and issues once the spec repository is public.]

OpenSAFR is an independent, unofficial open reference implementation. It is not affiliated with or endorsed by the Monetary Authority of Singapore, BuildFin.ai, or any organisation that contributed to the SAFR whitepaper. SAFR is an industry reference approach, not regulatory guidance. Nothing on this site is legal, regulatory, or financial advice.