Minimum Third-Mode Interface

Appendix I

11 min read

Appendix I: Minimum Third-Mode Interface

This appendix specifies the operational interface a system must implement to claim compliance with the Third Mode. A compliant system must implement all ten operations with their stated signatures, preconditions, artifacts, and failure modes.

The specification is deliberately minimal. It describes what the interface must do, not how implementations should achieve it. Any system that satisfies these contracts—regardless of internal architecture—is Third-Mode compliant.

I.1 Core Types

Before specifying operations, we define the types that appear in signatures.

I.1.1 Primitive Types

Context       := { name: String, signature: Set⟨Predicate⟩, logic: Logic }
Logic         := CWA | OWA | THREE_VALUED
Claim         := { subject: EntityRef, predicate: PredicateName, value: Value, context: Context }
EntityRef     := Opaque identifier for an entity
PredicateName := String
Value         := Any (type determined by predicate signature)

I.1.2 Witness Types

Witness       := { class: WitnessClass, content: WitnessContent, provenance: Provenance }
WitnessClass  := DECIDABLE | PROBABILISTIC | ATTESTED
WitnessContent := class-specific evidence (see A2c)
Provenance    := { source: String, timestamp: DateTime, method: String }

I.1.3 Equivalence Types

Scope         := Set⟨Context⟩ (downward-closed in context poset)
Equivalence   := { left: EntityRef, right: EntityRef, scope: Scope, witness: Witness }
TransportCertificate := { equivalence: Equivalence, property: PredicateName, direction: LEFT_TO_RIGHT | RIGHT_TO_LEFT }

I.1.4 Cover Types

Cover         := { components: Set⟨Context⟩, target: Context }
                 -- components must jointly cover target in the site topology
MatchingFamily := { sections: Map⟨Context, Claim⟩, cover: Cover }
                 -- sections must agree on overlaps for the family to be "matching"

I.1.5 Artifact Types

-- Success artifacts
ClaimReceipt        := { claim: Claim, witness: Witness, timestamp: DateTime }
GluingReceipt       := { global_claim: Claim, local_receipts: Set⟨ClaimReceipt⟩, cover: Cover }
TransportReceipt    := { original: Claim, transported: Claim, certificate: TransportCertificate }
AcceptanceReceipt   := { predicate: PredicateName, tests_passed: Int, scope: Scope, version: SemVer }

-- Failure artifacts
ObstructionWitness  := { disagreeing_contexts: Set⟨Context⟩, conflict_set: Set⟨Claim⟩, 
                         resolution_options: Set⟨ResolutionHint⟩ }
ScopeViolation      := { equivalence: Equivalence, attempted_context: Context, 
                         valid_scope: Scope, violation_type: OUTSIDE_SCOPE | SCOPE_LEAK }
UnsatCore           := { constraints: Set⟨Constraint⟩, derivation: DerivationChain }
RejectionWitness    := { reason: RejectionReason, evidence: Any }
RejectionReason     := MISSING_EVIDENCE | INVARIANT_VIOLATION | SCOPE_MISMATCH | 
                       TEST_FAILURE | WITNESS_EXPIRED | LOGIC_MISMATCH

I.2 The Ten Operations

Operation 1: `create_context`

Purpose: Establish a new context with a declared signature and logic regime.

create_context(
  name: String,
  signature: Set⟨PredicateSpec⟩,
  logic: Logic,
  refines?: Set⟨Context⟩    -- optional: contexts this one refines
) → Context | RejectionWitness

Preconditions:

name is unique within the system
Each PredicateSpec in signature is well-formed
If refines is provided, signature must be a conservative extension of refined contexts

Artifacts on success:

Context object with assigned identity

Failure modes:

RejectionWitness with NAME_COLLISION if name exists
RejectionWitness with SIGNATURE_MALFORMED if any predicate spec is invalid
RejectionWitness with NOT_CONSERVATIVE if refinement violates conservativity

Invariant: Created contexts are immutable. To modify a context, create a new version.

Operation 2: `register_claim`

Purpose: Assert a claim in a context with supporting witness.

register_claim(
  subject: EntityRef,
  predicate: PredicateName,
  value: Value,
  context: Context,
  witness: Witness
) → ClaimReceipt | RejectionWitness

Preconditions:

