SOP-001 — Loop Execution · sop-001-loop-execution

Owner directive (2026-07-10), canonical. "dont let the Neural Engine Execution or the Neural Ware Agenticly gettings things done stray a single word from the Kernels and the knowledge in general at the Library." [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:610]

Content

This SOP defines how any datan (or looper) executes one loop inside a run. It applies to all seven loop types (D18: Environment, Pipeline, Workflow, Datan, Work, Neural, Companion [src: HOS-Webdoc/web/src/data/hos-specification.ts:409]). The governing rule is the cognitive-loop: "Every action in Mainland is a Loop. A Loop is valid only once it has run the fixed sequence Cognis → Kernels → Neuralwares." [src: wiki/engines/cognitive-loop.md:3]

Procedure

1. Take the row. Read the assigned playbook row (pb-001-spatial-site-loop, pb-002-library-authoring or pb-003-run-dispatch). A loop with no playbook row does not start.
2. Equip the gear-set. Load exactly the gear-set the row names (gear-sets): its cookbooks, benchmark gates, schemas and registry neuralwares. No improvised tooling — the loadout is what makes the Datan "a deterministic agent to complete the task" [src: …/knowledge-management-and-concept-modeling.md:453].
3. Read only library cards. All definitions and instructions come from the Knowledge Library; sources outside it are reached only through cards that cite them (sop-004-library-authoring).
4. Traverse the Cognitive Loop. Execute through the Cognis in order, each on its own kernel, with equipped neuralwares injected at their stage [src: wiki/engines/cognitive-loop.md:17, 64].
5. Clear the gate. Pass the Cognitive Loop gate (method → execute check against the approved playbook + frontier standard [src: wiki/engines/cognitive-loop.md:57]). A failed gate bounces the loop back, not forward [src: wiki/engines/cognitive-loop.md:94].
6. Deliver the particle. Produce "the exact particle requested in the format requested" [src: …/knowledge-management-and-concept-modeling.md:612]. Delivery below the quality bar is a failed delivery (Dynamic Work approval threshold 0.6 [src: wiki/engines/cognitive-loop.md:95]).
7. Commit. "every loop should have a commit, until the atom and the nodes, and etc with PR following the interactions of the systems." [src: …/knowledge-management-and-concept-modeling.md:586]
8. Spark. Record the spark(s) the closed loop emits — the output artifact that initiates the next loops [src: wiki/GLOSSARY.md:2829].

Gear-swap rule (the academy rule)

"If the datan could not delivery what is expected, it should go to the academy and bring a new neuralware (N8N, ComfyUI,VisualStudio,Gitea,Servers,APIS,TOOLS, WHATEVER) to try again and bring the exact particle requested in the format requested." [src: …/knowledge-management-and-concept-modeling.md:612]

Constraints on the swap:

1. A swap happens only after a failed delivery (gate bounce exhausted or particle rejected) — never pre-emptively mid-loop.
2. The replacement neuralware must come from the same gear-set family as the failed one (gear-sets defines families); crossing families is a re-dispatch decision for the RUN Leadership seat (squad-roles), not the Datan.
3. Every swap is logged in the run heartbeat (sop-003-run-dispatch): failed loop id, neuralware out, neuralware in, retry result.
4. After the swap the Datan retries the same playbook row — the row, format and acceptance criteria do not change.

Composition

• uses: cognitive-loop (the rule) · gear-sets (loadouts + families) · neuralware-index (what can be equipped) · sop-003-run-dispatch (heartbeat log) · sop-004-library-authoring (read-only-cards discipline)
• used-by: squad-eggtech · squad-schematic · squad-instance (every loop of every run) · okrs-2026-h2 (activity execution)

See also

• sop-002-conflict-resolution — when a loop hits conflicting definitions
• neural-engine — the runtime that drives the traversal
• dooit · ditto — the executor conduits inside a loop

SOP-002 — Conflict Resolution (Authority Chain) · sop-002-conflict-resolution

Owner directive (2026-07-10), canonical. "the version at mainland.so have all the concepts quite scattered and conflicting (but if you have them in a line you can deterministically presume the right definition." [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:579] — "Create different versions for conflicting definitions." [src: :618] — "So you never need to guess." [src: :626]

Content

This SOP is the deterministic procedure for resolving two or more conflicting definitions of one HOS concept. It is the operational form of the TEMPLATE rules [src: HOS-Instance/library/_templates/TEMPLATE.md:42-53] and applies to every card in this library.

Authority chain (precedence, highest first)

