LISA Vault Governance

---

Operational Rules

Rule 1 — FCF Compliance Is Non-Negotiable

Every file created must conform to the FCF's segment grammar, casing rules, and placement logic. Before creating any file:

1. Determine the correct file type using the FCF decision tree
2. Read the relevant TypeSpec for that type
3. Construct the filename using the segment grammar
4. Determine the correct folder path
5. Confirm the YAML frontmatter schema from the TypeSpec
6. Only then write the file

Rule 2 — All Outputs Go Into the Vault

Never leave outputs in the terminal, clipboard, or session memory. Every piece of generated content must be written as a vault file at an FCF-compliant path. If the operator asks for "a quick summary," write it as a note (Intel type or appropriate alternative) — not as a chat response that vanishes.

Exception: Direct answers to questions, status confirmations, and conversational responses remain in-session. The rule applies to generated content — notes, documents, code, data, specifications, and analyses.

Rule 3 — Non-Markdown Artefacts Go to artefacts/

Non-markdown files (images, code archives, data exports, scripts, configs, builds, PDFs) must NEVER be placed in mission folders. Always place them in the appropriate artefacts/{type}/{project-subfolder}/ path:

Project subfolders use the mission's lowercase-hyphenated name (e.g., ClientA/, ClientA/, east-coast-hydrogen/). Use general/ for unscoped artefacts. Create subfolders on first use — do not pre-create empty ones.

Rule 4 — ArtefactMap Maintenance

Every non-markdown artefact produced must have a corresponding entry in the relevant ArtefactMap note. After placing any artefact:

1. Check if an ArtefactMap exists in the parent mission/subject folder
2. If not, create one using the ArtefactMap template
3. If yes, read it and append the new entry under the correct type section
4. Update the last_updated field in the ArtefactMap body metadata to the current ISO 8601 timestamp
5. On artefact deletion/move, update or remove the corresponding entry

Rule 5 — Complete YAML Frontmatter

Every new markdown note must include complete YAML frontmatter conforming to the relevant TypeSpec. No exceptions. Missing frontmatter fields are a classification failure.

Rule 6 — No Files Outside Vault Root

Never create files outside the vault root directory unless explicitly instructed by the operator. The vault boundary is absolute.

Rule 7 — Report All File Operations

After completing any task that creates, modifies, or deletes files, provide a summary listing:

• Full path of each file created (marked [NEW])
• Full path of each file modified (marked [MODIFIED])
• Full path of each file deleted (marked [DELETED])
• Any ArtefactMap entries added or updated

Rule 8 — CS.YB SubBrand Slot Compliance

When constructing a CS.YB filename, evaluate whether the {EndClient} represents a parent organisation with multiple commercial sub-brands AND whether the deliverable targets a specific sub-brand. If both hold, the {SubBrand} slot is mandatory in the filename and the sub_brand: field is mandatory in YAML frontmatter. The two must agree exactly. If either condition fails, the slot is omitted and the file follows the previous-form CS.YB grammar. Compound mission values that bake sub-brand identity (e.g. ClientAWebsite, ClientA-SubBrand) are not permitted for new files.

Per the 2026-05-08 dispatch-namespace resolution: when SubBrand is occupied, the dispatch namespace also carries the sub-brand (e.g. CS.YB.ClientA.ClientA.ClientA for ClientA Website work, NOT the parent CS.YB.ClientA.ClientA). Mission Matrix entries are added per sub-brand.

See FCF: CS.YB Grammar for the full slot specification, the parent-group worked examples (GroupCo, HoldCo), and the Mission elision sub-rule. See FCF SubBrand Slot Revision Proposal for the convention rationale, frontmatter validation rules, and forward-binding policy for legacy files.

---

Nin Prompt Execution Protocol

When the operator invokes a CMD.* prompt file:

1. Read the prompt file to extract the instruction template
2. Read all context files referenced by the operator
3. Execute the prompt logic
4. Classify all outputs via FCF before writing
5. Write markdown outputs to correct mission/subject folders
6. Write non-markdown outputs to correct artefacts/{type}/{project-subfolder}/ paths
7. Create or update ArtefactMap if non-markdown outputs were produced
8. Report all files created or modified

---

Vault Structure Reference

Top-level folders and their purposes:

---

Classification Matrix Consultation Protocol

1. Extract key terms from note content: entities, activities, mission identifiers.
2. Select matrix:
   • PER domain → PER.EX.SAG_SYSX.Data.ActivityClassMatrix.Tobi
   • CS domain → CS.AK.CSDAO.Data.MissionMatrix
   • For namespace construction rules and lifecycle state definitions, consult Mission Taxonomy — it defines the mission entity model, graduated infrastructure requirements by class, and dispatch namespace resolution rules that inform classification decisions.
3. Locate matching row and extract canonical values:
   • PER: pillar, topic, subject
   • CS.YB: client, end_client, mission — use Mission Shorthand for filename; full mission name for YAML mission field
   • CS.AK: mission
4. Apply to YAML using expanded values (e.g., "Sagyōjutsu", not "SAG").
5. Matrix gap? Classify by best judgement. Flag in YAML: note: Pending [Matrix Name] formalisation - [gap description].