Reflective coverage is graded across representational forms

Type: kb/types/note.md · Tags: foundations, computational-model, constraining, self-improving-systems

A reflective system's behavior can be carried by several kinds of artifact at once. Its system-definition artifacts — the artifacts it consumes with binding force — may take any representational form: prose interpreted by models and humans, symbolic structures with formal consumers, distributed-parametric state such as model weights. Where they span forms, reflective reach must span them too: a behavior bound by an artifact whose form the self-representation does not cover is outside that reach, however thoroughly the other forms are covered.

That need cannot be assessed all-or-nothing. Reflective coverage is relative to the declared aspects and operations, and it grades — by which forms the self-representation spans, and by what the system can do to each covered component.

Two dimensions grade coverage

Form coverage asks which forms' aspects enter the self-representation at all. Operation depth asks what processes inside the boundary can do to a covered component. Four operations, ordered by how far into the component they reach:

  1. Observation — the component can be read or probed, and what is learned is available inside the boundary.
  2. Selection — the system can swap one sealed component for another without seeing inside either. A skill pinning model: opus selects among sealed alternatives and reaches nothing finer.
  3. Configuration — the component exposes parameters the system can set, within an interface it did not author. Commonplace's skill frontmatter does this to the harness: allowed-tools: Read, Write, Grep, Glob, Bash, Skill and context: fork set the tool surface and context regime for a skill run, through a schema the harness owns. The system can set those fields and cannot inspect or edit the machinery that honours them.
  4. Modification — the substrate itself can be edited from inside the boundary. Editing kb/types/tag-readme.md changes what the validator enforces, because the spec's own path is the validator's dispatch key.

The four are ordered but not nested, and the difference matters when a claim is being made. Deeper reach does not confer shallower reach: selection operates over components it cannot observe — that is what makes them sealed — and configuration through a vendor's schema grants no ability to swap the vendor out. So a coverage claim states which operations hold over a given component, not a single number. The ordering is useful for saying what a lever does not reach; it is not a licence to infer the lower rungs from the higher one.

Depth is also per component rather than per form. The two instances above sit over different components — selection over the weights, configuration over the harness — and both components are outside the declared boundary in the case classification. Nothing in this repository configures the parametric form itself.

Nor does either dimension imply the other, or any form inherit from another. The instructive case pairs modification depth on prose and symbolic artifacts with selection depth on a parametric component: an agent system whose instructions can require a particular model, or a class of models, exercises real intercession over its distributed-parametric form — the choice of weights is represented, causally connected, and revisable by the system's own processes — yet nothing inside the boundary can inspect or edit what the weights do. Calling this "no reflection over the model" misses the lever that exists; calling it "reflective coverage of the weights" overstates what the lever reaches. It is selection-grade coverage of the parametric form, and should be claimed as exactly that.

Two corollaries. The obvious evidence is not evidence: that one agent can edit both Markdown and Python establishes neither that those artifacts form a self-representation nor that changes to them reach later operation through a causally connected path. And depth describes a design without ranking it — a fixed mapping held at shallow depth can be the correct choice, as the kernel-boundary discussion below shows. Each covered form brings its own verification obligation besides: read prose, test symbolic artifacts, probe parametric ones behaviorally.

Mapping coverage is not mapping modifiability

Three properties must remain distinct. Mapping coverage asks whether a supported observation or intervention is reliably realized across the boundary. Mapping inspectability asks whether the system can examine how the transfer works. Mapping modifiability asks whether the system can change it. A trusted compiler may sit in an unmodifiable kernel and still preserve full reflective coverage of a desired-state aspect — provided the declared interface exposes its semantics and its relevant failures.

The properties come apart in practice. Commonplace's type-spec-to-validator mapping is unusually well covered: the validator dispatches on the spec's own path (@type_rule("kb/types/tag-readme.md")), so a prose spec and the code enforcing it cannot drift silently — the specification file is the enforcement key. That is high mapping coverage bought by a naming convention, not by making the dispatch mechanism modifiable. Most other prose-to-code relationships in the same repository have no such binding, and there the mapping is uncovered: the prose can change with nothing to notice that the code no longer matches.

The demand rises only when a system claims to inspect or adapt the transfer itself. Then the mapping must enter the self-representation: its interface, authority rule, rationale-to-implementation lineage, codification boundary, or consistency mechanism. Declaring a terminal kernel keeps this from becoming an infinite demand to represent every mechanism that represents another mechanism.

Assessing a claim

Six questions establish what a coverage claim actually covers:

  • Represented aspects and operations: What can be observed or changed?
  • Transfer: What carries values, distinctions, or operations across the boundary?
  • Authority: Which representation governs when the two disagree?
  • Lineage: Which dependencies require invalidation, regeneration, or review after a change?
  • Consistency and failure: How are drift, rejected translations, and stale derivatives exposed?
  • Kernel boundary: Which interpreter, compiler, runtime, human practice, or learned substrate is fixed outside the reflective surface?

A worked pass

Keep lineage and compiled views from drifting gives source-of-truth rules for a memory system whose authored source renders into cues, prompt files, indexes, lint rules, and assistant-specific views. Put to the six questions:

  • Aspects and operations. Behavior-shaping knowledge — policies, conventions, cues; observation via provenance and version metadata, intervention directional: edit the source, then regenerate the view or mark it stale.
  • Transfer. A renderer with target-specific filtering — named, but not represented.
  • Authority. Answered, the rules' strongest item: the source governs; a compiled view is never a separate policy.
  • Lineage. Answered: a source change obliges regeneration or a staleness mark; direct edits to a view flow back to the source or stay candidate-stage.
  • Consistency and failure. Partial: staleness after a source change is covered; rejected translations are not — a source item that cannot render into a target can vanish silently.
  • Kernel boundary. Not declared: the renderer and the harness's context-loading mechanism sit outside the reflective surface, unnamed.

The pass separates cases the rules treat together — a policy rendered into an AGENTS.md excerpt stays prose, while a convention rendered into a lint rule crosses into symbolic form and acquires a formal consumer, the codification crossing where transfer can fail silently. And it locates the defect precisely: the renderer's non-modifiability is compatible with full coverage; what breaks the claim is the unexposed failure — filtering that can silently drop a policy for one target while keeping it for another.

Computational precedents

The analytical questions have computational precedents. Pattie Maes distinguishes procedural reflection, where implementation and self-representation share one operative representation, from declarative reflection, where explicit constraints must be kept consistent with procedural behavior (1988, printed p. 14; PDF p. 14) — which is why the representation best suited to implementation may differ from the one best suited to reasoning. Cross-language reflection supplies the precedent for spanning access: Roel Wuyts and Stéphane Ducasse make entity transfer explicit so each language can reason about and act on the other (2001, printed pp. 4–10; PDF pp. 4–10), and Kris Gybels and colleagues separate data mappings, which move values across a boundary, from protocol mappings, which make the receiving side's operations applicable to representations of those values (2006, printed pp. 110–112; PDF pp. 2–4).

What this establishes

Combining prose and code does not increase computational universality. The stronger and narrower claim is:

Combining representational forms extends reflective coverage over a system whose behavior is already distributed across them — and that coverage is graded: a claim must name the form and the operation depth, and no form inherits either from another.

Joint adaptation, movement between forms, and shared callable interfaces may support that coverage, but none of them establishes it without a causally connected self-representation. What this note supplies is a vocabulary and a graded coverage criterion. It does not, by itself, classify Commonplace or any other system.

Relevant Notes: