Status: CANDIDATE · AUTHORITY NONE · IMPLEMENTATION HOLD
Date: 2026-08-09
Repo reconnaissance base: thelaplage/counterpedia main d0ef484eafc84148277c1d81dd1ac600d0449cdc
Initial proving fixtures: USB-C / Thunderbolt compatibility + Warbling Vireo classification reprojection

0. PURPOSE

The Quiet Utility Corpus established six different knowledge computations.

The next step is not another research dossier.

It is to prove that Counterpedia can take governed, admitted input propositions and produce a deterministic derived relationship without allowing the derivation itself to acquire admission authority.

The first two proving families are deliberately different:

USB-C
capabilities + requirements
        ↓
compatibility projection

Warbling Vireo
immutable observation + taxonomy edition + conversion rule
        ↓
classification projection

The implementation target is therefore not one generic answer() engine.

It is a small shared derivation envelope plus typed derivation families.

1. EXISTING REPO DOCTRINE TO REUSE

Current Counterpedia already demonstrates two load-bearing patterns.

1.1 Pure projection is disposable and non-authoritative

The current activityPublicProjection.ts contract says, in substance:

• projection has one admitted input pool;

• projection is deterministic;

• projection is not the canonical receipt;

• projection is not a source of truth;

• projection derives no standing/trust score;

• invalid input fails closed.

Quiet Utility should reuse that posture.

1.2 Deterministic evaluation is never governance authority

Current compositionIntake.ts explicitly separates:

deterministic evaluation
        ≠
admission authorization

An eligible result changes no lifecycle state.

Quiet Utility must preserve the same separation:

derivation result
        ≠
admitted claim
        ≠
published composition

A derived result may become input to a later governance/admission lane, but it cannot self-admit.

2. CANDIDATE COMMON ENVELOPE

Proposed family name:

counterpedia.derivation-result/v0.1

CANDIDATE ONLY. Do not implement this schema name until ratified.

Conceptual shape:

{
  "schema": "counterpedia.derivation-result/v0.1",

  "derivation_id": "...",
  "derivation_kind": "...",
  "rule_version": "...",

  "evaluated_at": "...",
  "valid_at": "...",

  "inputs": [
    {
      "input_ref": "...",
      "input_kind": "admitted_claim|observation|edition|rule",
      "input_digest": "sha256:..."
    }
  ],

  "context": {},

  "result": {},

  "basis_claim_refs": [],
  "limitations": [],
  "reopening_requirements": [],

  "deterministic": true,
  "authority_effect": "none",
  "standing_effect": "none"
}

The envelope is intentionally thin.

Typed families own the meaning of:

context
result

There is no universal verdict vocabulary.

3. HARD INVARIANTS

D-01 — DERIVATION NEVER ADMITS

A successful derivation must not:

• create an admitted claim;

• change claim standing;

• alter a refusal;

• mutate a source;

• mint a SourceEdition;

• authorize publication;

• self-declare public truth.

Required posture:

authority_effect = none
standing_effect = none

D-02 — INPUTS ARE EXACTLY BOUND

Every authority-relevant input must be identified and digest-bound.

No hidden ambient inputs.

A derivation result must be reproducible from:

typed inputs
+
rule version
+
context

D-03 — SAME INPUTS + SAME RULE = SAME SEMANTIC RESULT

Timestamps/ids may differ where operationally necessary, but the semantic result must be byte-reproducible under an explicitly defined canonical projection.

No network calls.

No model calls.

No wall-clock-dependent classification logic except when valid_at is an explicit input.

D-04 — UNKNOWN IS FIRST-CLASS

Missing required input never becomes inference-by-analogy.

Return a typed unresolved result.

D-05 — DERIVATION FAMILY OWNS ITS OUTPUT VOCABULARY

No global:

true
false
maybe

verdict enum.

Compatibility and taxonomic reprojection require different semantics.

D-06 — HISTORICAL INPUTS ARE NOT REWRITTEN

A later taxonomy or compatibility computation creates a new projection.

It never mutates:

• original observation label;

• source claim;

• previous derivation result;

• historical product specification.

D-07 — READER PROJECTION IS DOWNSTREAM

The derivation artifact can contain machine-facing detail.

