Task-fitted structure costs cross-task reuse

Type: kb/types/note.md · Tags: document-system, foundations

A knowledge base's structural layer — types, tags, indexes, schemas, link vocabulary, and routing contracts — can be fitted to the questions it answers today. That fit has immediate value: routing gets cheaper, validation gets sharper, and an agent can infer a writing goal from one word. Yet it establishes usefulness only for the current question set. Cross-task reuse value is a separate property: how much a later, different task gains by retaining the structure. Present fit does not show that this value will transfer.

When the questions change, the cost is mismatch rather than missing content. A tag taxonomy discards no note, a type spec deletes no text, and an index removes no source. A lossy summary can be repaired by falling back to its retained source, as in theory and methodology form a two-layer execution system. Structural mismatch is different: retained content makes a new taxonomy or index possible, but does not supply the new access path. The content remains available while the structure is shaped for questions nobody asks anymore.

Adoption and hardening are therefore separate decisions. Hardening makes a choice shared, binding, or expensive to replace. A KB can use task-derived structure now without granting it that permanence. If the KB is expected to outlive its current questions, it should keep such structure local and replaceable until varied use that could have exposed a bad fit earns broader scope. It may harden structure forced by boundary commitments, but only while those commitments hold.

The bill comes due before export

Commonplace, the KB framework documented in this repository, already makes a strong version of this argument on one axis. A universal knowledge framework demotes content taxonomies to defaults because a taxonomy abstracted from the KBs its authors have seen — often just one — mistakes features of one structural profile for universals. But that note draws the boundary at the framework's edge:

A single-purpose KB can benefit from hardcoding its profile; the burden begins when that profile is exported.

For a long-lived KB, that boundary is too late. Export is not the only way a KB meets questions it was not built for; its project can change around it. Drift and export run the same test: both bring structure fitted to one question set into contact with another. One does so across time, the other across installations. Hardcoding a profile therefore bets not only on other people's KBs, but also on the KB's own future. The second bet is harder to notice losing because no handover forces the mismatch into view.

The burden therefore begins whenever a KB is expected to outlive the question set that shaped it.

What earns permanence

The first warrant for hardening comes from constraint. A framework rule with a boundary-preserving rival is not an inherited constraint, so constraint can warrant hardening only for rules without such a rival — and surviving that hunt leaves a rule contestable, not certified. Choosing a consumer, substrate, domain, or machinery fixes the invariants a rival must preserve. Dropping a rule those commitments genuinely force means changing the commitment, not merely selecting another workable design.

The second warrant comes from evidence. Derivation and inheritance give a decomposition only starting scope warrant; discriminating evidence or proof earns scope. Task-derived structure should begin local and replaceable, but it can earn broader scope by surviving genuinely different questions that could have exposed a bad fit. Promotion should record that evidence explicitly. Adoption by more tools or notes raises migration cost; it does not by itself demonstrate transfer.

At adoption, the source of warrant divides the structural layer into two classes:

  • Constraint-derived structure is forced by current commitments. Finite consumer context, file-path semantics, and domain answerability remain binding when tasks change within those commitments. Their guarantee ends when the consumer, substrate, domain, or machinery commitment changes.
  • Task-derived structure is one workable choice among rivals under the same commitments. Examples include a type set or link vocabulary local to one KB subtree, or a guarded default profile. It should be adopted at the narrowest useful scope and left replaceable. Its initial warrant reaches no further than the question that motivated it; broader scope must be earned.

Hence the rule: harden what current constraints force; promote what discriminating use earns; configure everything else. Structure that can name neither an inherited constraint nor evidence of transfer has no claim on permanence, however useful it is today.

Cheap adoption magnifies the cost

Wikis make the accumulation risk acute because they offer many cheap ways to add structure. Any page can become an index, any convention a template, and any distinction a tag or namespace.

Retirement usually has weaker support. Adding a tag scheme can take one session; removing it may require an owner, dependency evidence, and a migration path. Without a retirement trigger, old layers can accumulate. Each may have answered a real question. Taken together, overlapping taxonomies, drifted indexes, and competing conventions raise routing and maintenance costs.

This outcome is not inevitable. Named owners, deprecation metadata, dependency checks, and scheduled audits can interrupt it. Wiki flexibility does not cause structural decay. It lowers adoption friction, so weak retirement pressure leaves more residue behind.

Neighbouring systems illustrate the present-fit and future-transfer trade without proving a universal wiki law. Sparks, a single-binary runtime for personal LLM wikis, hardcodes a small set of page types to provide a clean agent protocol. Echel, a local product-creation scaffold, fixes graph-node types around one software workflow. sift-kg, a Python CLI and library for persistent knowledge graphs, discovers a schema from an initial corpus and reuses it. Each design can be excellent within its current scope. Assessing present capability does not show whether that scope will transfer.

Scope

  • This is not an argument against structure or against deriving it from tasks. As scenario decomposition drives architecture argues, current questions should shape architecture; structure with no current question to answer is speculation. The disagreement concerns permanence, not origin. Today's task can justify adoption, but not hardening.
  • Locality bounds the blast radius; it does not supply retirement. Structure local to one KB subtree contains most damage from a bad fit. Cross-subtree links can still widen the effect, and locality alone does not remove residue from past questions.
  • The cost is real but not always decisive. A KB with a stable question set or a short life can rationally hardcode. The claim is that this bet is often invisible and rarely revisited, not that it is always wrong.
  • Commitment changes reopen hardened structure. Constraint-derived structure survives task drift only while the commitment that forced it remains. A new consumer, substrate, domain, or machinery design requires a new constraint test.
  • Coordination value is a third warrant this rule does not cover. A shared convention — a schema field, a link label, a routing key — can be worth hardening because every artifact and tool adopts the same one — coordination value, created by the shared commitment rather than earned by transfer. Its logic inverts the rule above: you commit before any use could show a fit, because waiting withholds the coordination itself. Coordination value, and the conflict it creates when a better-in-principle theory pulls against it, is treated where maintenance follows authored dependency edges rather than genre; this note governs only permanence warranted by inherited constraint or earned transfer.

Open Questions

  • What signal tells a maintainer that a piece of structure has outlived its question? Notes have staleness and review, but the structural layer has no equivalent. Automating KB learning is an open problem places retirement among the judgment-heavy mutations whose oracle is missing.
  • What evidence should promote task-derived structure to shared scope? Repetition is not enough unless the later questions could have exposed a bad fit, but nothing here sets a sufficient sample or weighs migration cost against replaceability.
  • Can accretion be made self-limiting, so structural elements must periodically justify themselves against a current question rather than persist by default?
  • When should a task-derived structure be committed as a shared convention before use could show it transfers, taking coordination value in place of earned reach? That such conventions are legitimate is settled, and how they behave once committed is treated there; what remains open is the rule for making the commitment — the trade of the option value of staying replaceable against the coordination benefit and the later switching cost.

Relevant Notes: