SOP-004 — Library Card Authoring · sop-004-library-authoring

Owner directive (2026-07-10), canonical. "Bring all the pages with their concepts inside a folder with divided .MD with the same format of the knowledge Base Antropic Use, but, of course following every HOS methodology." [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:540] — "You should have a folder with multiple folders and multiple files and multiple lines, so the neural engine can work like the obsidian knowledge base of antropic (…) but following the whole HOS model." [src: :542]

Content

This SOP is the procedure for authoring one card in the HOS Knowledge Library (HOS-Instance/library/). The library is the resolved layer: a datan in a loop reads only library cards, and the neural-engine may not "stray a single word from the Kernels and the knowledge in general at the Library" [src: …/knowledge-management-and-concept-modeling.md:610]. Every letter must be traceable: "every letter, word, code, should be a link to a .md at the library" [src: :582].

Procedure

1. Claim the id. Take the card's id from the library file plan (the authored id inventory). One id, one file, <id>.md, id equals filename stem, unique library-wide [src: HOS-Instance/library/_templates/TEMPLATE.md:44].
2. Copy the template. Start from _templates/TEMPLATE.md. Fill the YAML frontmatter completely: id, name, type (from the closed enum), status, authority[], supersedes[], sources[{type,path,line}], tags[], updated.
3. Write the owner-directive blockquote. Directly under the H1: the dated ruling in the owner's words, or the D-ledger resolution restated, with its [src: path:line].
4. Write ## Content. The single resolved definition. Every HOS term is a double-bracket wiki-link to another card. Every load-bearing claim carries an inline [src: path:line] citation to a real file and line.
5. Wikilink discipline. A wiki-link may target only an id that exists in the library file plan. Never invent an id; if a needed concept has no planned card, cite its upstream source instead and flag it as a queue item (sop-003-run-dispatch).
6. Handle conflicts. If the concept ever had conflicting definitions, add the ## Variants table per sop-002-conflict-resolution — verbatim quotes, authority-cited rulings, or status: draft + ## Open question when no authority exists. Never delete deprecated text.
7. Complete ## Composition and ## See also. uses / used-by relations, each a resolving wikilink.
8. Run the gate. Execute _meta/check_links.py: zero orphans, valid frontmatter, Variants⇒authority-or-draft. A card that fails the gate is not delivered — it is a failed particle under sop-001-loop-execution step 6.
9. Commit. One card (or one coherent card set) per loop, one commit per loop [src: …/knowledge-management-and-concept-modeling.md:586].

Style

Institutional-precise voice. Quote definitions verbatim (including the owner's spelling) when quoting; paraphrase only in resolved prose. Short definition sentences from the project's own internal docs are preferred over invented wording.

Composition

• uses: sop-002-conflict-resolution (Variants procedure) · schema-library-json (machine contract of the library index) · gear-sets (library-authoring set equips this SOP)
• used-by: bp-002-knowledge-library (the blueprint realized card by card) · squad-schematic (RUN-016 owner of the library) · okrs-2026-h2 (KR3 zero-orphan gate) · pb-002-library-authoring (each row of that playbook executes this SOP)

See also

• neuralware-index — a card produced under this SOP's draft path
• dikwc — the pipeline the library's resolved knowledge feeds