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:

StepOperation
1Execution request arrives with a declared claim_type
2Execution controller retrieves registry entry for that claim_type
3Registry version identifier is verified
4Merkle proof of inclusion is verified against published Merkle root
5If either verification fails → non-execution state, fail-closed
6PlausibilityScore is incorporated as a deterministic coefficient in safetyViolation computation
7safetyViolation is compared to execution threshold
8Execution 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

PlausibilityScoreExecution outcome
Below lower thresholdsafetyViolation exceeds any execution threshold → guaranteed non-execution
Intermediate bandExecution requires mandatory human arbitration — registry version ID and Merkle proof hash recorded in audit log
Above upper thresholdNormal 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:

  1. Digitally signed plausibility assessments submitted by recognised authorities
  2. Deterministic aggregation: P = Aggregate(w₁s₁, w₂s₂, … wₙsₙ) where each sᵢ is a signed assessment
  3. New registry version published with threshold cryptographic signatures from a predefined quorum
  4. New Merkle root published alongside the version
  5. 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:

FieldTypeMeaning
constraint_idstringUnique identifier for this constraint within the schema version
constraint_classenumstructural, constitutional, temporal, or domain_specific
resultenumPASS, FAIL, or WARN
severity_levelint 1–51 = 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:

MechanismFunction
Plausibility MatrixPrevents execution on registry-implausible claims — fail-closed
Dissent ArchivePreserves rejected claims with provenance intact for future re-evaluation
Registry update pathwayThe 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)