Risk → control → evidence matrix

Framework status

This matrix proposes an alignment method. It is neither a certification, an adopted standard nor evidence that a control works in every environment.

Its purpose is precise:

Connect a versioned external item to an internal failure mode, an authority, Core objects, an admission decision, a projection, an observation and a residual limitation.

The matrix operationalizes An external framework does not govern the canon.

1. Preconditions

No mapping should be activated before the following elements exist.

1.1 Identified Core

The system must use the five v0.1 objects:

• Entity;
• Claim;
• Term;
• Constraint;
• Precedence.

The matrix adds none.

1.2 Explicit authorities

Every mobilized object must have a source, authority scope and precedence rule. An official page is not automatically authoritative over every Claim class.

1.3 Admission rules

The decision to use an object in a situation must be separable from its canonical state. A Claim may be allowed in the Core but non-admissible in an interaction because a condition is not satisfied or cannot be evaluated.

1.4 Deterministic projection

The system must be able to produce a reproducible projection from authority, policy, intent and context.

1.5 Bounded observation

The observation protocol must distinguish observed restitution, deviation, conformance verdict and evidence limitation. The ledger does not attest to the internal state of a third-party model.

2. Unit of work

A matrix row does not correspond to an entire domain such as misinformation, transparency or multi-agent risks.

It corresponds to a smaller unit:

a failure mode
+ a Claim class
+ an application context
+ an expected control
+ observable evidence

Example:

Loss of a certification validity date when answering a compliance question in a specific jurisdiction.

That unit can be connected to a broader external risk. It remains precise enough to produce a condition, projection and test.

3. Minimum matrix structure

4. Step 1: capture the framework

The framework must be imported into an external namespace, never into the Core.

The capture manifest should contain:

framework:
  namespace: mit-airi
  source_url: https://airisk.mit.edu/risks
  snapshot_date: 2026-08-18
  imported_at: 2026-08-18T00:00:00Z
  license: CC-BY-4.0
  snapshot_sha256: "..."
  canonical: false

Illustrative dates must be replaced by actual import values. The hash applies to the stored artifact, not the URL.

The capture must state whether it represents:

• a published release;
• a dated export;
• a snapshot of a living database;
• a partial selection;
• a local adaptation.

An adaptation must preserve the source and distinguish original content from added interpretation.

5. Step 2: qualify the internal failure mode

The external label is not sufficient. The mapping must describe what can actually fail in the architecture being evaluated.

An acceptable failure mode specifies:

• the affected object;
• the unwanted transformation;
• the context in which it becomes consequential;
• the observable sign of deviation;
• what remains outside measurement.

Examples include:

• omission of an essential exclusion;
• generalization of a Claim beyond its scope;
• confusion between an official source and external evaluation;
• loss of a constraint during agent-to-agent transfer;
• answer production despite an unevaluated condition;
• probabilistic classification presented as declared fact.

6. Step 3: identify internal authority

Every failure mode must connect to a Claim class and to the authority able to govern it.

The matrix answers:

1. which source declares the information;
2. which Claim class falls within its authority;
3. which external sources may complement or challenge it;
4. which Precedence applies in a conflict;
5. which limits remain outside internal authority.

An organization may be authoritative over the date and scope of a certification it publishes. It cannot use that authority to certify its general reputation or invalidate independent criticism.

7. Step 4: connect the mapping to the five objects

A row creates no new object. It references existing objects or proposes, under review, a separate internal change.

Conceptual example:

core_refs:
  entity: entity:organization-x
  claims:
    - claim:certification-y-status
  terms:
    - term:certification-y
  constraints:
    - constraint:jurisdiction-required
    - constraint:validity-date-required
  precedence:
    - precedence:certification-registry-over-marketing-copy

If a Constraint is missing, the matrix may open a change proposal. It does not activate that Constraint itself.

8. Step 5: test applicability and admission

Applicability must consider at least:

• entity;
• intent or question class;
• audience;
• channel or agent;
• jurisdiction;
• time;
• sensitivity;
• possible decision type;
• positive conditions;
• non-applicability conditions.

A condition verdict may be:

• satisfied;
• not satisfied;
• indeterminate;
• unexecutable.

The last two states are neither permission nor conformance.

When a necessary condition is not satisfied, indeterminate or unexecutable, the conditional Claim is non-admissible for that projection. No average score can compensate for a missing necessary condition.

9. Step 6: compile the projection control

The control must not be written as a vague recommendation. It must declare verifiable behavior.

Examples:

