Australian not-for-profit · ACN 699 651 771Open research · Open software · Public benefitPublic record

Framework alignment · Self-assessment

The same problem NIST names, approached as architecture.

The NIST AI Risk Management Framework sets out how organisations should govern, map, measure, and manage AI risk. This page shows where DET.io’s research architecture addresses each function, the level of evidence behind each point, and where the gaps are.

Reviewed 10 October 2026 · Not a NIST assessment, endorsement, or certification

See the four functionsRead the framework →

01 · How to read this mapping

Alignment of purpose, not proof of conformance.

This is DET.io’s own reading.

The category summaries are paraphrased. Matching a research design to a category shows that it addresses the same concern. It does not show that the risk is managed in practice, and no external party has reviewed this mapping.

Every point carries its evidence level.

Each entry is tagged with the same maturity ladder used across the research. Most points are published design. None has reached integration or independent validation.

Gaps are listed with each function.

Where the architecture does not address a category, or addresses it only on paper, the mapping says so rather than leaving the category out.

02 · The four core functions

Govern, map, measure, manage.

NIST AI RMF function

Govern

Policies, accountability, culture, engagement, and third-party risk across the organisation.

  • GOVERN 1 · Risk policies and processes are in place and followed
  • GOVERN 2 · Accountability structures assign authority and responsibility
  • GOVERN 4 · A culture that considers and communicates risk
  • GOVERN 6 · Third-party and supply-chain risks are covered
Where the architecture addresses it
  1. In forceSigned constitution: the public-benefit lock, reserved matters, and protected provisions bind the Foundation.
  2. DesignDSEMA two-house amendment with delay: no single body can change the rules agents operate under.
  3. DesignFoundation, network, and DSEMA authority are kept separate rather than conflated.

Gap. Network governance is stake-weighted and not yet tested for capture. Diversity and accessibility of oversight (GOVERN 3) are not yet addressed.

NIST AI RMF function

Map

Establish context, categorise the system, and characterise its impacts on people and society.

  • MAP 1 · Context is established and understood
  • MAP 3 · Capabilities, uses, benefits, and costs are understood
  • MAP 4 · Risks are mapped for every component, including third parties
  • MAP 5 · Impacts on individuals, communities, and society are characterised
Where the architecture addresses it
  1. DesignComponent roles and dependencies are mapped, with integrations marked as unbuilt.
  2. DesignOutside systems, scarcity, and capture are stated as boundaries of the claim.
  3. DesignPost-labour economics is treated as a stress scenario, not a prediction.

Gap. No characterisation yet of impacts on specific communities, such as people excluded by identity checks.

NIST AI RMF function

Measure

Identify metrics, evaluate trustworthiness, track risks over time, and check that measurement works.

  • MEASURE 1 · Appropriate methods and metrics are applied
  • MEASURE 2 · Systems are evaluated for trustworthy characteristics
  • MEASURE 3 · Risks are tracked over time
  • MEASURE 4 · Feedback on measurement is gathered
Where the architecture addresses it
  1. DesignA public maturity ladder: every claim cites the level it has reached.
  2. DesignSeven research questions, each with a named metric such as false rejection, correlated failure, or unauthorised execution.
  3. OperatingBosun execution ledgers and review gates produce operating evidence for engineering tasks.

Gap. The metrics are defined but not yet measured. No independent evaluation has been performed.

NIST AI RMF function

Manage

Prioritise and respond to risks, manage third parties, and document response and recovery.

  • MANAGE 1 · Mapped and measured risks are prioritised and treated
  • MANAGE 2 · Strategies maximise benefit and minimise harm
  • MANAGE 3 · Third-party risks are managed
  • MANAGE 4 · Response, recovery, and communication are documented and monitored
Where the architecture addresses it
  1. DesignPre-execution gates: authority, resource ceiling, and containment must each pass.
  2. SourceEscrow, attestation, and billing disputes give remedies against provider failure.
  3. OperatingBosun recovery: autofix, circuit breakers, and human escalation for failed agent work.

Gap. There is no published incident-response plan for a live network, because the network is not live.

03 · Characteristics of trustworthy AI

Seven characteristics. Two clear gaps.

The framework describes seven characteristics of trustworthy AI. The architecture says most about safety, security, accountability, and privacy. It says least about explainability and fairness.

NIST trustworthiness characteristics, the corresponding DET.io architecture feature, and its status.
CharacteristicArchitecture featureStatus
Valid and reliableReputation from recorded, held-out task performance; Bosun's reviewed-diff evidence.Designed · Bosun operating
SafeIndependent authority, budget, and containment gates before any agent action.Designed
Secure and resilientHardware attestation; many independent providers rather than one operator.In source
Accountable and transparentOpen source, a record linking mandate to settlement, and a signed constitution.Partly in source · record linkage designed
Explainable and interpretableDecisions are recorded and can be replayed. Model internals are not addressed.Gap
Privacy-enhancedOn-device processing and minimal, purpose-specific identity proofs.In source
Fair, with harmful bias managedFalse rejection and access barriers are named metrics for the identity research.Gap · not yet measured

04 · Evidence levels

What each badge means.

  1. Published design

    Specified in a public document. No implementation is claimed.

  2. In public source

    Code exists in an open repository. The network is not live and the code is not independently audited.

  3. In operating use

    Used in practice by its maintainers. Experimental, configuration-dependent, and not independently evaluated.

  4. Institutional instrument

    A signed legal instrument binding the Foundation. It does not bind networks, agents, or external systems.

  5. Integrated end to end

    Demonstrated working across components on one task. Not yet reached by any part of the architecture.

  6. Independently validated

    Evaluated by parties outside the Foundation under adversarial conditions. Not yet reached.

Read the research synthesis →Try the end-to-end taskDiscuss an evaluation