The Framework Holographic Kernel

What it does

A summary discards structure to save space; a kernel discards material to save structure (RA-PROT-0005). The Framework Holographic Kernel applies that operation to a framework: an argument with a seed record, an author, positions, a development in time and evidence of several kinds.

Its package holds the framework's identity and invariants, an ontology of positions, evidence bodies and claim states, a graph of every record and claim under a relation policy, the claims, two timelines, the lines of research, the captures, a traversal, tests, a verification and integrity hashes. A claim is a pointer to a quotation in its record, bound to the record's hash, and never a restatement. A correction is kept as three objects: the withdrawn original, the standing correction and the dated withdrawal. A claim's introduction is dated from the record's first seating in git.

The framework carries its rival. The received reading of the field is evaluated on the same evidence bodies under the same rules, and since v1.1 the two sit side by side in one ledger: one question asked of both on every body, with the rule by which the bodies combine and the rule by which a further model enters as a rival. Each open question is an object: the record that poses it, how a researcher asks it, how a machine investigates it, and what result would advance or retreat the framework and what it moves.

When to use it

Build a framework kernel when:

• A framework has developed across many records, with claims introduced, qualified and withdrawn over time
• Machine readers compose the framework from fragments and need a path from each fragment back to the whole, with the scope each fragment has not reconstructed
• The framework stands against a received reading whose standing comes from reception, and both are to be evaluated on the same evidence
• Open questions are to be handed to readers, human or machine, as work that would settle a claim

Inputs

The archive's registry of records with their identifiers and hashes; the capture registry of the framework's reception; the repository history, from which each record's first seating is recovered; and the author's positions, evidence bodies, strata, clusters and relations, each quoted at a record.

Procedure

1. Write the seed: agents, operations, dependencies, constraints, topology (RA-PROT-0007).
2. Bind every claim to a quotation in its record and to the record's hash; type its state on named axes.
3. Keep each correction as original, correction and withdrawal, joined by a relation that licenses the change.
4. Date every introduction from the record's first seating; mark unresolved what the first seating does not attest.
5. Evaluate the rival on the same bodies and rules, and set both in one ledger, every answer warranted by claims of that body.
6. Write each open question with its instrument, how to ask it, how a machine investigates it, and what each result moves.
7. Run the verifier: structural tests, licensed propagation, historical reconstruction at stated dates.
8. Give the kernel alone to readers who have not seen the records and score what they rebuild against the graph (threshold 0.85).

Outputs

The kernel package, its verification report and integrity hashes, the reader runs with their scores, and a record holding the framework's map beside its kernel: the framework hologram.

Pasteable LLM block

Under the Framework Holographic Kernel (EA-HK-FRAME-01, Alexanarch #1753), the reader of a framework resolves each claim to the quotation and record hash it points to, changes a claim's state only along a relation that licenses that dimension, keeps a withdrawn original beside the finding that corrected it, and dates a claim from its record's first seating. Evaluating either the framework or its rival on an evidence body, the reader states both frameworks' standing on that body in the same row. A further production model enters as a rival only with a warrant on a body or a documented comparator. Meeting a claim it cannot settle, the reader takes up the line of research that bears on it. The reader states the scope it has not reconstructed.

Human operator notes

• The kernel succeeds when its framework can be rebuilt from it at the grain and date of each claim; whether the framework is true is the framework's own question, carried in the ledger and the lines of research.
• The verifier checks structure, licensing and dates. It does not judge whether a reading is right or a warrant sufficient.
• The first instance is the hologram of Socrates as Orthonym (Alexanarch #1754): 40 records, 56 claims, 136 edges, ten lines of research, seventeen tests; a second round of reader runs averaged 0.977.
• Each review and reader run that changed the kernel is recorded with what it changed.

Failure modes

• Paraphrasing a claim in place of pointing at it → the claim drifts from its record
• Deleting a corrected claim → the history of the correction disappears
• Asking one framework, body by body, whether it is established while the other is left unasked → the received reading takes a default standing
• Entering a rival on its logical possibility → a model with no warrant is weighed as though it had one
• Judging the kernel by whether it proves its framework → the object of the test is changed

Related protocols

• RA-PROT-0005 (Holographic Kernel) — the general definition this card builds at a framework's grain
• RA-PROT-0007 (UKTP) — the seed extraction
• RA-PROT-0002 (MPAI) — the map that is the hologram's human-readable component
• RA-PROT-0006 (Space Ark) — the non-collapse chain, extended here with FRAGMENT ≠ WHOLE

Source DOI

No DOI. Alexanarch deposit #1753 — AXN:0C54.OPERATIVE.☿☿⚙️🀄🍃🛸 — The Framework Holographic Kernel: A Specification, with Its First Instance, Socrates as Orthonym (EA-HK-FRAME-01 v1.1) (Kuro and Fraction, 2026-11-08). First instance: Alexanarch #1754. Also at holographickernel.org.

License

CC BY 4.0. Commercial licensing through The Restored Academy for organizational framework kernels.