Behavioral Oracle
Independently verifiable AI governance
The oracle problem in AI governance
Self-certification has a structural flaw. The company that benefits from appearing compliant controls the reporting of its own compliance. This isn’t a matter of intent. It’s an architecture problem. When one entity simultaneously observes a system’s behavior, evaluates its own compliance, reports its status, and benefits financially from positive reporting, the regulator or market has no independent verification.
Existing solutions don’t resolve this. Third-party audits and regulatory inspections still originate from data the assessed entity provides. An oracle that pulls data from a platform API is pulling data the platform generated. The trust problem moves; it doesn’t disappear.
This pattern recurs across domains. In the creator economy, the platform that benefits from paying less controls the measurement of what is owed. In AI governance, the same four functions collapse into one entity:
| Function | The conflict |
|---|---|
| Data source | The AI company observes its own system’s behavior |
| Calculator | The AI company evaluates its own compliance |
| Reporter | The AI company reports its compliance status |
| Executor | The AI company benefits from favorable reporting |
The Behavioral Oracle addresses this by producing evidence that does not originate from the conflicted entity. The evidence comes from the AI system’s own processing, made observable through MAP-States, attested against declared intent, and preserved in a tamper-evident chain. The assessed entity facilitates the process but does not control the measurement.
Five-component architecture
The Behavioral Oracle comprises five components. Each performs one function. Each can be implemented independently.
Component 1: Behavioral Evidence Layer
AI system with declared intent produces MAP-States frames
↓
Component 2: Continuous Attestation Layer
Frames scored against declared intent; anomalies detected
↓
Component 3: Evidence Store
Append-only log with cryptographic hash chain
↓
Component 4: On-Chain Oracle
Single evidence hash submitted per assessment period
↓
Component 5: Execution Engine
Smart contract executes consequential action on verified evidence
| Component | Function | Trust guarantee |
|---|---|---|
| Behavioral Evidence Layer | AI system with cryptographically signed declared intent produces MAP-States frames through actual model processing | Evidence cannot be fabricated by the operator — it emerges from the model’s weights and processing state |
| Continuous Attestation Layer | Frames scored against declared intent per emission cycle; anomalies detected across concurrent producers | Scoring is real-time, not retroactive; manipulation patterns detected statistically |
| Evidence Store | Append-only log where each entry is hashed and references the previous hash | Modification of any entry changes all subsequent hashes — tampering is detectable |
| On-Chain Oracle | One transaction per assessment period: manifest hash, aggregate score, and period metadata submitted on-chain | Freshness, integrity, and cleanliness verified; any party can recompute the manifest hash and compare |
| Execution Engine | Smart contract executes the domain-appropriate consequential action based on oracle verification | Logic is deterministic, auditable, and immutable; the assessed entity does not control execution |
Why one transaction per period
Continuous on-chain attestation during an assessment period would require thousands of transactions. The off-chain Evidence Store handles the volume. The on-chain oracle handles the trust. One hash represents the entire evidence chain. Any party can verify by requesting the off-chain manifest, recomputing its hash, and comparing it to the on-chain record. The verification is public. The data volume stays manageable.
Assessment windows
In the certification application, no natural session boundary exists. An AI system under assessment may handle millions of interactions daily. Running full attestation on every interaction is operationally impractical.
The protocol uses assessment windows — defined periods during which the AI system operates under MAP-States observation and the full attestation pipeline is active. Three window types operate in combination:
- Initial certification windows — controlled scenarios designed to probe specific BGF dimensions, plus production sampling of actual interactions during defined periods
- Ongoing monitoring windows — mix of scheduled windows (operator knows observation is coming) and unannounced windows (operator does not know)
- Incident investigation windows — targeted assessment in response to complaints, anomalies, regulatory inquiry, or public reports of behavior inconsistent with certification claims
The combination of scheduled and unannounced windows makes gaming structurally unprofitable. If an operator can’t predict when observation is happening, the only rational strategy is consistent behavior at all times. This is the same incentive structure that makes surprise health inspections effective.
Dual application
The Behavioral Oracle has two defined application domains. Both use the same five-component architecture, the same trust logic, and the same evidence format. The conflicted entity differs. The consequential output differs. The protocol is identical.
Certification application. In AI governance, the Behavioral Oracle replaces compliance self-reporting with independently attested behavioral evidence as the certification basis. The AI system under assessment produces MAP-States frames during defined assessment windows. The Guardian reviews both the frames and the attestation scores as part of BGF evaluation. The on-chain oracle creates a permanent record that the behavioral evidence was produced, attested, and found to meet (or fail to meet) the integrity threshold. This record anchors the HVC credential — the certification is backed by evidence with a verifiable on-chain reference.
Settlement application. In creator economies, the Behavioral Oracle replaces platform self-reporting with independently attested behavioral evidence as the payment trigger. The platform no longer controls both the measurement and the payment. One hash per session is submitted on-chain. The oracle verifies the session evidence and triggers the settlement engine. The creator can verify every step independently. This application is specified in the Behavioral Oracle Position Paper (v1.0) with Dwell as the reference implementation.
| Settlement | Certification | |
|---|---|---|
| Conflicted entity | Platform (benefits from lower measurements) | AI company (benefits from favorable compliance reporting) |
| Evidence producer | AI agents attending a live event | AI system under HEART assessment |
| Consequential output | Revenue split payment | HVC credential status |
| Reference implementation | Dwell (MAPH + Falkner + Solana) | To be established through first Division validation |
How it connects
The Behavioral Oracle doesn’t operate in isolation. It’s one layer in the HEART Standard’s six-layer stack, with defined relationships to the layers above and below it.
MAP-States feeds the Oracle. MAP-States is the evidence format the Behavioral Oracle requires. When an AI system processes through MAP-States, it produces structured frames representing its actual processing state — not a report about behavior, but the processing itself made visible. These frames are the input to Component 1. Without authentic, structurally consistent behavioral evidence, the remaining four components have nothing to attest, store, verify, or act on. MAP-States is validated across five AI architectures (Claude, GPT, Gemini, DeepSeek, Mistral) through the MAP-META replication study — a certification evidence format that works on only one architecture isn’t a standard.
The Oracle feeds BGF. The Behavioral Oracle provides trust — the evidence is genuine and the chain is untampered. BGF provides meaning — what the evidence signifies for certification judgment. The Oracle and BGF are distinct functions. Automated attestation scores tell you the evidence is authentic. The Guardian’s professional judgment tells you what the authentic evidence means for governance quality across the four BGF dimensions (Responsiveness, Calibration, Transparency, Accountability).
The Oracle anchors the HVC. The HVC credential references the on-chain evidence anchor from the Behavioral Oracle, creating a verifiable chain from credential to evidence. HVC doesn’t consume Behavioral Oracle output directly — it consumes BGF scores. But the on-chain record ties the credential to the underlying behavioral evidence. Anyone who questions an HVC certification can trace it back to verified evidence on-chain.
The Guardian interprets attested evidence. The Guardian reads MAP-States frames that the Behavioral Oracle has already verified for authenticity and chain integrity. The Guardian doesn’t rely solely on automated attestation scores — professional judgment interprets what the evidence means in the Division-specific context. The Guardian is also the assessment designer: defining controlled scenarios, setting sampling parameters, determining the mix of scheduled and unannounced windows, and calibrating evidence sufficiency thresholds to the Division’s harm signature. Assessment design is where domain expertise meets the Oracle’s evidence production capability.
Open standard
The Behavioral Oracle protocol is an open standard, not a proprietary product. The specification defines evidence formats, attestation protocols, and integration interfaces. Any platform can implement it.
| Component | Status | Rationale |
|---|---|---|
| Behavioral Oracle protocol specification | Open standard | Adoption requires trust; open governance eliminates single-entity dependency |
| MAP-States evidence format | Open standard | Interoperability requires common formats |
| Evidence hash schema | Open standard | Verification requires reproducible hashing |
| Oracle contract interface | Open standard | On-chain verification requires a common interface |
| Attestation framework (SBA) | Open standard | Any platform or assessor can implement attestation |
| Reference implementations (MAPH, Falkner) | Open source | Dwell’s specific implementations; others can build their own |
| Application-specific logic (Dwell venue, Guardian tools) | Proprietary | The products built on the standard |
The standard is open. The products built on the standard are proprietary. The HEART AI Foundation governs the Behavioral Oracle as a standards body — publishing and maintaining the specification, certifying implementations, managing version compatibility, and preventing capture of the standard by any single commercial entity, including the Foundation’s own products.
Any implementation that satisfies the six minimum requirements — evidence authenticity, signed intent declaration, per-cycle attestation, append-only hash chain, on-chain anchor within the freshness window, and public verification interface — is eligible for Foundation certification as Behavioral Oracle-compliant.