Case packet

Neutral case identifier: case-c299eb39a9c550

The possible directed relationship from Artifact A to Artifact B is under review.

Artifact A

Technical constraints turn KB objective-function choice from philosophy into engineering

A knowledge base optimizes something. Call it the KB's objective function: the loss its writing, connecting, and review are trying to minimize. Asked in the open — what knowledge is worth keeping? what does a good note maximize? — this is a rerun of epistemology, and it terminates in taste, not a decision. The claim here is that in an agent-operated KB the question does not stay open, because four concrete technical constraints set hard rules that delete most candidate objectives before any value judgment is made. What survives is a small, testable space, and choosing within it is engineering.

The constraints do not tell you what to value. They tell you what you cannot make the system optimize, which is most of what philosophy would otherwise argue about.

Why it would otherwise be philosophy

Absent constraints, "what should a KB keep" has the shape of every unbounded normative question: any answer is defensible in isolation, none is falsifiable, and the debate never closes because there is no cost to a bad answer. A KB with unlimited context, no code, an infinitely malleable reader, and free verification could optimize anything you could name — coherence-of-the-whole, aesthetic economy, comprehensiveness — and you would have no engineering reason to prefer one. The objective would be pure stipulation.

The constraints below remove exactly that freedom.

The four constraints that prune the space

1. Bounded context. The consumer attends to one finite window where everything competes, since [context efficiency is the central design concern in agent systems]. An objective that can only be evaluated by loading the whole corpus — global coherence, non-redundancy across all artifacts — is not optimizable by the consumer that runs the KB. This forces objectives that are locally checkable: what one artifact does when co-present with a handful of others, not what the graph does as a whole.

2. The codification option. Any part of an objective whose inputs are already known can be moved out of natural-language content and into a symbolic artifact with formal semantics — [codification]. What the move buys depends on the consumer, because codification changes an artifact's [representational form], never its authority family — a methodology theory is already a natural-language [system-definition artifact], consumed with instruction force. For that reflective content — the KB's own conventions, gates, and routing rules — codification hardens the enforcement channel of authority the artifact already holds: the argument "is this the right rule?" becomes "does the validator pass?", and compliance stops costing context and varying by session. For object-level knowledge artifacts — claims about the KB's domain rather than about its operation — codification hardens only the oracle: the claim becomes a runnable test of itself, gaining checkability without gaining force over the system. Whether to discharge a sub-objective in code or leave it to the LLM remains a tradeoff with a decision procedure (see [codify-versus-LLM heuristics]). The scope limit matters when generalizing: only content that is a self-representation of the KB's own operation has an enforcement channel to harden, so "settled by construction rather than by debate" covers a KB's methodology, not its domain content. Commonplace's object and reflective layers coincide — the methodology is the content — which makes this lever look more general here than it is in a domain KB.

3. The model's fixed lexicon and priors. You write the objective against a consumer that already assigns meanings to words and carries priors over what text means. You cannot redefine that substrate. A convention that fights the model's lexicon is expensive to enforce and degrades silently — the model reverts to its prior under load. So the objective has to be expressible in terms the model already discriminates reliably, which prunes exotic value schemes and private vocabularies the model cannot apply consistently. This is the consumer-inherited half of the constraint packet: pick an LLM reader and its lexicon comes along whole.

4. The verification boundary. [The boundary of automation is the boundary of verification]. Whatever objective you set, you can automate its optimization only as far as you can build an [oracle] for it; objectives you cannot verify stay manual or advisory. Verifiability is therefore a first-class engineering fact about a candidate objective, not an afterthought — it decides how much of the pursuit can run without a person, and what the remainder costs.

What it does not do is settle which objective to hold. Reading it that way — the cheaply scored option beats the one you merely believe is deeper — is how a proxy displaces the thing it stands in for, [since a property adopted as a goal is checked for achievement rather than for warrant], and a cheap score supplies the full signature of a verified objective while establishing nothing about whether it was worth adopting. This KB is the demonstration: the profile carrying its most valued content has the weakest oracle, as below, and that objective was kept anyway. The constraint prunes the space of objectives you can automate against; the choice within it stays a choice.

None of the four says what to value. Together they turn "what should a KB keep?" into "which locally-checkable, model-expressible, verifiable objective best serves the stated goal within one window?" — a question with testable answers and a cost for wrong ones.

The objective hierarchy: goals set the loss, contracts specialize it, profiles bundle it

The surviving objective is not monolithic. It is specialized down a three-level hierarchy, each level a narrower loss than the one above.

  • Global KB goals set the loss. The always-loaded control-plane goals — purpose, scope, quality bar — are the top-level objective every session optimizes against, and they decide inclusion before anything else does, since [KB goals in always-loaded context guide inclusion decisions]. This is the domain filter: it deletes off-scope material however well-written.

  • COLLECTION.md text contracts specialize the loss per collection. Each writable collection declares a quality goal in its [text contract] — the local objective its writers and reviewers treat as decisive. kb/notes/ optimizes explanatory-reach; kb/reference/ optimizes fidelity and economy; kb/instructions/ optimizes executability and precision. Same global goal, different residual loss per subtree.

  • Profiles are named, proven objective-function bundles. A [profile] is a pre-packaged objective a collection adopts, extends, or replaces wholesale — theoretical, descriptive, prescriptive are the shipped defaults, and the set is open and worked-case-gated. A profile is exactly what an optimization framework calls a loss template: a bundle of orientation, quality goal, and link grammar that has been shown to travel together (see [a knowledge base holds theories, descriptions, and prescriptions with asymmetric linking]).

The hierarchy is why objective choice is cheap in practice: a new collection rarely designs a loss from scratch, it adopts a proven bundle in one line and only writes a contract when no bundle fits.

Judge strength differs per profile

The payoff of specializing through profiles is that the same global goal lands on very different verification regimes. Oracle strength — how cheaply and reliably you can check correctness — is not uniform across the KB; it is a property of the profile.

  • Descriptive has the strongest oracle. The described system exists, so fidelity is checkable against ground truth: read the code, run it, compare the account to the referent. This is the closest a KB profile gets to a hard oracle, and it is why descriptive review can lean on mechanical checks.

  • Prescriptive has a behavioral oracle. An instruction's correctness is whether executing it produces the intended behavior. That is checkable by running the instruction against a controlled boundary and asserting on what it does, as in [unit testing LLM instructions by mocking the tool boundary]. The ground truth is the produced behavior rather than a fixed external referent — a medium-strength oracle, verifiable but only by execution.

  • Theoretical has the weakest oracle and must compensate with the widest judges. Reach — a claim's generality across contexts — has no ground truth to check against; no single test decides whether a claim is as general as it says. So the theoretical profile cannot harden the oracle and instead widens the judge: multiple decorrelated critics, falsifier attempts, cross-domain probing. This is why [error correction needs above-chance oracles and decorrelated checks] is load-bearing here — width of independent checking substitutes for the missing hard oracle. It is also why theoretical review is the most expensive and the least automatable.

That the profile with the weakest oracle (theoretical) carries the KB's most valued content (transferable claims) is the structural tension the whole review system is built around: the objective you most want to optimize is the one you can least cheaply verify.

Scope

  • The constraints are inherited, not universal. They arrive in the constraint packet of this framework's boundary commitments — an LLM consumer, a file substrate, a knowledge domain, the built machinery — so "engineering, not philosophy" is relative to those commitments, since [first principles are inherited constraints, not design choices]. A framework built on a different consumer inherits a different packet and a different pruned space. The value question is dissolved for this framework, not in general.
  • Pruning is not determination. The four constraints delete most candidate objectives; they do not select a unique survivor. Choosing among what remains — which quality goal, how much to codify, how wide a judge to fund — still takes judgment. The claim is that the residual is small and testable, not that it is a single point.
  • Per-profile oracle strength is a characteristic default, not a law. A theoretical note resting on one described system can borrow that system's oracle; a descriptive account of a system not yet built has no referent to check against. The dependency edge overrides the profile default.

Open Questions

  • Is the model's fixed lexicon a genuinely independent constraint, or a facet of the bounded-context/consumer commitment already covered by inheritance?
  • Can the theoretical profile's "widest judges" ever be hardened into a real oracle, or is explanatory-reach permanently a no-oracle objective — in which case the KB's central objective is structurally the one it can never fully automate?

Relevant Notes:

Artifact B

A knowledge base holds theories, descriptions, and prescriptions with asymmetric linking

Many knowledge bases repeatedly need three default text-contract profiles, each with a different quality priority:

Default profile What it does Quality priority Context-efficiency strategy Example query
Theory Makes transferable claims about what is true [Explanatory-reach] One claim covers many situations — compress across contexts "Why is X a good idea?"
Description Accounts for what exists in a particular system Fidelity + economy One account covers the system in minimum tokens — compress within a single context "How does X work here?"
Prescription Directs what to do or not do Executability + precision One instruction says exactly what to do — compress to what's actionable "How do I do X?"

These are recurring defaults, not a partition of all knowledge. A stance-neutral dialectical/evidential collection, for example, needs a different quality bar: faithful attribution of a live disagreement rather than the collection's own claim about what is true. [ADR 042] therefore makes the [profile] library open and worked-case-gated. A default earns its place when adopting the bundle saves repeated contract decisions and improves writing or review. A collection whose needs do not fit should write its own contract.

All profiles face bounded-attention pressure. In LLM-operated KBs, [context is the single scarce resource], so excess or ambiguous text directly competes with the next action. Reach, fidelity, economy, executability, and precision are not exclusive properties—every artifact benefits from several—but each profile identifies the failure its writers and reviewers should treat as decisive.

Why the profiles are useful