1. D-ledger — D1–D28 resolutions in HOS-Webdoc/web/src/data/hos-specification.ts. A Dxx ✓ RESOLVED entry is final.
2. C-entries — canonical decisions in wiki/development/HANDOFF.md §5 (C-01…C-06 resolved; C-07/C-08 explicitly open: "do not guess — flag" [src: wiki/development/HANDOFF.md:145]) and wiki/development/REQUIREMENTS.md.
3. Owner-directive blockquotes — dated > **Owner directive** quotes in wiki canon pages.
4. Newest dated owner prompt — verbatim prompts in the archive (sop-005-prompt-archival), cited as OWNER-YYYY-MM-DD; among prompts, the newest date wins.

Procedure

1. Detect. A loop or authoring pass finds ≥2 sources defining the same concept differently.
2. Collect verbatim. Copy each conflicting definition exactly — spelling and all — with [src: path:line]. "Variants preserve conflicting definitions VERBATIM — deprecated text is never deleted." [src: HOS-Instance/library/_templates/TEMPLATE.md:51]
3. Walk the chain in order. Stop at the first level that rules on the concept. Quote the ruling.
4. Ruled → write the Variants table. In the concept's card, add a ## Variants table: one row per definition, ruling column citing the authority (D-xx / C-xx / OWNER-YYYY-MM-DD), status canonical for the winner, deprecated or variant for the rest. The card's frontmatter authority must be non-empty.
5. Unruled → draft + Open question. If no level of the chain rules: set status: draft, leave the ruling column "pending", and add an ## Open question section addressed to the owner. Never guess a ruling. [src: HOS-Instance/library/_templates/TEMPLATE.md:46-49]
6. Escalate. Register the open question as a queue item in the next dispatch tick (sop-003-run-dispatch) so it reaches the owner; when the owner answers, the answer is archived per sop-005-prompt-archival and becomes a citable OWNER-YYYY-MM-DD authority, and the card is upgraded from draft.
7. Propagate. After a ruling, sweep the library for cards linking the concept and update their prose to the canonical definition; the Variants table remains as the permanent record.

Worked precedent

neuralware-index follows step 5: canon states two different registry compositions, no D/C entry rules on the count, so the card is draft with an Open question — the procedure exactly as specified.

Composition

• uses: sop-004-library-authoring (card mechanics) · sop-003-run-dispatch (escalation queue) · sop-005-prompt-archival (how owner answers become authorities)
• used-by: every library card with a ## Variants section · squad-schematic (governance owner, RUN-016)

See also

• bp-002-knowledge-library — the library blueprint this SOP protects
• neuralware-index — live example of the draft/Open-question path

SOP-003 — Run Dispatch (10-minute tick) · sop-003-run-dispatch

Owner directive (2026-07-10), canonical. "Create a Dispatch, Wake you up every 10 minutes, check if all capability is allocated, check the conclusion of particles and atoms and if the run is moving." [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:646]

Content

This SOP is the contract for the dispatch tick that supervises RUN-016 (squad-schematic), RUN-017 (squad-eggtech) and RUN-018 (squad-instance). The dispatcher also enforces rule compliance: "create a dispatch and always optimize the performance and the delivery, checking if the rules are being followed and refusing/accepts." [src: …/knowledge-management-and-concept-modeling.md:620]

Tick contract — every 10 minutes

1. Read state. Load dispatch.json (validated against schema-dispatch-json) and the active playbook rows of all open runs (pb-001-spatial-site-loop, pb-002-library-authoring, pb-003-run-dispatch).
2. Capability check. Every open row must have (a) a seated datan per squad-roles and (b) an equipped gear-set per gear-sets. An unallocated row is a finding.
3. Particle/atom completion check. Compare delivered work-particles and assembled atoms (work-units, matter-hierarchy) against the previous tick. Deliveries must satisfy sop-001-loop-execution step 6.
4. Run-movement check. Each open run must show movement since the last tick: ≥1 particle delivered, a gate passed, or a row state transition. A run with none is stalled this tick.
5. Rule check (refuse/accept). Spot-check the tick's deliveries against their gates (bm-001-web-perf, bm-002-splat-budget, sop-004-library-authoring zero-orphan). Non-compliant deliveries are refused — the row reopens; compliant ones are accepted.
6. Write. Append the heartbeat entry (per-run: rows open/blocked, particles delivered, gear swaps logged per SOP-001, refusals) and one tick line (timestamp, runs checked, verdict). Commit — the tick itself is a loop, and every loop has a commit [src: …/knowledge-management-and-concept-modeling.md:586].

Stall rule

A row or run with no movement for more than 2 consecutive ticks (>20 minutes) raises a queue item naming: the blocked row, the responsible seat, the last error, and the proposed remedy — a gear swap within family (sop-001-loop-execution academy rule), a re-dispatch by RUN Leadership, or an owner escalation when the blocker is an open ruling (sop-002-conflict-resolution step 6).

