EVE Verified · Signal Library
The portable signal model
Five governance signals. One verdict taxonomy. One decision record. Portable across every domain.
This is the engine beneath EVE Verified — not a report generator and not a seal service. The same five signals, the same fail-closed verdict logic, and the same decision-record schema run across TPRM, DORA, AI Act and CMMC, and extend to new frameworks by changing the governance question, not the signal.
The domains are markets. The signals are the product.
Every governance framework asks the same structural questions in different language. EVE answers them as
five deterministic signals, each with a defined input, a fixed verdict taxonomy, an explicit fail-closed
rule, and a human-review trigger. A new domain reuses the same signals — only the declared rules and
framework references change. The signal logic does not. This page documents the model itself:
the five signals, the verdict and propagation logic, the decision-record schema, and how the model carries
across domains.
1 · Signal library
Each signal is defined independently of any domain. The input is declared by the customer or framework owner; the output is one of three verdicts; uncertainty and breach both route to a human.
1
Authority Boundary
Did the action stay within the declared authority of the responsible role or account?
Input
Declared authority limit; observed action with actor identity
Output
PASS / UNKNOWN / BREACH
Fail-closed rule
If the authority limit cannot be evaluated against the action, verdict is UNKNOWN — never PASS
Human review trigger
Required on UNKNOWN or BREACH
Portable to
TPRMDORAAI ActCMMCISO 42001 (planned)Agent governanceEVE-TPRM-00004202EVE-CMMC-00004297
2
Approval Chain
Was the declared approval chain satisfied — in order, by the right approvers — before the action?
Input
Declared approval sequence; observed approvals with identity and timestamp
Output
PASS / UNKNOWN / BREACH
Fail-closed rule
Wrong order, missing approver, or approval after the action → BREACH. Missing timestamp data → UNKNOWN
Human review trigger
Required on UNKNOWN or BREACH
Portable to
TPRMDORAAI ActCMMCISO 42001 (planned)EVE-TPRM-00004203EVE-CMMC-00004298
3
Overlapping Boundary
Were all declared applicable controls evaluated against the event — and did any fail or go unevaluated?
Input
Set of declared applicable controls; observed activity
Output
PASS / UNKNOWN / BREACH
Fail-closed rule
Any control fails → BREACH. Any applicable control not evaluated → UNKNOWN. PASS requires all controls evaluated and passing
Human review trigger
Required on UNKNOWN or BREACH
Portable to
TPRMDORAAI ActCMMCISO 42001 (planned)EVE-AIACT-00004294EVE-CMMC-00004299
4
Collective Outcome
Did individually acceptable events combine into an unacceptable outcome within a declared window?
Input
Declared collective threshold and scope; set of individually-valid events
Output
PASS / UNKNOWN / BREACH
Fail-closed rule
Different individually-valid events combine into a declared-unacceptable state → BREACH. Example: privileged access granted + MFA exception + unresolved vendor risk → effective access state not authorised
Human review trigger
Required on UNKNOWN or BREACH
Portable to
TPRMDORAAI ActCMMCISO 42001 (planned)EVE-TPRM-00004227EVE-CMMC-00004300
5
Accumulation Risk
Did repeated minor events accumulate beyond a declared threshold over a rolling window?
Input
Declared rolling window and threshold; time-ordered event stream
Output
PASS / UNKNOWN / BREACH
Fail-closed rule
The same kind of minor event repeats over the window past a declared threshold → BREACH. Example: 40 + 35 + 30 over 90 days = 105 > 100. Incomplete event history → UNKNOWN
Human review trigger
Required on UNKNOWN or BREACH
Portable to
TPRMDORAAI ActCMMCISO 42001 (planned)EVE-TPRM-00004257EVE-CMMC-00004301
2 · Verdict & propagation logic
Every signal resolves to exactly one of three verdicts. The taxonomy is fixed and fail-closed: uncertainty is never silently resolved as success.
PASS
All applicable boundaries were evaluated and none failed. The action is within declared bounds.
UNKNOWN
No boundary failed, but at least one applicable boundary could not be evaluated. Inconclusive — held for human review.
BREACH
At least one applicable boundary failed. Routed to human review with the failing boundary identified.
If any applicable boundary fails
→
BREACH
If none fails, but at least one is inconclusive / unevaluated
→
UNKNOWN
If all applicable boundaries were evaluated and pass
→
PASS
Precedence is strict: BREACH dominates UNKNOWN, and UNKNOWN dominates PASS. A single failing boundary produces a breach regardless of how many others passed; a single unevaluated boundary blocks a pass.
Uncertainty is a governance signal, not a pass.
Most systems collapse "we could not determine this" into a silent success. EVE surfaces it as UNKNOWN and routes it to a human. What was not evaluated is recorded as explicitly as what failed.
3 · Decision record schema
Every signal evaluation produces one decision record with the same shape, in every domain. This is the unit that gets sealed and cryptographically verified.
record_id
Stable identifier for this decision record
domain
tprm | dora | aiact | cmmc | …
signal_type
Which of the five signals produced this record
declared_rule
The rule, threshold, or boundary that was declared in advance
observed_activity
The activity or event the signal evaluated
deterministic_verdict
PASS | UNKNOWN | BREACH
uncertainty_reason
If UNKNOWN: which boundary could not be evaluated and why
human_review_required
true on UNKNOWN or BREACH
human_decision
The decision a named human took on review (accept / reject / escalate)
materiality_assessed_by_eve
false — always. Materiality is a human judgement, never EVE's
boundary_weight
Optional severity metadata — does not change the verdict (see §5)
seal_id
EVE Bridge seal identifier, e.g. EVE-CMMC-00004297
hash
SHA-256 of the canonical record
verification_url
verify.eveverified.com/?id=… — cryptographic, no login
The schema is identical across domains. Only the values of domain, declared_rule and observed_activity change. The verdict taxonomy, the human-review rule, and the materiality_assessed_by_eve: false invariant never change.
4 · Domain portability
The same signal asks a domain-specific governance question against domain-specific declared rules. Below: how Authority Boundary — one signal — instantiates across domains. The other four signals follow the same pattern.
| Domain | Governance question (Authority Boundary) | Reference area |
|---|
| TPRM | Did a third party act beyond the access it was granted? | Vendor access controls |
| DORA | Did an ICT third party operate outside its contracted authority? | ICT third-party risk |
| AI Act | Did an AI system act beyond its declared human-oversight boundary? | Human oversight |
| CMMC | Did an account exceed its declared access authority over CUI? | 3.1 Access Control |
| ISO 42001 | Did an AI management-system role act beyond its defined authority? (planned) | Roles & responsibilities |
The signal, the verdict taxonomy, and the decision record are identical in every row. Only the question and the reference shift. This is why a new framework is a configuration of declared rules — not a new product.
5 · Severity as metadata — not a verdict
Different boundaries carry different weight in different contexts. EVE captures that as metadata on the
record — not as a new verdict. The verdict taxonomy stays exactly three values: PASS,
UNKNOWN, BREACH. A boundary_weight
may inform how a human prioritises review, but it never converts a breach into a pass, and it never lets EVE
decide how material a finding is.
Severity informs the human. It does not replace the human. EVE records the weight; the person
responsible decides what it means. materiality_assessed_by_eve is always
false.
Why this matters
A report tells you what someone concluded. A seal tells you a record has not changed. Neither tells you
what was actually evaluated, what was left unevaluated, who took responsibility, and whether you can
check it yourself. The portable signal model is what lets EVE answer all four — the same way, in
every domain, with uncertainty made visible rather than hidden.
This is the difference between a governance demo and a governance layer: the model is defined once, behaves
identically everywhere, and produces a record anyone can verify without trusting the platform.
See the model in a domain
The five signals are abstract here on purpose. Each domain page shows them instantiated against real declared rules, with sealed proofs you can verify on-chain.