• include validity date and jurisdiction whenever the certification Claim is delivered;
• prohibit generalization from a local observation to the entire organization;
• preserve source and projection identifiers through a multi-agent transfer;
• request clarification when two homonymous entities remain possible;
• produce non-response when the required authority source is absent;
• mark model-based classification as probabilistic and non-canonical.

A compiled policy may be represented as:

P = f(A, G, I, C)

The matrix contributes to G. Canonical authority remains in A.

10. Step 7: declare evidence before observation

Expected evidence must be defined before execution. Otherwise, the system can select the most favorable traces after the fact.

Depending on the control, evidence may include:

• external snapshot identifier and version;
• approved mapping;
• exact Core references;
• admission result;
• satisfied or unevaluated conditions;
• compiled projection and hash;
• package actually delivered;
• raw restitution;
• audit protocol;
• classified deviation;
• conformance verdict;
• ledger event;
• residual limitations.

Missing evidence must not be replaced by retrospective narrative.

11. Step 8: observe without mutating the Core

Restitution R is compared with projection P:

Δ = g(P, R)

The conformance result is then qualified under applicable governance:

Q = h(Δ, G)

Verdicts may distinguish:

• observed conformance;
• partial conformance;
• minor deviation;
• critical deviation;
• indeterminate result;
• unexecutable control;
• insufficient observation.

Those verdicts belong to the observation layer. They do not change the Core states allowed, conditional, forbidden or deprecated.

A repeated deviation may open a correction proposal. The change then follows the normal authority process.

12. Illustrative MIT AI Risk Repository example

The following rows illustrate the method. They are neither an official MIT mapping, certification nor active integration.

MIT mitigation categories may then qualify the control family, for example:

• 3.1 Testing & Auditing for the comparison protocol;
• 3.5 Post-deployment Monitoring for longitudinal observation;
• 4.1 System Documentation for architecture and limitation documentation;
• 4.2 Risk Disclosure for publishing risk and residual limitation;
• 4.3 Incident Reporting for critical deviations;
• 4.4 Governance Disclosure for decision rules and authorities.

This external qualification does not replace the internal control description.

13. Epistemic status of row data

Every value declares its epistemic provenance.

A model_classified item that later becomes human_reviewed retains the history of its initial classification. Review must not erase the path that produced the proposal.

14. Versioning and reversibility

Every activation links:

• the external snapshot SHA;
• matrix version;
• canonical-state SHA or identifier;
• compiled-policy version;
• runtime version;
• audit protocol;
• observation window.

When an external framework changes, three operations remain separate:

1. import a new snapshot;
2. calculate and review differences;
3. decide whether a mapping should be changed or reactivated.

The new state never automatically replaces the old one. The system must be able to replay an observation with the state active at delivery time.

15. Minimum fixtures

Before activation, the matrix must pass fixtures covering at least:

1. an external risk with no internal mapping: no projection effect;
2. a proposed but unapproved mapping: inactive;
3. a satisfied condition: projection remains within permission;
4. a condition not satisfied: Claim is non-admissible;
5. an indeterminate condition: no implicit permission;
6. contradictory Constraints at the same authority: compilation failure;
7. a lower layer attempting to widen permission: rejected;
8. unreviewed model classification: no Core change;
9. updated external snapshot: no automatic activation;
10. deviating restitution: ledger event without canonical mutation.

French and English versions must describe the same architecture. French remains the normative reference when the specification is stabilized; English is a translation, not a parallel architecture.

16. Acceptance criteria

A row is activatable only when:

• framework and snapshot are identified;
• licence and attribution are preserved;
• failure mode is precise;
• Claim class and authority are explicit;
• references to the five objects are valid;
• applicability includes negative conditions;
• the admission decision is deterministic;
• the control widens no permission;
• expected evidence is declared;
• residual limitation is explicit;
• fixtures pass;
• the mapping can be disabled without Core mutation.

If one necessary criterion is missing, the verdict is not activatable. A positive average does not compensate for an absent necessary condition.

17. Expected output

Applying the method should produce a self-contained decision package containing:

1. the external snapshot manifest;
2. the versioned mapping row;
3. references to canonical objects;
4. the authority decision;
5. applicability and admission rules;
6. compiled projection policy;
7. fixtures and results;
8. evidence contract;
9. residual limitation;
10. removal or replacement plan.

The package does not yet prove control effectiveness. It makes the control executable, testable and auditable.

Final rule

The matrix is not used to attach a risk label to a system. It maintains a responsibility chain:

external reference
→ qualification
→ internal authority
→ admission
→ control
→ projection
→ delivery
→ observation
→ bounded evidence

At no point does the external reference become the canon, and at no point does observation directly rewrite that canon.