Prove an obligation.

Pick a real framework obligation, mark the evidence you actually hold, and watch it resolve two different ways: coverage — is it mapped to controls at all — and evidence — is it satisfied by what you have. mapped ≠ satisfied, made executable in your browser.

Every obligation, addressing control, and required-evidence item below is the live Evidence Proof Map (real corpus data). Coverage is static — it comes from the published map. Evidence is computed here from the boxes you check; the platform's composeObligationProof() runs the same shape against real signed evidence artifacts. Nothing is fabricated — checking a box asserts you hold that artifact, it does not create one. Recompute the corpus hashes →

Loading the Evidence Proof Map…

Worked example

A real obligation from the Evidence Proof Map, resolved statically here so it reads without scripts — the interactive version above computes the evidence side from your own answers.

EU AI Act · Art. 5(1)(a) — Prohibited AI — subliminal manipulation

AI systems that deploy subliminal techniques beyond a person's consciousness or purposefully manipulative or deceptive techniques with the objective to materially distort the behaviour of a person or a group of persons are prohibited.

Coverage: direct — mapped to 4 addressing controls. This is static, from the published proof map; it never depends on your evidence.

EF-05 · EU AI Act Prohibited Practices Governance (Art. 5)

fit: directbasis: anchoredblocks-deployment

Every AI system developed, deployed, or procured by the organization must have an Art. 5 screening record confirming evaluation against the current Prohibited Practices Register before intake resources were allocated. Any system that…

Evidence you would need to produce

  • prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art.…
  • art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match /…

HI-02 · Human Dignity and Autonomy Preservation

fit: directbasis: anchoredblocks-deployment

No AI system may be deployed or continue operating if a red-team evaluation has identified unresolved high-severity dignity violations or autonomy-undermining patterns within the control's defined remediation SLA. All production AI systems…

Evidence you would need to produce

  • red_team_evaluation_report per AI system, conducted within the prior 90 days, scored against the dignity and autonomy rubric with all findings categorized by severity and tracked to…
  • prohibited_patterns_registry document listing current prohibited patterns with definitions, illustrative examples, and most recent review date confirming currency within 18 months

HI-06 · Consent and Agency Preservation for AI Interactions

fit: directbasis: anchoredrequires-review

All AI-mediated interactions must be preceded by plain-language disclosure of the AI's nature, capability category, data use, and consequential outputs; consent records must be version-tagged to the capability state at the time of consent;…

Evidence you would need to produce

  • consent_record_export with fields for user_id, consent_timestamp, capability_version_tag, consent_granularity_tier, and revocation_status for every consented user, with no records lacking a…
  • disclosure_readability_assessment_report showing Flesch-Kincaid reading ease score at or above 60 for all pre-interaction disclosure content, assessed after each material capability update

GV-07 · Protect humans from being deceived by an agent

fit: unratedbasis: unratedrequires-review

All agent-generated content shown to human approvers or end users is clearly labeled as AI-generated and includes independent, system-sourced facts about the action being approved; the approval channel cryptographically prevents agent…

Evidence you would need to produce

  • approval_ui_design_artifact showing the agent-output label and an independent fact panel (resource identifiers, current auth scope, prior action history) displayed alongside any…
  • impersonation_block_log recording instances where an agent attempted to assert a named human identity or forge an on-behalf-of header, and the system's rejection response

mapped ≠ satisfied. The controls above are mapped to this obligation (coverage). Whether they are satisfied depends on evidence you actually hold — that is the second verdict. See a whole action resolved on the wire →