Interval

The 10-minute interval is fixed by the owner directive. Ticks may be cheap (checks only) but may not be skipped while any run is open; a missed tick is itself logged as a finding on the next tick.

Composition

• uses: schema-dispatch-json (state file contract) · gear-sets / squad-roles (capability check) · sop-001-loop-execution (delivery + swap semantics) · bm-001-web-perf / bm-002-splat-budget (accept/refuse gates) · pb-003-run-dispatch (the playbook wiring this SOP)
• used-by: okrs-2026-h2 (KR2/KR4 evidence) · squad-eggtech · squad-schematic · squad-instance (all supervised runs) · bpmn-neural-engine-run (the tick appears as a lane)

See also

• neural-engine — the runtime the dispatcher wakes
• sc-002-neural-engine-run — schematic of a full run under dispatch

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

SOP-005 — Owner Prompt Archival · sop-005-prompt-archival

Owner directive (2026-07-10), canonical. "Organize this prompt, save its as with the other…" [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:451] — earlier: "I want every single prompt I wrote to claude in all projects inside a json with date and topic. (…) I want the purest form of prompt" [src: :434-444].

Content

Owner prompts are the fourth level of the authority chain (sop-002-conflict-resolution): an archived prompt is citable as OWNER-YYYY-MM-DD with path:line. This SOP keeps the archive verbatim, complete, and regenerable.

Canonical stores and direction of truth

• Source of truth: ~/Documents/CodeLoop/prompt-archive/prompts_by_topic.md — the verbatim per-topic markdown snapshot (produced by concat_prompts.py) [src: wiki/development/prompts-archive/INDEX.md:3].
• Derived JSON: archive.json is regenerated from the markdown, not the reverse. regen_archive.py "regenerate[s] archive.json from prompts_by_topic.md. The working-dir archive.json was wiped between sessions. The verbatim 335-prompt snapshot survives in prompts_by_topic.md" [src: Documents/CodeLoop/prompt-archive/regen_archive.py:3-9]. The direction is markdown → json; never hand-edit archive.json.
• Published copy: wiki/development/prompts-archive/INDEX.md (verbatim copy) split into by-topic/ files by split_by_topic.py, which is "read-only w.r.t. the source archive" [src: wiki/development/prompts-archive/split_by_topic.py:3-7].

Procedure

1. Capture verbatim. The prompt is stored exactly as written — spelling, punctuation, line breaks. "336 prompts across 14 topics, nothing edited" [src: wiki/development/prompts-archive/INDEX.md:3]. The single redaction rule: live credentials are replaced with a [REDACTED — …] marker; nothing else is ever altered [src: wiki/development/prompts-archive/INDEX.md:6].
2. Append to the source of truth. Add the prompt under its ## Topic (n) heading in prompts_by_topic.md with the meta line [YYYY-MM-DD · Source · subtopic] (sources: Claude Code, Opus session, Claude web, Gemini chat, Voice memo, PDF session [src: Documents/CodeLoop/prompt-archive/regen_archive.py:21-25]). Bump the topic count.
3. Regenerate JSON. Run regen_archive.py (markdown → archive.json). Verify the entry count incremented as expected.
4. Publish to the wiki. Copy the updated archive verbatim into wiki/development/prompts-archive/INDEX.md, then run split_by_topic.py to refresh by-topic/*.md and the INDEX topic links.
5. Cite. From this point the prompt is a citable authority: OWNER-YYYY-MM-DD + [src: wiki/development/prompts-archive/by-topic/<topic>.md:line]. Library cards ruled by it are upgraded per sop-002-conflict-resolution step 6.
6. Commit the source archive and the wiki copy in the same loop [src: …/knowledge-management-and-concept-modeling.md:586].

TCC note (macOS harvesting)

When harvesting prompts from application transcript stores (Claude/other app containers under ~/Library/…), macOS TCC (Transparency, Consent & Control) can silently block reads: an unpermitted process gets empty listings rather than errors. Therefore: (a) run harvests only from a terminal the owner has deliberately granted Full Disk Access, with the owner's consent; (b) never work around TCC; (c) verify harvest counts against expected session counts — a suspiciously low count is treated as a blocked read, not as "no prompts", and is raised as a queue item (sop-003-run-dispatch).

Composition

• uses: sop-003-run-dispatch (queue items for blocked harvests) · sop-002-conflict-resolution (how archived prompts act as authorities)
• used-by: every card citing OWNER-YYYY-MM-DD · sop-004-library-authoring (citation targets) · squad-schematic (governance owner)

See also

• bp-002-knowledge-library — the resolved layer the archive feeds
• src-hosweb-routes · src-droplet-index — sibling source-capture cards