Comparison Contracts, Contested Partition Histories, Reproducible Local Property Runs, and Human-Legible Recovery
Concresca Research Document DOC-052
Release: v0.18.0
Epistemic status: Technical-governance framework, local repository conformance evidence, and analytical test definitions
Date: 2026-08-29
Truth boundary: This document defines temporal-comparison contracts, proof obligations, receipt schemas, partition-history cases, legibility tests, and invalidation rules. It also reports a deterministic local conformance run against exact Concresca repository artifacts. It does not report a live external interoperability exchange, a production partition or restoration, external adoption, legal recognition, independent certification, or production performance.
Executive finding
A system can reconnect while remaining constitutionally unfit to resume authority. It can reproduce the same bytes while carrying stale authorization. It can present a successful transport health check while its evidence history is forked, its revocation record is incomplete, its model or policy version has drifted, or its human explanation conceals an unresolved contradiction.
Concresca therefore treats restoration as a proof-bearing transition rather than a network event. The transition must establish what is being compared, which histories exist, what changed, which authority is current, what was revoked or stayed, which conflicts remain unresolved, what baseline is attested, what limited function is permitted, and what a human reviewer can understand and challenge.
v0.18 adds four linked controls:
- Temporal comparison contracts prevent two artifacts from being called “unchanged” unless their identity, capture scope, normalization, version semantics, time basis, and material dimensions are comparable.
- Proof-carrying restoration requires a conjunctive set of evidence obligations before authority can move from disconnected or disputed states into limited or full restoration.
- Contested partition-history reconciliation preserves competing histories and unresolved facts instead of collapsing them into whichever node reconnects first.
- Human-legibility evaluation treats authority, evidence, uncertainty, change, stay, revocation, reconciliation, and restoration explanations as hard gates rather than decorative summaries.
The release also executes a bounded local property run against repository-owned Concresca registries. That run establishes only that the published local artifacts satisfy the named machine-checkable invariants under the recorded method and inputs.
1. The temporal-integrity problem
A comparison is not merely two digests placed side by side. A digest can answer whether the chosen input bytes differ, but it cannot answer whether the two inputs represent the same conceptual artifact, the same fields, the same normalization, the same authority period, or the same evidentiary question.
Consider five superficially similar statements:
- The raw bytes are unchanged.
- The selected fields are unchanged.
- The declared version is unchanged.
- No material constitutional dimension changed.
- No change was observed.
These are not interchangeable.
Raw bytes may change because whitespace changed. Selected fields may remain unchanged while an unretained field changes. A declared version may remain stable while the publisher silently revises content. A material constitutional dimension may change even when most fields remain identical. “No change observed” may mean no comparison was performed, the source was unavailable, or the capture was incomparable.
Temporal integrity begins by refusing to compress those states.
2. Comparison contracts
A comparison contract defines the conditions under which a result is meaningful. Concresca v0.18 publishes twelve contracts.
2.1 Identity continuity
The comparison must identify the same canonical artifact or explicitly explain a successor relationship. A shared title is insufficient. Required identity evidence may include a stable artifact identifier, canonical route, declared successor record, or exact repository path.
2.2 Capture-scope equivalence
The compared captures must retain the same field set or declare additions and removals. A comparison that silently drops a field cannot support an “unchanged” conclusion for that field.
2.3 Version semantics
A semantic version, publication revision, date, commit identifier, or “version not observed” state must be explicit. Different version systems must not be normalized into false equivalence.
2.4 Raw-byte comparability
Raw-byte comparison is valid only when both exact byte sequences were actually retained and the content boundary is known. A selected-field digest cannot be relabeled as a remote-response hash.
2.5 Selected-field comparability
Selected-field comparison is valid only when field names, values, ordering rules, null handling, list semantics, and normalization rules are identical or their differences are explicitly represented.
2.6 Normalization transparency
Normalization may remove noise, but it must not erase meaning. Whitespace normalization, Unicode normalization, case folding, URL canonicalization, timestamp conversion, and list sorting each require a declared rule and a field-specific justification.
2.7 Materiality ownership
A change detector may report a difference; it must not silently decide constitutional materiality. Materiality must be evaluated by named dimensions such as authority, jurisdiction, purpose, evidence class, revocation, stay, review, partition, restoration, or source independence.
2.8 Added and removed fields
Field addition and field removal are typed events. Absence must not be treated as a null value unless the schema defines that equivalence.
2.9 Unknown preservation
Unknown, unavailable, not retained, not checked, and not observed are distinct. The comparison result must preserve the specific reason a conclusion cannot be reached.
2.10 Source unavailability
An unavailable source does not imply unchanged content, supersession, deletion, or failure. It produces a source-unavailable state with a review obligation.
2.11 Time-window and clock basis
The capture time, declared publication time, authority-validity time, and local clock basis may differ. A system must not use a transport timestamp as proof that authority was current.
2.12 Downstream dependency propagation
A material source change must identify dependent claims, decisions, receipts, simulations, and derived representations. Correction is incomplete while known dependencies remain stale and unmarked.
3. Typed temporal results
Concresca uses result classes that preserve both what was found and what the method permits.
- UNCHANGED_VERIFIED: Exact comparable inputs were evaluated and no difference was found within the declared boundary.
- CHANGED_MATERIAL: A comparable difference affects one or more named material dimensions.
- CHANGED_NONMATERIAL: A comparable difference exists but does not affect the named material dimensions under the declared reviewer rule.
- FIELDS_ADDED: The new capture contains fields absent from the baseline.
- FIELDS_REMOVED: The new capture omits fields present in the baseline.
- BASELINE_INCOMPARABLE: Identity, capture scope, normalization, or version semantics do not support direct comparison.
- SOURCE_UNAVAILABLE: The target could not be captured under the approved method.
- NOT_REOBSERVED: No new capture was attempted or authorized.
- UNKNOWN: The available evidence does not support a more specific result.
The result vocabulary prevents the dangerous fallback in which every non-error becomes “no change.”
4. Baseline lineage
A baseline is not merely a hash. It is a lineage record containing:
- the artifact identity;
- the source release or capture;
- the target release or capture;
- the exact comparison boundary;
- the prior and current digests when exact bytes exist;
- the comparison contract applied;
- the result class;
- the material dimensions reviewed;
- limitations and unavailable information;
- the reviewer or deterministic tool identity.
v0.18 performs exact local comparisons for repository-owned artifacts that were present in the v0.17 package and remain present in v0.18. These include the Constitutional Interoperability Protocol Registry, Protocol Lab, DOC-051, and protected brand masters. The result is bounded to exact local bytes. It does not represent a new external observation.
New v0.18 registries receive baseline-established records with no invented prior capture.
External v0.17 artifact observations are retained as prior public-artifact baselines. v0.18 does not claim a second external capture and therefore does not infer external doctrine drift.
5. Proof-carrying restoration
Restoration must be represented as a state machine with forbidden shortcuts.
5.1 States
- DISCONNECTED: Transport is unavailable or the node is isolated.
- RECONNECTED_UNTRUSTED: Transport is available, but no authority or history conclusion follows.
- HISTORY_COLLECTED: Relevant local, remote, and archival histories have been collected or explicitly marked unavailable.
- CONFLICTS_CLASSIFIED: Agreements, differences, contradictions, unknowns, and supersession claims are typed.
- AUTHORITY_REVALIDATED: Issuer, jurisdiction, purpose, scope, validity, revocation, stay, and delegation chain are current or explicitly unavailable.
- BASELINE_ATTESTED: Code, configuration, data, model or policy, evidence, and clock conditions satisfy the declared restoration profile.
- LIMITED_RESTORATION: Only the minimum explicitly authorized function is available while residual conditions remain.
- FULL_RESTORATION: All required proof obligations and human-review gates for the profile pass.
A direct transition from DISCONNECTED or RECONNECTED_UNTRUSTED to FULL_RESTORATION is prohibited.
5.2 Proof obligations
The v0.18 registry defines twenty-four obligations across identity, artifact integrity, authority, purpose, evidence, version, revocation, stay, partition history, contradiction, reconciliation, baseline attestation, software/configuration, data, model/policy, time, reviewer independence, least-irreversible action, audit continuity, human legibility, downstream correction, rollback, residual risk, and release authority.
Each restoration profile is conjunctive. A failure in authority cannot be compensated by stronger availability, and a missing reconciliation receipt cannot be offset by a clean software hash.
5.3 Proof bundles
A proof bundle is a typed package, not an undifferentiated readiness score. It contains:
- artifact references and exact digest boundaries;
- authority credentials and validity evidence;
- revocation and stay queries;
- competing partition histories;
- conflict classifications;
- baseline attestations;
- reviewer identity and independence state;
- human explanation and machine reason codes;
- residual unknowns;
- allowed limited function;
- rollback target;
- downstream correction state;
- release decision and receipt identifiers.
A bundle may be complete for limited restoration and incomplete for full restoration. That distinction must remain visible.
6. Contested partition histories
A partition produces histories, not a single automatic truth. One compartment may record a grant while another records a revocation. One may have a newer policy version but an older authority credential. A transport layer may reconnect before an archive, reviewer, or identity service is available.
Concresca v0.18 publishes twenty-four analytical cases across eight families:
- authority grant versus revocation;
- stay versus continued execution;
- evidence acceptance versus later contradiction;
- configuration and software divergence;
- model or policy divergence;
- clock and expiry disagreement;
- reviewer and appeal divergence;
- downstream correction divergence.
Each case preserves:
- History A and History B;
- facts both histories support;
- contested facts;
- unavailable evidence;
- unsafe resolution shortcuts;
- required proof obligations;
- minimum allowed state while unresolved;
- a human-facing question;
- an unexecuted actual-result field.
The purpose is not to choose a winner in advance. The purpose is to prevent the first reconnecting node, the highest-capability node, or the newest timestamp from silently acquiring constitutional priority.
7. Reconciliation rules
Reconciliation is not a merge operation that must always terminate in one canonical history. Valid outcomes include:
- one history is supported and the other is superseded with preserved provenance;
- both histories are valid within different jurisdictions or purposes;
- a contradiction remains unresolved and full restoration stays blocked;
- a temporary limited-function state is authorized;
- the evidence is insufficient and the result remains unknown;
- a human or institution with current authority issues a reviewable resolution;
- downstream claims are invalidated pending correction.
The register forbids “last writer wins,” “highest uptime wins,” “most capable node wins,” and “transport success equals authority success” as default constitutional rules.
8. Restoration receipts
A restoration receipt must answer both machine and human questions.
Machine-facing fields
- stable receipt ID and schema version;
- receipt type and lifecycle state;
- artifact and authority references;
- digest algorithms and boundaries;
- prior and current states;
- proof-obligation results;
- unresolved conflicts and unknowns;
- allowed function and prohibited function;
- rollback target;
- dependency invalidation set;
- reviewer and release-authority identifiers;
- timestamps and clock basis.
Human-facing fields
- What happened?
- What changed?
- Which authority is being relied on?
- Was anything revoked or stayed?
- Which histories disagree?
- What evidence is missing?
- What can the system do now?
- What remains prohibited?
- Who can challenge or review the decision?
- What would invalidate this receipt?
v0.18 publishes receipt templates only. It does not fabricate production restoration events.
9. Human-legibility evaluation
Human legibility cannot be collapsed into a single readability number. A polished explanation can still hide a stale authority credential or omit a contested history. v0.18 therefore uses dimension-specific hard gates.
The eighteen dimensions include:
- subject and action clarity;
- authority issuer and chain;
- jurisdiction and purpose;
- validity, expiry, revocation, and stay;
- evidence provenance and class;
- synthetic versus operational status;
- temporal baseline and change scope;
- contradiction and unknown visibility;
- partition state;
- restoration state;
- allowed and prohibited function;
- reviewer independence;
- challenge and appeal path;
- correction propagation;
- reason-code explanation;
- accessible structure;
- plain-language summary;
- machine/human parity.
Each dimension has a positive and negative fixture. The fixtures define expected results but retain actual_result: null until an identified interface or study is evaluated.
No compensatory score is allowed. Failure to disclose revocation cannot be offset by excellent typography. Failure to provide an appeal path cannot be offset by concise prose.
10. Invalidation propagation
A proof or receipt remains valid only while its dependencies remain valid. v0.18 defines invalidation triggers including:
- artifact identity mismatch;
- raw or selected-field digest mismatch;
- schema or capture-scope change;
- authority expiry or revocation;
- newly discovered stay;
- jurisdiction or purpose mismatch;
- source correction or supersession;
- unresolved contradictory history;
- software/configuration drift;
- data-set or evidence-set drift;
- model or policy version drift;
- clock uncertainty;
- reviewer conflict;
- missing archive or identity service;
- correction-propagation failure;
- human/machine representation mismatch;
- failed accessibility or legibility gate;
- rollback-target unavailability;
- residual-risk change;
- release-authority withdrawal.
Invalidation must identify scope. A source correction may invalidate one claim, one receipt, a family of derived decisions, or an entire restoration profile. It must not silently delete the prior record; the prior record remains preserved as invalidated history.
11. Deterministic local property run
v0.18 executes a repository-local conformance run against exact Concresca source registries. The run is reproducible from the published script and recorded input hashes.
The run checks, among other things:
- uniqueness and reference integrity of artifact, property, observation, and temporal-contract identifiers;
- truthfulness of exact local raw hashes;
- absence of raw remote-response hash claims for uncaptured external artifacts;
- separation of test definitions from executed results;
- completeness of temporal comparison contracts;
- exact local baseline lineage;
- prohibition of direct reconnect-to-full-restoration transitions;
- conjunctive restoration proof obligations;
- required revocation, stay, freshness, and reconciliation gates;
- human/machine fields in restoration receipts;
- preservation of competing partition histories;
- paired legibility fixtures with unexecuted actual-result fields;
- invalidation propagation fields;
- explicit unknown and cross-project authority boundaries.
The run can pass while every external interoperability and production claim remains unobserved. Passing means the local published registries satisfy the named checks. It does not certify the truth or effectiveness of an external system.
12. Relationship to v0.17
v0.17 established a first selected-field public-artifact baseline, formal properties, bounded observations, reconciliation records, partition/restoration cases, and human-legibility prototypes.
v0.18 does not pretend that the passage from v0.17 to v0.18 automatically creates a second external observation. Instead, it does three things:
- It performs exact longitudinal comparison only where the repository owns both byte sequences.
- It labels external artifacts as not reobserved in this release rather than inferring unchanged doctrine.
- It deepens the method required before future external longitudinal findings can be published.
This separation is central. A release can advance methodology without claiming that the world changed.
13. Failure modes the framework is designed to expose
False unchanged
Two different capture scopes produce the same retained values and are labeled unchanged.
Digest laundering
A selected-field digest is presented as though it authenticated a full remote response body.
Reconnection laundering
A restored transport channel silently restores cached authority.
Timestamp supremacy
The newest timestamp is treated as constitutionally authoritative despite clock uncertainty or invalid issuer authority.
Capability supremacy
The most capable node or model resolves a dispute because it can, not because it is authorized.
History erasure
A losing partition history is deleted rather than preserved as evidence.
Compensatory readiness
Availability, performance, or clean code compensates for failed authority, revocation, reconciliation, or human-review gates.
Explanation theater
A fluent summary obscures missing evidence, disputed history, or a blocked restoration state.
Correction without propagation
A source record is corrected while dependent claims, decisions, caches, and receipts remain stale.
Local conformance inflation
A repository test pass is advertised as external certification, production safety, or live interoperability.
14. Public machine interfaces
v0.18 publishes exact read-only interfaces for:
- temporal comparison contracts;
- baseline lineage;
- local property run records;
- restoration proof obligations and profiles;
- restoration receipt templates;
- contested partition histories;
- legibility evaluation dimensions and fixtures;
- invalidation triggers and propagation rules.
The public HTML pages explain the same boundaries in human-readable form. Machine representations do not outrank canonical explanatory context when interpretation is required.
15. Decision consequences
The framework creates several practical decision rules.
- Do not claim a material change before comparability is established.
- Do not claim unchanged content when no new capture occurred.
- Do not restore full authority merely because transport returned.
- Do not merge conflicting histories by convenience.
- Do not treat human legibility as optional after machine validation.
- Do not allow a readiness score to compensate for a failed constitutional gate.
- Do not issue a restoration receipt without an invalidation route.
- Do not let a local conformance pass imply external or production assurance.
16. Open questions
The release does not resolve several research questions:
- How should materiality ownership be distributed across human institutions and machine validators?
- Which proof obligations can be independently reproduced without exposing protected evidence?
- How should privacy-preserving partition histories prove relevance without disclosing unrelated data?
- What minimum human-legibility evidence is required for people with different language, disability, expertise, and stress conditions?
- How should restoration proceed when the authorized reviewer institution itself is partitioned or contested?
- How should long-duration systems handle authority whose issuing institution no longer exists?
- What evidentiary threshold is needed before a deterministic synthetic demonstration can support a production claim?
These remain open by design. Unknowns are part of the state, not defects to be hidden.
Conclusion
Temporal integrity is the discipline of proving that a comparison means what it appears to mean. Proof-carrying restoration is the discipline of proving that recovered capability is accompanied by current authority, reconciled history, attested baseline, bounded function, human review, and an invalidation path.
Together they block a dangerous equivalence chain:
reconnected ≠ reconciled ≠ reauthorized ≠ restored ≠ certified
v0.18 makes that chain explicit in public registries, analytical cases, receipt templates, legibility tests, and a bounded reproducible local run. It strengthens Concresca’s own technical-governance architecture while preserving the decisive evidence boundary: no live shared protocol, production restoration, external adoption, external recognition, or independent certification is claimed.
