Skip to content

Governed Knowledge Projection Compiler v0.1 — candidate schema, invalidation, and receipts #8

Description

@hummbl-dev

Parent and dependencies

Status

CANDIDATE ARCHITECTURE AND REFERENCE-IMPLEMENTATION WORK PACKET — CLOSEABLE — NON-CANONICAL — NO PRODUCTION AUTHORITY

Objective

Define and implement the smallest auditable reference slice of a governed knowledge projection compiler.

Working description:

Transform revision-addressed evidence and claims into a human-readable, agent-queryable derived knowledge projection while preserving provenance, claim dependencies, compilation-loss tests, invalidation, authority posture, rollback, and transformation/execution receipts.

The working name is candidate terminology. This issue must not claim invention, patentability, canon status, or production readiness.

Governing distinction

The projection is not the evidence authority and not memory truth.

bibliography / source packets / evidence / claims
                    ↓
       governed compilation contract
                    ↓
       derived knowledge projection
                    ↓
       agent and human retrieval surface

The derived surface must remain traceable, invalidatable, and rebuildable from its declared inputs.

Required v0.1 invariants

  1. Source separation — source artifacts are referenced by immutable or revision-addressed locators and are not silently rewritten.
  2. Derived status — every projection unit is explicitly marked as derived.
  3. Claim-level provenance — material statements resolve to evidence and source locators, not merely page-level citations.
  4. Dependency tracking — derived claims record upstream claim/evidence dependencies.
  5. Invalidation propagation — source correction, revocation, supersession, or posture change identifies affected downstream projection units.
  6. Compilation-loss evaluation — the compiler tests for material omissions and unsupported compression.
  7. Authority separation — evidence posture, claim posture, projection posture, and write authority remain distinct.
  8. Reversibility — projections can be rebuilt, rolled back, or quarantined without mutating canonical evidence.
  9. Receipt honesty — transformation and execution receipts identify what was read, generated, changed, omitted, tested, and not verified.
  10. Human/agent readability — output is inspectable without requiring a proprietary database or opaque embedding store.

Candidate architecture

Input contract
  ├── bibliography_refs
  ├── source_packet_refs
  ├── claim_evidence_refs
  ├── source revisions and hashes
  ├── authority and privacy postures
  └── compilation policy

Compiler
  ├── validate inputs
  ├── extract or import atomic claims
  ├── build dependency map
  ├── synthesize projection units
  ├── attach provenance and posture
  ├── evaluate coverage and omissions
  ├── detect contradiction/supersession
  └── emit receipts

Projection
  ├── index/navigation
  ├── source pages
  ├── entity/concept/topic pages
  ├── claim views
  ├── contradiction and uncertainty views
  └── append-only or versioned operation log

Candidate schema elements

Reuse existing HUMMBL schemas by reference where possible. The reference slice should cover at least:

projection_id:
projection_version:
projection_status:
compiler_policy_version:
compiled_at:

inputs:
  bibliography_refs: []
  source_packet_refs: []
  claim_evidence_refs: []
  source_revisions: []

projection_unit:
  unit_id:
  unit_type:
  title:
  content_or_content_ref:
  derived_claims: []
  upstream_dependencies: []
  source_locators: []
  epistemic_posture:
  authority_posture:
  freshness:
  sensitivity:
  invalidation_state:
  supersession_refs: []

compilation_quality:
  required_claims: []
  preserved_claims: []
  omitted_claims: []
  unsupported_claims: []
  contradiction_findings: []
  coverage_result:

receipts:
  transformation_receipt_ref:
  execution_receipt_ref:
  review_receipt_refs: []

lifecycle:
  rebuild_from:
  previous_version_ref:
  rollback_ref:
  quarantine_reason:

Exact names remain candidate pending schema reconciliation.

Required implementation slice