predicate is in context.signature
value conforms to predicate's declared type
witness.class is acceptable for this predicate (per predicate's witness policy)
Claim does not contradict existing claims in context

Artifacts on success:

ClaimReceipt with timestamp and witness binding

Failure modes:

RejectionWitness with PREDICATE_NOT_IN_SIGNATURE if predicate unknown in context
RejectionWitness with TYPE_MISMATCH if value type is wrong
RejectionWitness with WITNESS_INSUFFICIENT if witness class is too weak
RejectionWitness with CONTRADICTION if claim conflicts with existing claims

Invariant: A registered claim cannot be silently overwritten. Correction requires explicit retraction (Operation 10).

Operation 3: `verify_witness`

Purpose: Check that a witness is valid for a claim under its declared class.

verify_witness(
  claim: Claim,
  witness: Witness
) → VerificationResult

VerificationResult := 
  | { status: OK }
  | { status: OK_WITH_CONFIDENCE, confidence: Float, bounds: (Float, Float) }
  | { status: OK_IF_TRUSTED, authority: String }
  | { status: FAIL, reason: String }

Preconditions:

witness.class is declared
witness.content is parseable for that class

Artifacts: Returns VerificationResult (no persistent artifact)

Failure modes: Returns FAIL status with diagnostic reason

Contract by class (per A2c):

Class	Verification	Output on success
`DECIDABLE`	Total, deterministic	`OK`
`PROBABILISTIC`	Terminates with confidence	`OK_WITH_CONFIDENCE(p, bounds)`
`ATTESTED`	Checks provenance chain	`OK_IF_TRUSTED(authority)`

Operation 4: `declare_equivalence`

Purpose: Assert that two entities are equivalent within a scope, with witness.

declare_equivalence(
  left: EntityRef,
  right: EntityRef,
  scope: Scope,
  witness: Witness
) → Equivalence | RejectionWitness

Preconditions:

left ≠ right (no trivial self-equivalence declarations)
scope is a valid downward-closed set of contexts
witness supports the equivalence claim
No conflicting equivalence exists in scope (e.g., left ~_S z and right ~_S z with z ≠ left, right)

Artifacts on success:

Equivalence object registered in system's equivalence graph

Failure modes:

RejectionWitness with TRIVIAL_EQUIVALENCE if left = right
RejectionWitness with INVALID_SCOPE if scope is malformed
RejectionWitness with CONFLICTING_EQUIVALENCE if contradicts existing

Invariant: Equivalences are persistent within their scope. Retraction requires explicit operation with audit trail.

Operation 5: `transport`

Purpose: Move a property from one entity to an equivalent entity via certificate.

transport(
  claim: Claim,
  equivalence: Equivalence,
  target_context: Context
) → TransportReceipt | ScopeViolation

Preconditions:

claim.subject matches one side of equivalence
target_context ∈ equivalence.scope
claim.predicate is transportable (some predicates may be marked non-transportable)

Artifacts on success:

TransportReceipt binding original claim to transported claim

Failure modes:

ScopeViolation with OUTSIDE_SCOPE if target_context ∉ equivalence.scope
ScopeViolation with SCOPE_LEAK if transport would leak beyond declared scope
RejectionWitness with NOT_TRANSPORTABLE if predicate blocks transport

Invariant: Transport produces a new claim in target context. Original claim remains. Both are linked via receipt.

Operation 6: `glue`

Purpose: Given a cover and local claims, check the sheaf condition and produce a global claim or obstruction witness.

glue(
  cover: Cover,
  claims: MatchingFamily
) → GluingReceipt | ObstructionWitness

Preconditions:

cover.components is a valid cover of cover.target in the site topology
Each claim in claims.sections is registered in its respective context
Claims share the same (subject, predicate) signature

Sheaf condition check: For all pairs (Uᵢ, Uⱼ) with non-empty overlap Uᵢ ∩ Uⱼ:

claims[Uᵢ]|_{Uᵢ ∩ Uⱼ} must agree with claims[Uⱼ]|_{Uᵢ ∩ Uⱼ}

Agreement is defined by the predicate's AgreementCriterion:

For discrete values: equality
For scores: within declared tolerance
For probabilistic: distribution overlap

Artifacts on success:

GluingReceipt containing the unique global claim and provenance chain

Failure modes:

ObstructionWitness with:
- disagreeing_contexts: minimal set of contexts where agreement fails
- conflict_set: the specific claims that disagree
- resolution_options: hints for resolution (tolerance adjustment, scope fork, authority resolution)

Invariant: If gluing succeeds, the global claim is the unique section over the target. The sheaf condition guarantees uniqueness.

Operation 7: `propose_predicate`

Purpose: Submit a new predicate for potential inclusion in the vocabulary.

propose_predicate(
  name: PredicateName,
  signature: PredicateSpec,
  intension: IntensionSpec,      -- definition (rule, model, exemplars)
  scope: Scope,
  invariants: Set⟨Constraint⟩,
  tests: TestSuite
) → ProposalId

Preconditions:

name is not already in global vocabulary
signature is well-formed
tests includes positive exemplars, negative exemplars, and boundary cases

Artifacts:

ProposalId for tracking through acceptance pipeline

Failure modes: None at proposal stage. Proposal is always accepted for evaluation.

Note: This operation does not add the predicate to the vocabulary. It queues the proposal for acceptance testing (Operation 8).

Operation 8: `accept_predicate`

Purpose: Run acceptance tests on a proposed predicate and, if passed, add to vocabulary.

accept_predicate(
  proposal_id: ProposalId
) → AcceptanceReceipt | RejectionWitness

Preconditions:

proposal_id refers to a valid pending proposal
System has sufficient resources to run test suite

Acceptance criteria (per A29):

Positive exemplars: All must be classified correctly
Negative exemplars: None may be classified as positive
Invariants: All hard invariants must hold
Conservative extension: Adding predicate must not change truths in existing vocabulary
Scope consistency: Predicate must be well-defined in all declared scope contexts

Artifacts on success:

AcceptanceReceipt with version, scope, and test results summary
Predicate added to vocabulary with declared scope

Failure modes:

RejectionWitness with TEST_FAILURE listing failed cases
RejectionWitness with INVARIANT_VIOLATION with specific constraint
RejectionWitness with NOT_CONSERVATIVE with counterexample
RejectionWitness with SCOPE_UNDEFINED listing contexts where predicate fails

Invariant: Accepted predicates are versioned. Future modifications create new versions, not overwrites.

Operation 9: `query`

Purpose: Return candidates matching query predicates, with attached obligations.

query(
  pattern: QueryPattern,
  contexts: Set⟨Context⟩,
  constraints: Set⟨Constraint⟩
) → QueryResult

QueryResult := {
  candidates: Set⟨{ entity: EntityRef, claims: Set⟨ClaimReceipt⟩ }⟩,
  obligations: QueryObligations,
  coverage: CoverageReport
}

QueryObligations := {
  required_witnesses: Set⟨WitnessRequirement⟩,
  contexts_consulted: Set⟨Context⟩,
  invariants_enforced: Set⟨Constraint⟩,
  uncertainty_budget: UncertaintySpec
}

Preconditions:

All predicates in pattern exist in at least one context in contexts
constraints are satisfiable (checked via lightweight pre-solve)

Artifacts:

QueryResult with candidates, obligations, and coverage report

Failure modes:

UnsatCore if constraints are unsatisfiable
RejectionWitness with PREDICATE_UNKNOWN if pattern uses undefined predicate
RejectionWitness with CONTEXT_INACCESSIBLE if context cannot be reached

Invariant: Query results include provenance for every claim. No "orphan" results.

Operation 10: `refuse_or_retract`

Purpose: Handle unsatisfiable constraints or retract a previously registered claim.

-- Refusal mode (constraints imply emptiness)
refuse(
  constraints: Set⟨Constraint⟩
) → UnsatCore

-- Retraction mode (explicit withdrawal)
retract(
  claim_receipt: ClaimReceipt,
  reason: RetractionReason,
  authority: Witness
) → RetractionReceipt

Refusal preconditions:

Constraints have been determined unsatisfiable

Refusal artifacts (per A27):

UnsatCore containing:
- Locally-minimal inconsistent constraint subset
- Derivation chain (human-readable proof sketch)
- Machine-checkable certificate (if available)

Retraction preconditions:

claim_receipt refers to a registered claim
authority has standing to retract (original asserter or delegated authority)

Retraction artifacts:

RetractionReceipt with timestamp, reason, authority
Claim marked as retracted (not deleted) in system

Invariant: Retracted claims remain in audit log. They are excluded from queries but remain queryable via audit interface.

I.3 Compliance Criteria

A system is Third-Mode compliant iff:

All ten operations are implemented with the specified signatures
Preconditions are enforced (operations fail predictably when preconditions are violated)
Artifacts are produced (success and failure both produce structured artifacts)
Invariants are maintained (immutability, auditability, versioning)
Failure modes are exhaustive (no silent failures; every failure produces a diagnostic artifact)

I.3.1 Minimum Test Suite

A compliance test must verify:

Test Case	Operation	Expected
Register valid claim	`register_claim`	`ClaimReceipt`
Register claim with wrong type	`register_claim`	`RejectionWitness(TYPE_MISMATCH)`
Register contradicting claim	`register_claim`	`RejectionWitness(CONTRADICTION)`
Declare valid equivalence	`declare_equivalence`	`Equivalence`
Transport within scope	`transport`	`TransportReceipt`
Transport outside scope	`transport`	`ScopeViolation(OUTSIDE_SCOPE)`
Glue matching family	`glue`	`GluingReceipt`
Glue disagreeing family	`glue`	`ObstructionWitness`
Accept valid predicate	`accept_predicate`	`AcceptanceReceipt`
Accept failing predicate	`accept_predicate`	`RejectionWitness(TEST_FAILURE)`
Query satisfiable	`query`	`QueryResult`
Query unsatisfiable	`query`	`UnsatCore`
Retract with authority	`retract`	`RetractionReceipt`
Retract without authority	`retract`	`RejectionWitness`

I.4 What This Specification Does Not Cover

This interface specifies what a Third-Mode system must do, not how:

Storage implementation: Any backend (graph DB, relational, in-memory) is acceptable
Consistency model: Eventual, strong, or causal consistency are all compatible
Computation strategy: Eager or lazy evaluation of gluing is implementation-dependent
Distributed architecture: Single-node or distributed implementations are both valid
Query language: The QueryPattern type is abstract; implementations may use SQL, GraphQL, Datalog, etc.

The specification also does not cover:

Authentication/authorization: Assumed to exist but not specified here
Performance requirements: No latency or throughput guarantees
UI/API surface: Operations may be exposed via any interface (REST, gRPC, library API)

I.5 Relationship to Anchors

This interface draws directly from the formal anchors:

Operation	Primary Anchors
`create_context`	A12, A12b (covers, site structure)
`register_claim`	A2, A2b (provenance, witnessed assertion)
`verify_witness`	A2c (witness classes)
`declare_equivalence`	A10, A23, A30 (witnessed sameness, scoped equivalence)
`transport`	A16 (transport discipline)
`glue`	A13 (sheaf condition)
`propose_predicate`	A17, A19 (predicate invention, proposal operator)
`accept_predicate`	A29, A24 (predicate acceptance, predicate package)
`query`	A25 (query semantics)
`refuse_or_retract`	A27 (refusal obligation)

I.6 Consequence

A system implementing this interface can answer the fundamental question of the Third Mode:

"Can these local claims be reconciled into a coherent global assertion?"

If yes: produce the global claim with full provenance.
If no: produce an obstruction witness that explains why and what would need to change.

That is the minimum viable discipline for systems that must generalize beyond their initial vocabulary.

← Back to Appendices Back to The Proofs →

Appendix I: Minimum Third-Mode Interface

I.1 Core Types

I.1.1 Primitive Types

I.1.2 Witness Types

I.1.3 Equivalence Types

I.1.4 Cover Types

I.1.5 Artifact Types

I.2 The Ten Operations

Operation 1: create_context

Operation 2: register_claim

Operation 3: verify_witness

Operation 4: declare_equivalence

Operation 5: transport

Operation 6: glue

Operation 7: propose_predicate

Operation 8: accept_predicate

Operation 9: query

Operation 10: refuse_or_retract

I.3 Compliance Criteria

I.3.1 Minimum Test Suite

I.4 What This Specification Does Not Cover

I.5 Relationship to Anchors

I.6 Consequence

Operation 1: `create_context`

Operation 2: `register_claim`

Operation 3: `verify_witness`

Operation 4: `declare_equivalence`

Operation 5: `transport`

Operation 6: `glue`

Operation 7: `propose_predicate`

Operation 8: `accept_predicate`

Operation 9: `query`

Operation 10: `refuse_or_retract`