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:

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


Get involved · Get started · Talk to us · Contact · GitHub ↗