Reader wording is a separate projection.

Example:

machine:
  video_transport = unsupported

reader:
  "No — this cable does not support the display video path."

The reader surface must not add stronger semantics.

4. FAMILY 1 — COMPATIBILITY INTERSECTION

Candidate derivation kind:

counterpedia.compatibility.intersection/v0.1

This is not a schema namespace decision yet; it is the proposed derivation-family identifier.

4.1 Inputs

Typed admitted propositions such as:

host capability
target requirement
intermediate capability
numeric ceiling
object-version identity

Example fixture:

MacBook Pro M3 Pro 2023
Studio Display 2022
Cable A = Apple 240W USB-C Charge Cable

4.2 Result shape

Conceptually:

{
  "dimensions": [
    {
      "dimension": "physical_connector",
      "outcome": "compatible",
      "basis": ["..."]
    },
    {
      "dimension": "video_transport",
      "outcome": "incompatible",
      "basis": ["..."],
      "limiting_input_ref": "..."
    },
    {
      "dimension": "power",
      "outcome": "compatible_with_ceiling",
      "effective_ceiling": {
        "value": 96,
        "unit": "W"
      },
      "limiting_input_ref": "..."
    }
  ],
  "overall_for_requested_use": "incompatible"
}

Closed family vocabulary candidate:

compatible
incompatible
compatible_with_ceiling
unknown
not_applicable

This vocabulary belongs only to this family.

4.3 Numeric limiting-factor rule

For a dimension expressed as compatible ceilings:

effective_ceiling
=
min(all applicable admitted ceilings)

No value may be supplied if an input ceiling required for the requested inference is unknown.

4.4 Categorical capability rule

Conceptually:

required_capabilities ⊆ available_capabilities

If a required capability is explicitly absent:

incompatible

If its presence/absence is unresolved:

unknown

Never infer a protocol from connector shape.

5. USB FIXTURE — EXPECTED DERIVATIONS

USB-D1 — 240W Charge Cable

Expected semantic result:

connector:
  compatible

video_transport:
  incompatible
  reason:
    cable explicitly lacks video

power:
  compatible_with_ceiling
  published topology ceiling:
    96W from Studio Display

overall requested use:
  incompatible

Limit:

Do not claim empirical runtime charging behavior through this exact failed-video topology unless independently observed.

USB-D2 — Thunderbolt 4 Pro Cable

Expected semantic result:

connector:
  compatible

transport:
  compatible

video:
  compatible

power:
  compatible_with_ceiling
  effective published ceiling:
    96W
  limiting component:
    Studio Display

overall requested use:
  compatible

USB-D3 — UNKNOWN REGRESSION

Remove the admitted cable-video proposition.

Expected:

video_transport:
  unknown

overall:
  unknown

Not:

compatible because USB-C

6. USB SWAP INVARIANT

Given:

Host H
Target T
Cable A

derive result A.

Then replace only:

Cable A → Cable B

Expected:

• H source claims unchanged;

• T source claims unchanged;

• Cable A claims unchanged;

• Cable B claims unchanged;

• previous result preserved;

• new result created;

• result changes because one input reference/digest changed.

This is the flagship proof that Counterpedia is composing facts rather than rewriting them.

7. FAMILY 2 — CLASSIFICATION REPROJECTION

Candidate derivation kind:

counterpedia.classification.reprojection/v0.1

7.1 Inputs

immutable observation
taxonomy authority
taxonomy edition
taxon concepts
conversion rule
supporting observation evidence

The original observation's authored label is not an output field to overwrite.

7.2 Result shape

Conceptually:

{
  "observation_ref": "...",
  "taxonomy": {
    "authority": "...",
    "edition": "..."
  },
  "projection": {
    "outcome": "assigned",
    "taxon_concept_ref": "...",
    "display_name": "...",
    "scientific_name": "..."
  },
  "conversion_basis": {
    "kind": "geography|song|morphology|explicit_crosswalk|unresolved",
    "rule_ref": "..."
  }
}

Family vocabulary candidate:

assigned
ambiguous_pair
unresolved
not_in_scope

8. BIRD FIXTURE — EXPECTED DERIVATIONS

