--- type: Agent Skill Reference title: FSS Knowledge Ownership And Routing description: Documentation ownership, local projection, progressive disclosure, priority, invalidation, and working-memory rules for feature symbionts. status: stable --- # Knowledge Ownership And Routing Read this reference when an FSS infers documentation ownership, grows or rehomes feature knowledge, routes task context, updates concepts, or manages temporary insight. ## Documentation Ownership Infer the feature's documentation owner whenever FSS enters a project, feature scope or documentation topology changes, or a handoff would otherwise lose knowledge. Documentation ownership is independent of FSS status: a stable feature may still need local knowledge, while a draft feature may already belong in strong host documentation. Treat host documentation as established only when repository evidence shows a living system rather than merely a `docs/` directory: - Contributors have a canonical location and linking convention for domain knowledge. - Documentation changes alongside code, architecture, releases, or operations. - History shows recurring maintenance rather than one-off generation. - Instructions, reviews, validators, navigation, or tooling route contributors through it. - A new feature document has an obvious home and owner. When that evidence exists: - Read, route to, and update host documentation as the feature knowledge owner. - Create missing feature documentation inside host conventions, never in a shadow corpus. - Keep the FSS root focused on operating protocol, disclosure routes, gates, evidence, and freshness checks. - Keep local concepts only for FSS-specific control knowledge or bounded temporary memory. - Introduce OKF structure into host documentation only when its conventions and authority support it without creating a parallel topology. When documentation is absent, stale, fragmented, generated but unmaintained, or has no stable feature path: - Grow the smallest useful local knowledge projection. - Add concepts only when recurring reconstruction justifies them. - Ground claims in canonical code, tests, specifications, decisions, and evidence. - Keep the FSS root as executable router and lifecycle contract, not as the knowledge corpus. Re-evaluate ownership from repository evidence, never from a stored documentation mode. If host documentation becomes established, migrate durable local knowledge into it, update FSS routes, and remove or deprecate redundant concepts only after truth has a canonical destination. If the host path becomes unusable and recurring reconstruction returns, regrow the smallest verified local projection. Never oscillate from weak signals or leave two writable sources of truth. ## Local Knowledge Projection Grow an FSS-local OKF bundle only when feature reasoning would otherwise be repeatedly reconstructed and the host lacks an established documentation path. When host documentation is active, contribute there even if a local bundle seems convenient. Keep a small feature in one conformant `SKILL.md`; add concepts incrementally as distinct responsibilities emerge. A developed symbiont may use: ```text / ├── SKILL.md ├── BACKLOG.md optional canonical open work ├── INSIGHTS.md optional pre-consolidation memory ├── domains/ ├── interfaces/ ├── invariants/ ├── procedures/ ├── decisions/ ├── failure-modes/ ├── evidence/ ├── references/ optional mirrored sources or verification code └── log.md optional OKF update history ``` Keep typed knowledge directories directly under the FSS root. Do not add a generic `concepts/` layer: OKF already derives concept IDs from paths, and typed directories provide useful grouping. Add only directories containing admitted concepts. Do not automatically add empty directories, generated indexes, or nested `index.md` files. The root `SKILL.md` supplies executable disclosure routing; generic consumers may synthesize listings. A nested `SKILL.md` belongs only to an independently executable nested symbiont with its own feature identity and operating protocol. Follow [okf.md](okf.md) whenever creating or materially changing this projection. ## Root Constitution The local `SKILL.md` is the symbiont's executable constitution and meta-index control plane. Keep these contracts derivable from it and its source concepts: - **Operating protocol:** Classification, context loading, action, verification, reconciliation, and reporting. - **Admission protocol:** Which files qualify as concepts and how core metadata, extension metadata, scope, links, and sources validate. - **Concept grammar:** Semantic obligations for each admitted FSS concept type. - **Index construction:** Derivable type, scope, link, source-path, trigger, authority, freshness, and retrieval projections. - **Priority model:** Independent authority, retrieval, maintenance, and verification axes. - **Retrieval policy:** Mandatory and triggered concepts, normative dependency expansion, optional ranking, and context limits. - **Lifecycle policy:** Invalidation, refresh, verification, consolidation, supersession, and retirement. `SKILL.md` plus source concepts are canonical. Any generated or synthesized index is a disposable projection reconstructible from them. Keep access protocol in the root and feature knowledge in the smallest owning concepts; otherwise the control plane becomes another monolith. ## Priority Vector Knowledge priorities answer separate questions: - `authority`: What wins when knowledge conflicts, subject to current user direction and canonical host truth. - `retrieval`: How early a concept enters relevant task context. - `maintenance`: How urgently source changes require review or regeneration. - `verification`: How strong evidence must be before a concept returns to stable status. Never compress these axes into one score. A rare catastrophic failure may need low default retrieval and critical verification; a frequent overview may need high retrieval and normal maintenance. These priorities schedule knowledge, not roadmap work. FSS and its indexes never manufacture feature priority, overrule canonical work, or silently resolve product, architecture, risk, scope, release, or resource trade-offs. ## Retrieval And Update Build task-specific context through bounded progressive disclosure: ```text classify task scope → load the root protocol → resolve mandatory and triggered concepts → expand normative dependencies → rank optional concepts within the context budget → inspect referenced source anchors ``` Never load the entire FSS by default. Expand through domain-to-domain Markdown links before broad source trees, then stop when the active decision and required verification are covered. Reconcile knowledge with implementation: ```text source change → match triggers and anchors → mark affected concepts stale → update or retire the smallest affected concepts → run declared verification → restore stable status and rebuild disposable projections ``` If no indexer exists, route and invalidate directly from frontmatter and Markdown links. Never present a generated cache as canonical or retain it when it conflicts with `SKILL.md` and source concepts. ## Working Memory Create `INSIGHTS.md` only when temporary pre-consolidation memory prevents repeated feature reasoning. Format each entry tersely: ```text finding → evidence → delivery consequence → destination or apoptosis condition ``` Keep falsified assumptions, unresolved design pressure, recurring traps, cross-slice dependencies, and evidence gaps. Exclude raw logs, transcripts, commit diaries, copied tasks, current hashes, and stable facts already owned elsewhere. An FSS-authored `INSIGHTS.md` normally uses `type: FSS Working Memory`; follow [okf.md](okf.md). After meaningful work, promote durable truth to the inferred documentation owner, specification, architecture, work surface, code, tests, release history, stable feature skill, or smallest owning concept. Then prune the entry. Before setting `status: stable`, consolidate every surviving insight and remove `INSIGHTS.md` when no temporary memory remains.