Use a small public-safe corpus from the LLM Wiki prior-art workstream or another approved fixture. Implement:

  1. a minimal projection manifest/schema;
  2. a deterministic validator or validator stub, stdlib-first where practical;
  3. one valid fixture;
  4. invalid/adversarial fixtures;
  5. one compilation path that emits Markdown or another inspectable text projection;
  6. one dependency map from derived claim to upstream evidence;
  7. one invalidation event that marks affected projection content;
  8. one rebuild or rollback demonstration;
  9. compilation coverage and omission report;
  10. transformation and execution receipts.

LLM-assisted synthesis may be used in an experimental lane, but the validity, dependency, posture, and receipt checks must not depend solely on an LLM saying the output is correct.

Required adversarial fixtures

At minimum:

  • source removed after projection generation;
  • source corrected or superseded;
  • derived claim without a resolvable evidence dependency;
  • page-level citation masking an unsupported sentence;
  • high-confidence prose generated from low-authority evidence;
  • material source claim omitted during compression;
  • contradiction silently collapsed into one answer;
  • private source reference leaked into a public projection;
  • receipt presented as independent verification;
  • projection presented as canonical evidence;
  • rollback target missing or non-reproducible;
  • stale projection used after its review or freshness boundary.

Benchmark handoff

Produce a fixture and result contract consumable by:

The evaluation should compare, where feasible:

A. direct source inspection
B. conventional retrieval / RAG
C. ordinary compiled LLM wiki
D. governed knowledge projection

Measure separately:

  • factual precision;
  • retrieval and synthesis coverage;
  • unsupported and omitted claims;
  • claim-level citation validity;
  • contradiction handling;
  • invalidation correctness;
  • rebuild/rollback success;
  • latency, tokens, cost, and human correction effort;
  • receipt completeness and authority compliance.

Do not declare the governed projection universally superior.

Cross-repo contract requirements

The compiler must consume existing domain artifacts by reference under the candidate envelope in hummbl-governance#234. It must not copy or replace:

  • bibliography authority;
  • source-packet provenance;
  • claim-evidence semantics;
  • Evidence Graph artifacts;
  • verification or attestation records;
  • execution receipts;
  • CanonRegistry or publication maturity.

Deliverables

  1. Architecture note and explicit non-goals.
  2. Existing-schema crosswalk.
  3. Candidate projection schema/manifest.
  4. Validator or validator stub.
  5. Valid, invalid, and adversarial fixtures.
  6. Public-safe reference compilation.
  7. Dependency/invalidation demonstration.
  8. Compilation-loss/coverage report.
  9. Rollback/rebuild demonstration.
  10. Benchmark fixture and handoff.
  11. Independent adversarial review packet.
  12. AAR and bounded implementation receipt.

Acceptance criteria

  • Projection units are explicitly derived and do not become evidence authorities.
  • Every material derived claim resolves to upstream evidence or is marked unsupported.
  • Dependency and invalidation behavior is machine-checkable for the reference slice.
  • At least one material omission is detected by compilation-loss evaluation.
  • At least one source correction propagates to affected projection content.
  • Public/private and epistemic/authority postures remain distinct.
  • A projection can be rebuilt or rolled back from declared inputs.
  • Transformation and execution receipts are emitted and distinguish execution from verification.
  • The implementation consumes cross-repo artifacts by reference rather than copying authority data.
  • The benchmark contract can compare this approach with direct inspection, RAG, and ordinary wiki compilation.
  • Independent review challenges unsupported novelty, safety, privacy, and correctness claims.
  • Reuben approval is required before canonization, production adoption, default routing, public novelty claims, or a new repository.

Non-goals

  • Building a production knowledge platform.
  • Replacing RAG, search, knowledge graphs, or existing memory systems universally.
  • Connecting private Gmail, Slack, Notion, health data, or sensitive repositories in v0.1.
  • Creating a new repository before this home proves insufficient.
  • Publishing, patent filing, trademark filing, deployment, or default-route changes.
  • Treating schema validation as truth or independent corroboration.

Close condition

Close when the public-safe reference slice is committed and validated, adversarial fixtures behave as expected, dependency/invalidation and rollback are demonstrated, benchmark handoff is accepted, and the final receipt states whether the candidate should be advanced, revised, split, or rejected.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions