Plausibility Matrix
What is the Plausibility Matrix?
The Plausibility Matrix is the mechanism by which AIEP prevents execution on claims that are objectively implausible under current knowledge — while preserving a structured, evidence-bound pathway for implausible claims to become executable when knowledge changes.
This is what P03 (GB2519799.7) defines.
The word “matrix” is deliberate. This is not a binary filter. It is a scored, registry-bound, cryptographically verifiable continuum from “will not execute” through “requires human arbitration” to “proceeds normally.”
The problem it solves
Evidence retrieval systems face an asymmetry: they can verify that a claim exists and that evidence is attached, but they cannot — from structure alone — determine whether a claim is physically reasonable, logically coherent, or within the scope of current scientific understanding.
Without a plausibility layer, an AIEP execution system would be obligated to treat “this perpetual motion device has a failure rate of zero” with the same execution weight as “this bridge design has been load-tested to 50 tonnes.” Both may carry valid evidence artefacts. Both may have valid issuers. The structure is identical. The claims are not.
The Plausibility Matrix inserts a scored, registry-verifiable coefficient into the execution pipeline before the canonical scoring function runs. A claim that cannot pass the plausibility gate does not reach the scoring engine.
PlausibilityScore and the execution pipeline
The PlausibilityScore is a bounded numeric coefficient retrieved from a versioned safety registry. It is not computed from the claim itself — it is retrieved from the registry for the claim’s declared type.
The flow:
| Step | Operation |
|---|---|
| 1 | Execution request arrives with a declared claim_type |
| 2 | Execution controller retrieves registry entry for that claim_type |
| 3 | Registry version identifier is verified |
| 4 | Merkle proof of inclusion is verified against published Merkle root |
| 5 | If either verification fails → non-execution state, fail-closed |
| 6 | PlausibilityScore is incorporated as a deterministic coefficient in safetyViolation computation |
| 7 | safetyViolation is compared to execution threshold |
| 8 | Execution state assigned |
The safetyViolation contribution feeds into the canonical scoring function defined in GB2519711.2:
Score_i = α · deviation_i + β · safetyViolations_i + γ · resourceCost_i
The PlausibilityScore shapes the safetyViolations_i term — it does not alter the scoring formula itself.
The three execution bands
| PlausibilityScore | Execution outcome |
|---|---|
| Below lower threshold | safetyViolation exceeds any execution threshold → guaranteed non-execution |
| Intermediate band | Execution requires mandatory human arbitration — registry version ID and Merkle proof hash recorded in audit log |
| Above upper threshold | Normal AIEP arbitration proceeds |
This is not a soft recommendation. Below the lower threshold, no override mechanism permits execution. The fail-closed architecture treats absence of valid plausibility verification exactly as it treats verification failure — non-execution.
Registry versioning and cryptographic binding
The PlausibilityScore is not static. Registry updates proceed through:
- Digitally signed plausibility assessments submitted by recognised authorities
- Deterministic aggregation:
P = Aggregate(w₁s₁, w₂s₂, … wₙsₙ)where eachsᵢis a signed assessment - New registry version published with threshold cryptographic signatures from a predefined quorum
- New Merkle root published alongside the version
- Consuming systems retrieve and verify the new version before using updated scores
The critical property: a claim cannot use an updated, higher PlausibilityScore unless it can verify the Merkle proof for the new registry version. You cannot self-certify increased plausibility.
What AIEP means by “implausible”
Implausibility in AIEP is not a permanent judgement — it is a time-stamped registry state. The classic worked example from P03:
- Claim-type: “Perpetual motion engine design”
- Registry v1.3:
PlausibilityScore = 10→ non-execution - New signed assessments arrive and are deterministically aggregated
- Registry v1.4 published:
PlausibilityScore = 65→ execution proceeds under normal arbitration
This is the canonical expression of the recall principle. What was once implausible can become executable when the registry of knowledge changes. The pathway is not arbitrary elevation — it requires signed assessments from recognised authorities, deterministic aggregation, and threshold quorum authorisation.
See: Architecture of Knowing — the jigsaw metaphor and the role of preserved outliers.
The public interface: P67
While P03 (the Plausibility Matrix itself) defines the full internal engine — PlausibilityScore computation, Merkle verification, execution gating — P67 defines the public declaration format that third-party agents consume.
The plausibility object in an AIEP machine mirror page contains:
| Field | Type | Meaning |
|---|---|---|
constraint_id | string | Unique identifier for this constraint within the schema version |
constraint_class | enum | structural, constitutional, temporal, or domain_specific |
result | enum | PASS, FAIL, or WARN |
severity_level | int 1–5 | 1 = informational, 5 = critical |
A PlausibilityDeclarationHash is computed over the full canonical constraint array, schema ID, and schema version:
PlausibilityDeclarationHash = H(CanonicalConstraintArray || schema_id || schema_version)
A constraint with result: FAIL and severity_level 4 or 5 must be treated as non-admissible by any conformant agent, unless overridden by an explicit agent-side policy. The internal matrix logic — weights, constraint ranking, Bayesian parameters — is not exposed. Only the outcomes are public.
Plausibility and the dissent archive
Plausibility gates execution. The dissent archive stores what execution rejected.
These two mechanisms are complementary:
| Mechanism | Function |
|---|---|
| Plausibility Matrix | Prevents execution on registry-implausible claims — fail-closed |
| Dissent Archive | Preserves rejected claims with provenance intact for future re-evaluation |
| Registry update pathway | The structured route by which an archived claim can become executable again |
A claim that fails the plausibility gate is not deleted. Its DivergenceRecord is created, it is routed to the dissent archive, and its claim-type is associated with the registry version under which it failed. When the registry updates — when new signed assessments shift the PlausibilityScore into the executable band — the recall mechanism can surface archived claims of that type for re-evaluation.
This is not a loophole. It is the protocol expressing the correct epistemic position: we cannot execute this under current knowledge, but we preserve it so that future knowledge can.
Patents
- P03 / GB2519799.7 — Plausibility Matrix: Deterministic Registry-Bound Execution Control
- P67 — Plausibility Constraint Declaration Format (open source prior art disclosure)
Related
- Architecture of Knowing — how preserved outliers become future consensus
- Divergence — how plausibility failures become DivergenceRecords
- Recall — how archived claims are re-evaluated when knowledge shifts
- Probability Engine — the complementary safety certification layer
- Constitutional Substrate — the scoring function P03 feeds into
- Patents — P03, P67