Formulation discipline. Commonplace's theoretical profile requires a claim to stand without reference to any particular system. Descriptions may supply evidence, but removing any one described system should not collapse the claim. This constraint enables transfer across contexts. It is a deliberate convention of this profile, not a claim that system-specific causal explanations are never theories in ordinary language.

Distinct review priorities. A theoretical artifact fails when it merely records local fit without a transferable explanation. A descriptive artifact fails when it misstates its referent or spends context without improving fidelity. A prescriptive artifact fails when a first-time executor cannot determine what to do. The profiles are useful to the extent that these bundled priorities recur together.

Maintenance follows dependency and authority edges

Profile membership does not itself determine change impact. The primary record is the authored dependency: what cites what, under which relationship, plus the operational authority of the consuming path. Profiles supply useful defaults for which dependencies are common, but explicit edges override the default.

Authored dependency Meaning Revision trigger
Theory links to description with evidenced-by The target observation supports, qualifies, or bounds the source claim If the description or its referent changes, reassess the theory; other evidence may let it survive
Prescription rests-on theory The procedure depends on the claim If the theory changes, reassess the procedure
Description rests-on theory The system was shaped by the claim If the theory changes, reconsider the design; the description still follows the implemented referent
Prescription cites description as operates-on The procedure acts on the described system If the system changes, revise the procedure

The asymmetry is therefore characteristic rather than absolute. Theoretical artifacts often accumulate descriptive evidence and provide the rationale for prescriptions; descriptions track changing referents; prescriptions track both their rationale and the systems they operate on. But a schema-first description can be upstream of implementation, and a theory that rests on one volatile observation can be downstream of that evidence. Maintenance should follow the recorded dependency, not an inference from genre.

One common path connects the profiles

Derivation and implementation often connect the profiles in a deliberately designed system:

theory  →  prescription  →  implementation  →  description
(claim)    (procedure)      (working system)    (account of what exists)

Theory explains why. A prescription condenses that reasoning into executable guidance. Implementation encounters constraints the theory did not settle, and description records what was actually built. The description must remain faithful even when implementation deviates from the originating rationale.

This is one common path, not an origin law for descriptions. Existing systems are often described before anyone writes a theory about them; observations can revise theory; schema-first descriptions can direct implementation; and procedures can arise from local necessity without a general principle. These feedback and independent-origin paths are why the dependency edges, rather than the diagram, control maintenance.

Content profiles and operational roles are independent

Profiles classify what an artifact says—its linguistic content. Artifacts also have operational roles: what they do in the KB.

| Operational role | What the artifact does | |---|---|---| | Evidence | Supports or challenges a claim | | Executable instruction | Directs behavior at runtime | | Generated report | Records the output of an operation | | Routing surface | Helps consumers find other artifacts |

These roles cross-cut content. A generated review report is descriptive; an index is a routing surface whose text describes what exists. An agent instruction illustrates the important dual case: it is prescriptive by content and executable by operational role. Its immediate maintenance consequence comes from that authority path—changing loaded instruction text changes system behavior—not from prescriptive wording alone. The content profile tells a writer how to formulate the artifact; operational roles and dependency edges tell a maintainer what the artifact can affect.

Evidence from this KB

Commonplace's existing collections instantiate the three defaults:

  • kb/notes/ → theoretical register (transferable claims, [title-as-claim], optimized for explanatory-reach)
  • kb/reference/ → descriptive register (how the shipped system works, topical titles, optimized for fidelity)
  • kb/instructions/ → prescriptive register (procedures and conventions, imperative titles, optimized for executability)
  • kb/agent-memory-systems/ → another descriptive collection for an external landscape

This separation emerged from practical pressure: kb/reference/ was created because shipped-system documentation did not fit theory-oriented conventions. This worked example shows that the bundles can organize one KB, but it does not establish how often they recur elsewhere.

Practical consequences

  1. Declare the actual contract. Adopt a default profile when its orientation, quality priority, maintenance semantics, and link grammar travel together. Extend or replace it when they do not.
  2. Choose an encoding that matches operation. A KB may attach profiles to directories, types, metadata, or conventions. Commonplace uses directories because collection-wide rules must cover every artifact in a subtree. This choice is an implementation detail, not part of the content taxonomy.
  3. Review dependencies explicitly. Use profile defaults to guide prospecting, but use authored relationship labels and operational authority to decide what a change can invalidate.

Open questions

  • Across independently designed KBs, do orientation, quality goal, title convention, and maintenance semantics covary strongly enough for these three bundles to remain useful defaults?
  • After explicit dependency kinds and operational authority are known, what additional maintenance or review decision does profile membership predict?
  • How robust must a theory's evidence base be? A theory with one supporting observation is fragile. Is there a practical threshold (two systems? three?) or is this a judgment call?

Relevant Notes:

Under-review context phrase

the three profiles and their quality goals this note treats as proven objective bundles