BIRD-D1 — British Columbia historical record under eBird/Clements v2024

Immutable observation:

observed_label:
  Warbling Vireo

Projection under the 2024 broad concept:

assigned
→ Warbling Vireo
→ Vireo gilvus [broad pre-split concept]

BIRD-D2 — Same observation under eBird/Clements v2025

Using the admitted geographic conversion rule:

assigned
→ Western Warbling Vireo
→ Vireo swainsoni

Required provenance:

this is a later projection
NOT the observer's original identification string

BIRD-D3 — Same observation under AviList v2025b

Expected authority-scoped projection:

assigned
→ current AviList broad Warbling Vireo concept

Do not silently import the AOS/eBird split into AviList.

BIRD-D4 — Ambiguous migrant under post-split taxonomy

Observation lacks enough evidence to choose eastern vs western.

Expected:

ambiguous_pair
→ Eastern/Western Warbling Vireo

Not:

randomly assigned

Not:

historical observation invalid

9. TAXON-CONCEPT IDENTITY INVARIANT

Scientific-name string must never serve as the sole taxon identity.

Regression:

Vireo gilvus [broad pre-2025]

must not equal:

Vireo gilvus [narrow Eastern post-split]

even though the scientific-name string matches.

Required identity inputs include:

authority
edition
circumscription
lineage

10. PROPOSAL LIFECYCLE IS NOT CLASSIFICATION

AviList's issue queue must not become current taxonomy.

Required distinction:

proposal under consideration
        ≠
published checklist concept

A reprojection engine may only use the selected published taxonomy edition unless a caller explicitly requests a prospective/candidate view.

Prospective view must be marked non-current.

11. SHARED IMPLEMENTATION SHAPE

If ratified, implementation should be additive and small.

Proposed location:

lib/counterpedia/derivations/

Potential files:

types.ts
canonical.ts
compatibilityIntersection.ts
classificationReprojection.ts

Tests:

tests/quietUtilityCompatibilityDerivation.test.ts
tests/quietUtilityClassificationReprojection.test.ts

No reader cutover in the first implementation lane.

No live corpus admission in the first implementation lane.

Use synthetic/admitted-like fixtures only until the exact source/capture/SRC1 chain is available.

12. DO NOT PUT THIS IN COUNTERPEDIA CONTENT SCHEMA v0.2

counterpedia.content/v0.2 is a publication/content representation.

The current contract already supports claim anchors, epistemic markers, tables, galleries and other presentation/content structures.

A derivation engine is a different concern.

Do not add compatibility or taxonomy execution semantics to content blocks.

Instead:

governed claim/source graph
        ↓
derivation
        ↓
later admitted claim/composition
        ↓
counterpedia.content/v0.2

This keeps reader grammar separate from reasoning semantics.

13. DO NOT PUT THIS IN CAP1 / INGEST

Acquisition:

what bytes were observed?

Ingest:

what deterministic extraction came from those bytes?

Quiet derivation:

what follows from already-governed propositions under a named rule?

These are three distinct derivation domains.

No compatibility computation in counterpedia-acquisition.

No taxonomy adjudication in dagr-ingest.

14. RELATION TO RECORD-PACKAGE HALF B

The record-package candidate's Half B is derived from governed state.

A derivation result can eventually appear in Half B only as a projected consequence of the graph.

Conceptually:

Half A
  research question:
    "Will these products work?"
        ↓
captures / ingest / SRC1 / ADJ1
        ↓
admitted component facts
        ↓
Quiet derivation
        ↓
admission/governance of derived proposition
        ↓
COMP1
        ↓
Half B

No hand-authored compatibility result in Half B.

15. RELATION TO AMNESIAC / COLLIDE

Quiet derivation does not replace COLLIDE.

Example:

Counterpedia current taxonomy projection:
  Western Warbling Vireo

Amnesiac memory:
  "I recorded Warbling Vireo in 2024"

COLLIDE:
  likely aligned / superseded-basis relationship depending exact objects

The observation's historical label and the public current classification can coexist.

Quiet derivation supplies a public graph proposition.

COLLIDE describes a relationship between public/private epistemic state.

16. NEGATIVE MATRIX — SHARED

QD-N1

Missing required admitted input.

Expected:

UNKNOWN / unresolved

Never guess.

QD-N2

Input digest differs from bound digest.

Expected:

FAIL CLOSED

QD-N3

Unknown derivation kind.

Expected:

REJECT

QD-N4

Unknown rule version.

Expected:

REJECT

QD-N5

Caller sets standing_effect != none.

Expected:

INVALID

QD-N6

Caller sets authority_effect != none.

Expected:

INVALID

QD-N7

Same semantic inputs presented in different array order.

Expected:

same canonical semantic result

where the family declares input order non-semantic.

QD-N8

Projection contains undeclared ambient source.

Expected:

INVALID / impossible by API shape

17. NEGATIVE MATRIX — USB

USB-N1

Same connector only → unknown, not compatible.

USB-N2

240W higher than 100W → must not rank cable globally.

USB-N3

Missing video capability → unknown.

USB-N4

Explicit no-video → incompatible for display path.

USB-N5

Power ceiling result must identify limiting input.

USB-N6

Swap one cable → new result; old result immutable.

18. NEGATIVE MATRIX — BIRD

BIRD-N1

Same name string, different circumscription → distinct taxon concepts.

BIRD-N2

Later taxonomy must not rewrite observed label.

BIRD-N3

Pending AviList proposal must not act as current edition.

BIRD-N4

Ambiguous evidence → ambiguous_pair, not forced assignment.

BIRD-N5

eBird conversion rule must not leak into another authority.

BIRD-N6

Projection must bind authority + exact edition.

19. READER PROOF — DEFERRED BUT DEFINED

The first code lane should stop before UI.

Later reader demo A:

USB-C configuration
  [swap cable]
  ↓
result recomputes

Later reader demo B:

Warbling Vireo observation
  [taxonomy slider]
  [authority selector]
  ↓
classification projection changes

The reader should expose Why? as input/basis traversal, not generated rationale.

20. RATIFICATION QUESTIONS

Before implementation, operator must decide:

1. Is one common counterpedia.derivation-result/v0.1 envelope desirable, or should the two families remain fully separate contracts?

2. Does derivation_id become a canonical cp:* identity later, or remain content-addressed / externally scoped?

3. Are input digests mandatory for all input refs, or may canonical immutable graph editions supply equivalent identity?

4. Does valid_at belong in the common envelope or only temporally sensitive families?

5. Should derived results themselves enter ADJ1 as candidate claims, or should a separate DerivedClaimProposal projection mediate that handoff?

6. Which component owns the family/rule-version registry?

7. What exact canonicalization algorithm binds deterministic result bytes?

8. Should reopening_requirements live on derivation results, or be projected only when outcome is unresolved?

Until these are answered:

AUTHORITY NONE
IMPLEMENTATION HOLD

21. RECOMMENDED RATIFICATION DISPOSITION

The safest first ratification is narrow:

RATIFY:
  derive-first / admit-separately doctrine
  two typed proving families
  no standing/authority effect
  exact input binding
  deterministic / no network / no model
  immutable observations/sources
  UNKNOWN first-class

HOLD:
  generic schema identifier
  canonical derivation IDs
  registry ownership
  ADJ1 handoff object
  reader cutover

This would permit a synthetic implementation proving the computation without prematurely ratifying a universal derived-knowledge schema.

22. ACCEPTANCE TARGET FOR FIRST CODE LANE

A successful first code lane proves exactly:

USB:
  same governed object facts
  + Cable A
  → incompatible

  same governed object facts
  + Cable B
  → compatible

Bird:
  same immutable observation
  + taxonomy edition A
  → projection A

  same immutable observation
  + taxonomy edition B
  → projection B

and in all four cases:
  no source mutated
  no observation mutated
  no standing mutated
  no admission occurred
  same inputs/rule reproduce same semantic result

That is enough to establish the Quiet Utility execution primitive.

23. PROGRAM THESIS

Counterpedia should not merely store conclusions. It should preserve the governed inputs and the named deterministic rule that make a conclusion reproducible.

For contested evidence, Counterpedia preserves why certainty stops.

For ordinary utility, Counterpedia can additionally show:

what follows — and exactly why it follows — without giving computation the authority to govern itself.