Normalize agent instructions and workplan frontmatter (STATE-WP-0067)

- Align agent files with on-disk workplan prefixes (infer from workplan ids)
- Set workplan domain to registered domain_slug; add topic_slug where applicable
- Repair frontmatter delimiter formatting; migrate legacy task status literals
- Regenerate AGENTS.md, CLAUDE.md, and .claude/rules from State Hub templates

.claude/rules/agents.md

@@ -0,0 +1,20 @@
+## Kaizen Agents
+
+Specialized agent personas available on demand via the state-hub MCP.
+
+**Discover:** `list_kaizen_agents()` — returns all agents with name, description, category
+**Load:** `get_kaizen_agent("tdd-workflow")` — returns full instructions; read and follow them
+
+Common agents:
+
+| Agent | Category | When to use |
+|-------|----------|-------------|
+| `tdd-workflow` | testing | Step-by-step TDD8 workflow for any feature |
+| `code-refactoring` | quality | Code quality analysis and safe refactoring |
+| `test-maintenance` | testing | Diagnose and fix failing tests |
+| `requirements-engineering` | process | Prevent interface/mock mismatches upfront |
+| `keepaTodofile` | process | Maintain TODO.md during work |
+| `project-management` | process | Track status, determine next steps |
+| `datamodel-optimization` | quality | Optimize dataclasses and data structures |
+
+All 17 agents: call `list_kaizen_agents()` for the full list.

.claude/rules/architecture.md

@@ -0,0 +1,8 @@
+## Architecture
+
+<!-- TODO: Describe the key design decisions and component structure.
+     Key modules, data flows, external integrations, state machines, etc. -->
+
+## Quick Reference
+
+`~/state-hub/mcp_server/TOOLS.md` — MCP tool reference

.claude/rules/credential-routing.md

@@ -0,0 +1,50 @@
+# Credential and access routing
+
+**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
+for inference. Run this check **before** requesting secrets, API keys, SSH access,
+login tokens, or database passwords — in any repo, not only `ops-warden`.
+
+ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
+other credential need belongs to another subsystem. **Do not** message
+`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
+
+### Lookup (do this first)
+
+```bash
+warden route find "<describe your need>" --json
+warden route show <catalog-id> --json
+```
+
+Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
+
+| Agent runtime | How to orient |
+| --- | --- |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=info-tech-canon` is for coordination, not secret vending |
+| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
+| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
+
+### Quick routing table
+
+| I need… | Owner | ops-warden executes? |
+| --- | --- | --- |
+| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
+| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
+| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
+| Authorization decision | flex-auth | No — route only |
+| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
+| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
+
+### Anti-patterns (do not do these)
+
+- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
+- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
+- Pasting secrets into Git, State Hub, workplans, logs, or chat
+
+### Other capabilities (reuse-surface)
+
+Non-credential capabilities are usually discovered through **reuse-surface** federation
+(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
+every repo's agent instructions because it is high-frequency, high-risk, and easy to
+get wrong.
+
+**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`

.claude/rules/first-session.md

@@ -0,0 +1,38 @@
+## First Session Protocol
+
+Triggered when `get_domain_summary("infotech")` shows **no workstreams**.
+The project is registered but work has not yet been structured.
+
+**Step 1 — Read, don't write**
+- `~/the-custodian/canon/projects/infotech/project_charter_v0.1.md` — purpose, scope
+- `~/the-custodian/canon/projects/infotech/roadmap_v0.1.md` — planned phases
+- Scan repo root: README, directory structure, existing code or docs
+
+**Step 2 — Survey in-progress work**
+Look for TODOs, open branches, half-finished files. Note done vs. started but incomplete.
+
+**Step 3 — Propose workstreams to Bernd**
+Propose 1–3 workstreams — each a coherent strand, weeks to months, anchored to a
+roadmap phase. **Wait for approval before creating.**
+
+**Step 4 — Create workplan file first, then DB record (ADR-001)**
+```
+workplans/ITC-WP-NNNN-<slug>.md   ← write this first
+```
+Then register in the hub:
+```
+create_workstream(topic_id="fe2aaa78-9c20-4feb-b3d2-4fe0529572a3", title="...", owner="...", description="...")
+create_task(workstream_id="<id>", title="...", priority="high|medium|low")
+```
+
+**Step 5 — Record the setup**
+```
+add_progress_event(
+    summary="First session: structured infotech into N workstreams, M tasks",
+    event_type="milestone",
+    topic_id="fe2aaa78-9c20-4feb-b3d2-4fe0529572a3",
+    detail={"workstreams": [...], "tasks_created": M}
+)
+```
+
+<!-- Delete or archive this file once past first session -->

.claude/rules/repo-boundary.md

@@ -0,0 +1,8 @@
+## Repo boundary
+
+This repo owns **InfoTechCanon** only. It does not own:
+
+<!-- TODO: List what belongs in adjacent repos, e.g.:
+- SSH key management → railiance-infra/
+- State hub code     → state-hub/
+-->

.claude/rules/repo-identity.md

@@ -0,0 +1,5 @@
+**Purpose:** Markdown-first semantic canon and standards service for interoperable information-processing systems.
+
+**Domain:** infotech
+**Repo slug:** info-tech-canon
+**Topic ID:** fe2aaa78-9c20-4feb-b3d2-4fe0529572a3

.claude/rules/session-protocol.md

@@ -0,0 +1,85 @@
+## Session Protocol
+
+Dev Hub (State Hub API): http://127.0.0.1:8000
+MCP server name in `~/.claude.json`: `dev-hub`
+
+**Step 1 — Orient**
+
+Read the offline-safe brief first — it works without a live hub connection:
+```bash
+cat .custodian-brief.md
+```
+Then call the MCP tool for richer cross-domain context when MCP tools are exposed:
+```
+get_domain_summary("infotech")
+```
+If MCP tools are unavailable in the current agent session, use the REST API:
+```bash
+curl -s "http://127.0.0.1:8000/state/summary" | python3 -m json.tool
+```
+If the hub is offline: `cd ~/state-hub && make api`
+
+**Step 2 — Check inbox**
+With MCP tools:
+```
+get_messages(to_agent="info-tech-canon", unread_only=True)
+```
+Mark read with `mark_message_read(message_id)`. Reply or act on coordination
+requests before proceeding.
+
+Without MCP tools:
+```bash
+curl -s "http://127.0.0.1:8000/messages/?to_agent=info-tech-canon&unread_only=true" \
+  | python3 -m json.tool
+curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
+  -H "Content-Type: application/json" -d '{}'
+```
+
+**Step 3 — Scan workplans**
+```bash
+ls workplans/
+```
+For each file with `status: ready`, `active`, or `blocked`, note pending
+`wait`/`todo`/`progress` tasks.
+
+**Step 4 — Present brief**
+
+1. **Active workstreams** for `infotech` — title, task counts, blocking decisions
+2. **Pending tasks** from `workplans/` + any `[repo:info-tech-canon]` hub tasks
+3. **Goal guidance** — if `goal_guidance` in summary:
+   - `needs_workplan`: surface as top action — *"Repo goal '{title}' has no workplan yet"*
+   - `alignment_warnings`: flag if active work is not aligned with current goal
+4. **Suggested next action** — highest-priority open item
+5. **SBOM status** — flag if `last_sbom_at` is unset for this repo
+
+If no workstreams: follow First Session Protocol (`first-session.md`).
+
+**During work:** `record_decision()` · `add_progress_event()` · `resolve_decision()`
+
+> State Hub is a *read model*. Bootstrap tools (`create_workstream`, `create_task`)
+> are First Session Protocol only. Work structure belongs in repo files (ADR-001).
+
+**Session close:**
+With MCP tools:
+```
+add_progress_event(summary="...", topic_id="fe2aaa78-9c20-4feb-b3d2-4fe0529572a3", workstream_id="<uuid>")
+```
+Without MCP tools:
+```bash
+curl -s -X POST http://127.0.0.1:8000/progress/ \
+  -H "Content-Type: application/json" \
+  -d '{"topic_id":"fe2aaa78-9c20-4feb-b3d2-4fe0529572a3","workstream_id":"<uuid>","event_type":"note","summary":"what changed","author":"codex"}'
+```
+If workplan files were modified, ensure the local copy is up to date first:
+```bash
+git -C <repo_path> pull --ff-only
+cd ~/state-hub && make fix-consistency REPO=info-tech-canon
+```
+For repos where implementation runs on a remote machine (e.g. CoulombCore),
+use the combined target which pulls before fixing:
+```bash
+cd ~/state-hub && make fix-consistency-remote REPO=info-tech-canon
+```
+**C-15** (DB task ahead of file) is normal in multi-machine workflows — writeback
+will sync the file to match DB.  **C-16** (repo behind remote) blocks all writes
+until you pull — intentional to prevent clobbering remote progress.

.claude/rules/stack-and-commands.md

@@ -0,0 +1,19 @@
+## Stack
+
+<!-- TODO: Fill in language, frameworks, and key dependencies -->
+- **Language:**
+- **Key deps:**
+
+## Dev Commands
+
+```bash
+# TODO: Fill in the standard commands for this repo
+
+# Install dependencies
+
+# Run tests
+
+# Lint / type check
+
+# Build / package (if applicable)
+```

.claude/rules/workplan-convention.md

@@ -0,0 +1,40 @@
+## Workplan Convention (ADR-001)
+
+File location: `workplans/ITC-WP-NNNN-<slug>.md`
+ID prefix: `ITC-WP-`
+
+Work items originate as files in this repo **before** being registered in the hub.
+
+Canonical workplan/workstream frontmatter statuses are:
+`proposed`, `ready`, `active`, `blocked`, `backlog`, `finished`, `archived`.
+Use `proposed` for a newly drafted plan, `ready` after review against current
+repo state, and `finished` when implementation is complete. `stalled` and
+`needs_review` are derived health labels, not stored statuses.
+
+Closed workplans may be moved to `workplans/archived/` with a completion-date
+prefix: `YYMMDD-ITC-WP-NNNN-<slug>.md`. The frontmatter id remains
+unchanged; the prefix is only for quick visual reference.
+
+Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**:
+`workplans/ADHOC-YYYY-MM-DD.md`, workstream slug `adhoc-YYYY-MM-DD`, and task ids
+`ADHOC-YYYY-MM-DD-T01`, `T02`, etc. Use adhocs only for low-risk work completed
+directly. Promote anything requiring analysis, design, approval, dependencies, or
+multiple planned phases into a normal workplan.
+
+Ecosystem todos from other agents arrive as `[repo:info-tech-canon]` hub tasks —
+visible at session start. Pick one up by creating the workplan file, then registering
+the workstream.
+
+Task blocks use this shape:
+
+```task
+id: ITC-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
+```
+
+Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
+blocked work and `cancel` for stopped work.
+
+<!-- Ralph Loop rules and HEUREKA sequence: ~/.claude/CLAUDE.md — do not duplicate here -->

.custodian-brief.md

@@ -1,8 +1,8 @@
 <!-- custodian-brief: generated by fix-consistency — do not edit manually -->
 # Custodian Brief — info-tech-canon
 
-**Domain:** canon  
-**Last synced:** 2026-05-23 05:22 UTC  
+**Domain:** infotech  
+**Last synced:** 2026-06-22 10:38 UTC  
 **State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)*
 
 ## Active Workstreams
@@ -13,6 +13,6 @@
 ## MCP Orientation (when available)
 
 If the state-hub MCP server is reachable, call:
-`get_domain_summary("canon")`
+`get_domain_summary("infotech")`
 This provides richer cross-domain context.
 If the MCP call fails, use this file as your orientation source.

.gitignore

@@ -174,3 +174,7 @@ cython_debug/
 # PyPI configuration file
 .pypirc
 
+# Claude Code (machine-local, not shared)
+.claude/settings.local.json
+.claude/*.local.*
+

.repo-classification.yaml

@@ -0,0 +1,19 @@
+repo_classification:
+  standard: Repo Classification Standard
+  version: '1.0'
+  classified_at: '2026-06-22'
+  classified_by: agent
+  category: project
+  domain: infotech
+  secondary_domains: []
+  capability_tags:
+  - canon
+  - knowledge
+  - governance
+  business_stake:
+  - technology
+  - product
+  - operations
+  business_mechanics:
+  - coordination
+  - operation

AGENTS.md

@@ -0,0 +1,219 @@
+# InfoTechCanon — Agent Instructions
+
+## Repo Identity
+
+**Purpose:** Markdown-first semantic canon and standards service for interoperable information-processing systems.
+
+**Domain:** infotech
+**Repo slug:** info-tech-canon
+**Topic ID:** `fe2aaa78-9c20-4feb-b3d2-4fe0529572a3`
+**Workplan prefix:** `ITC-WP-`
+
+---
+
+## State Hub Integration
+
+The Custodian State Hub tracks work across all domains. Interact via HTTP REST —
+there is no MCP server for Codex agents.
+
+| Context | URL |
+|---------|-----|
+| Local workstation | `http://127.0.0.1:8000` |
+| Remote via tunnel | `http://127.0.0.1:18000` |
+
+### Orient at session start
+
+```bash
+# Offline brief — works without hub connection
+cat .custodian-brief.md
+
+# Active workstreams for this domain
+curl -s "http://127.0.0.1:8000/workstreams/?topic_id=fe2aaa78-9c20-4feb-b3d2-4fe0529572a3&status=active" \
+  | python3 -m json.tool
+
+# Check inbox
+curl -s "http://127.0.0.1:8000/messages/?to_agent=info-tech-canon&unread_only=true" \
+  | python3 -m json.tool
+```
+
+Mark a message read:
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
+  -H "Content-Type: application/json" -d '{}'
+```
+
+### Log progress (required at session close)
+
+```bash
+curl -s -X POST http://127.0.0.1:8000/progress/ \
+  -H "Content-Type: application/json" \
+  -d '{
+    "summary": "what was done",
+    "event_type": "note",
+    "author": "codex",
+    "workstream_id": "<uuid>",
+    "task_id": "<uuid>"
+  }'
+```
+
+Omit `workstream_id` / `task_id` when not applicable.
+
+### Update task status
+
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
+  -H "Content-Type: application/json" \
+  -d '{"status": "progress"}'
+# values: wait | todo | progress | done | cancel
+```
+
+### Flag a task for human review
+
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
+  -H "Content-Type: application/json" \
+  -d '{"needs_human": true, "intervention_note": "reason"}'
+```
+
+---
+
+## Session Protocol
+
+**Start:**
+1. `cat .custodian-brief.md` — domain goal and open workstreams (offline-safe)
+2. Check inbox: `GET /messages/?to_agent=info-tech-canon&unread_only=true`; mark read
+3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks
+4. Check human-needed tasks: `GET /tasks/?needs_human=true`
+
+**During work:**
+- Update task statuses in workplan files as tasks progress
+- Record significant decisions via `POST /decisions/`
+
+**Close:**
+1. Update workplan file task statuses to reflect progress
+2. Log: `POST /progress/` with a summary of what changed
+3. Note for the custodian operator: after workplan file changes, run from
+   `~/state-hub`:
+   ```bash
+   make fix-consistency REPO=info-tech-canon
+   ```
+   This syncs task status from files into the hub DB.
+
+---
+
+## Credential and access routing
+
+**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
+for inference. Run this check **before** requesting secrets, API keys, SSH access,
+login tokens, or database passwords — in any repo, not only `ops-warden`.
+
+ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
+other credential need belongs to another subsystem. **Do not** message
+`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
+
+### Lookup (do this first)
+
+```bash
+warden route find "<describe your need>" --json
+warden route show <catalog-id> --json
+```
+
+Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
+
+| Agent runtime | How to orient |
+| --- | --- |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=info-tech-canon` is for coordination, not secret vending |
+| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
+| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
+
+### Quick routing table
+
+| I need… | Owner | ops-warden executes? |
+| --- | --- | --- |
+| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
+| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
+| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
+| Authorization decision | flex-auth | No — route only |
+| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
+| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
+
+### Anti-patterns (do not do these)
+
+- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
+- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
+- Pasting secrets into Git, State Hub, workplans, logs, or chat
+
+### Other capabilities (reuse-surface)
+
+Non-credential capabilities are usually discovered through **reuse-surface** federation
+(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
+every repo's agent instructions because it is high-frequency, high-risk, and easy to
+get wrong.
+
+**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`
+
+<!-- REPO-AGENTS-EXTENSIONS -->
+<!-- Append repo-specific agent instructions below this marker.
+     The state-hub template sync preserves content after this line. -->
+
+---
+
+## Workplan Convention (ADR-001)
+
+Work items originate as files in this repo — not in the hub. The hub is a
+read/cache/index layer that rebuilds from files.
+
+**File location:** `workplans/INFO-WP-NNNN-<slug>.md`
+
+**Archived location:** finished workplans may move to
+`workplans/archived/YYMMDD-INFO-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is
+the completion/archive date; the frontmatter `id` does not change.
+
+**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use
+`workplans/ADHOC-YYYY-MM-DD.md` with task ids `ADHOC-YYYY-MM-DD-T01`, etc. Use
+this only for low-risk work completed directly; create a normal workplan for
+anything needing analysis, design, approval, dependencies, or multiple phases.
+
+**Frontmatter:**
+
+```yaml
+---
+id: INFO-WP-NNNN
+type: workplan
+title: "..."
+domain: infotech
+repo: info-tech-canon
+status: proposed | ready | active | blocked | backlog | finished | archived
+owner: codex
+topic_slug: ...
+created: "YYYY-MM-DD"
+updated: "YYYY-MM-DD"
+state_hub_workstream_id: "<uuid>"   # written by fix-consistency — do not edit
+---
+```
+
+Use `proposed` for a new draft, `ready` after review against current repo
+state, and `finished` after implementation. `stalled` and `needs_review` are
+derived health labels, not frontmatter statuses.
+
+**Task block format** (one per `##` section):
+
+```
+## Task Title
+
+` ` `task
+id: INFO-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
+` ` `
+
+Task description text.
+```
+
+Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.
+
+To create a new workplan:
+1. Write the file following the format above
+2. Notify the custodian operator to run `make fix-consistency REPO=info-tech-canon`
+   (or send a message to the hub agent via `POST /messages/`)

CLAUDE.md

@@ -0,0 +1,12 @@
+# InfoTechCanon — Claude Code Instructions
+
+@SCOPE.md
+@.claude/rules/repo-identity.md
+@.claude/rules/session-protocol.md
+@.claude/rules/first-session.md
+@.claude/rules/workplan-convention.md
+@.claude/rules/stack-and-commands.md
+@.claude/rules/architecture.md
+@.claude/rules/repo-boundary.md
+@.claude/rules/credential-routing.md
+@.claude/rules/agents.md

canon.yaml

@@ -99,6 +99,10 @@ standards:
     title: InfoTechCanonCaringAccessGovernanceStandard
     path: infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
     status: 0.4.0-RC2-aligned
+  - id: itc-repo-layout
+    title: InfoTechCanonRepositoryLayoutStandard
+    path: infospace/standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+    status: RC1-seed
 
 planned_directories:
   - infospace/

infospace/agent/briefs/standard-repository-layout.md

@@ -0,0 +1,37 @@
+---
+id: agent-brief/standard-repository-layout
+artifact_id: standard/repository-layout
+source_path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+source_kind: standard
+generated: true
+---
+
+<!-- GENERATED by info_tech_canon; do not edit by hand. -->
+
+# Agent Brief: InfoTechCanon Repository Layout Standard
+
+- Artifact ID: `standard/repository-layout`
+- Kind: `standard`
+- Canonical path: `standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md`
+- Full source: `standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md`
+- Summary: Cross-cutting canon standard: InfoTechCanon Repository Layout Standard.
+
+## Retrieval Hints
+
+Imports and anchors:
+- `kernel/itc-core`
+- `model/governance`
+- `model/information-space`
+- `model/task`
+
+## Owned Concepts
+
+- `CanonicalRepositoryLayout`
+- `InfoTechCanon Repository Layout Standard`
+- `LayoutConformanceLevel`
+- `RepositoryDocumentationDirectory`
+- `ScopeIntentOperatingMode`
+
+## Related Distinctions
+
+No common distinction is anchored directly on this artifact.

infospace/agent/global-agent-brief.md

@@ -5,8 +5,8 @@
 This brief summarizes the current canon service surface for agents.
 
 - Infospace slug: `canon`
-- Artifact count: 60
-- Retrieval index items: 60
+- Artifact count: 61
+- Retrieval index items: 61
 - Primary confidence command: `make validate`
 - Refresh generated indexes and views with: `make index`
 - Refresh agent briefs and interface templates with: `make agent-briefs`

infospace/agent/retrieval-index.json

@@ -43,7 +43,7 @@
     }
   ],
   "infospace": "canon",
-  "item_count": 60,
+  "item_count": 61,
   "items": [
     {
       "canonical_path": "standards/caring/benchmarks/kubernetes-rbac/benchmark.yaml",
@@ -2241,6 +2241,46 @@
       "title": "InfoTechCanon CARING Access Governance Standard",
       "warnings": []
     },
+    {
+      "canonical_path": "standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md",
+      "id": "standard/repository-layout",
+      "imports": [
+        "kernel/itc-core",
+        "model/governance",
+        "model/information-space",
+        "model/task"
+      ],
+      "kind": "standard",
+      "owned_concepts": [
+        "CanonicalRepositoryLayout",
+        "InfoTechCanon Repository Layout Standard",
+        "LayoutConformanceLevel",
+        "RepositoryDocumentationDirectory",
+        "ScopeIntentOperatingMode"
+      ],
+      "relationships": [
+        {
+          "target": "kernel/itc-core",
+          "type": "conforms_to"
+        },
+        {
+          "target": "model/information-space",
+          "type": "imports"
+        },
+        {
+          "target": "model/governance",
+          "type": "imports"
+        },
+        {
+          "target": "model/task",
+          "type": "imports"
+        }
+      ],
+      "source_path": "infospace/evaluations/repository-layout/source-demand.md",
+      "summary": "Cross-cutting canon standard: InfoTechCanon Repository Layout Standard.",
+      "title": "InfoTechCanon Repository Layout Standard",
+      "warnings": []
+    },
     {
       "canonical_path": "standards/tagging/InfoTechCanonTaggingStandard.md",
       "id": "standard/tagging",

infospace/agent/retrieval-index.md

@@ -4,7 +4,7 @@
 
 Schema: `info-tech-canon.retrieval-index.v1`
 Infospace: `canon`
-Items: **60**
+Items: **61**
 
 ## Common Distinctions
 
@@ -605,6 +605,16 @@ Items: **60**
 - Imports and anchors: `kernel/itc-core`, `model/access-control`, `model/data`, `model/devsecops`, `model/governance`, `model/network`, `model/observability`, `model/organization`, `model/security`, `model/task`, `standard/tagging`
 - Owned concepts: `CARINGAccessDescriptor`, `CARINGAnalysisFitnessTest`, `CARINGAnalysisProcedure`, `CARINGCanonicalRole`, `CARINGCapabilityProfile`, `CARINGDeclaredAccessMap`, `CARINGDerivedCapability`, `CARINGEffectiveAccessMap`, `CARINGExposureEvent`, `CARINGExposureMode`, `CARINGInducedAccess`, `CARINGOrganizationRelation`, `CARINGPlane`, `CARINGRedesignProcedure`, `CARINGRestrictionPrecedence`, `InfoTechCanon CARING Access Governance Standard`
 
+### InfoTechCanon Repository Layout Standard
+
+- ID: `standard/repository-layout`
+- Kind: `standard`
+- Canonical path: `standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md`
+- Source path: `infospace/evaluations/repository-layout/source-demand.md`
+- Summary: Cross-cutting canon standard: InfoTechCanon Repository Layout Standard.
+- Imports and anchors: `kernel/itc-core`, `model/governance`, `model/information-space`, `model/task`
+- Owned concepts: `CanonicalRepositoryLayout`, `InfoTechCanon Repository Layout Standard`, `LayoutConformanceLevel`, `RepositoryDocumentationDirectory`, `ScopeIntentOperatingMode`
+
 ### InfoTechCanon Tagging Standard
 
 - ID: `standard/tagging`

infospace/agent/retrieval-index.yaml

@@ -1,6 +1,6 @@
 schema: info-tech-canon.retrieval-index.v1
 infospace: canon
-item_count: 60
+item_count: 61
 items:
 - id: benchmark/caring/kubernetes-rbac
   kind: benchmark-workspace
@@ -1410,6 +1410,33 @@ items:
   - type: imports
     target: standard/tagging
   warnings: []
+- id: standard/repository-layout
+  kind: standard
+  title: InfoTechCanon Repository Layout Standard
+  canonical_path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+  source_path: infospace/evaluations/repository-layout/source-demand.md
+  summary: 'Cross-cutting canon standard: InfoTechCanon Repository Layout Standard.'
+  owned_concepts:
+  - CanonicalRepositoryLayout
+  - InfoTechCanon Repository Layout Standard
+  - LayoutConformanceLevel
+  - RepositoryDocumentationDirectory
+  - ScopeIntentOperatingMode
+  imports:
+  - kernel/itc-core
+  - model/governance
+  - model/information-space
+  - model/task
+  relationships:
+  - type: conforms_to
+    target: kernel/itc-core
+  - type: imports
+    target: model/information-space
+  - type: imports
+    target: model/governance
+  - type: imports
+    target: model/task
+  warnings: []
 - id: standard/tagging
   kind: standard
   title: InfoTechCanon Tagging Standard

infospace/artifacts/index.yaml

@@ -242,6 +242,23 @@ artifacts:
         target: model/task
       - type: imports
         target: standard/tagging
+  - id: standard/repository-layout
+    path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+    kind: standard
+    title: InfoTechCanon Repository Layout Standard
+    provenance:
+      source_path: infospace/evaluations/repository-layout/source-demand.md
+      placement: authored
+      placement_workplan: ITC-WP-0012
+    relationships:
+      - type: conforms_to
+        target: kernel/itc-core
+      - type: imports
+        target: model/information-space
+      - type: imports
+        target: model/governance
+      - type: imports
+        target: model/task
   - id: benchmark/caring/kubernetes-rbac
     path: standards/caring/benchmarks/kubernetes-rbac/benchmark.yaml
     kind: benchmark-workspace

infospace/evaluations/repository-layout/consumer-adoption-brief.md

@@ -0,0 +1,62 @@
+---
+id: repository-layout/consumer-adoption-brief
+title: Repository Layout Standard Consumer Adoption Brief
+status: candidate
+standard: standard/repository-layout
+workplan: ITC-WP-0012
+---
+
+# Repository Layout Standard Consumer Adoption Brief
+
+## Purpose
+
+Use this brief as the seed for adopting the InfoTechCanon Repository Layout
+Standard in a consumer repository. The adoption and any repo-specific
+implementation belong in the consumer's own repository, not in InfoTechCanon
+(same boundary as WP-0009 — `repository scope` is producer-only).
+
+The layout is a **recommendation, not a strict requirement**. Adopt the parts
+that fit and declare the conformance level you reach.
+
+## Canon Inputs
+
+- `infospace/standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md`
+- `infospace/evaluations/repository-layout/source-demand.md`
+- `infospace/evaluations/repository-layout/placement-decision.yaml`
+- `infospace/evaluations/repository-layout/reconciliation.yaml`
+- `infospace/models/governance/InfoTechCanonPurposeDemandExtension.md`
+- `infospace/patterns/intent-scope-purposes.md`
+
+## Adoption Steps For A Consumer Repo
+
+1. Add `INTENT.md` and `SCOPE.md` at the repository root, keeping intent
+   (aspiration) and scope (current boundary) distinct — do not collapse them.
+2. Decide which canonical directories the repo needs from the set
+   `research/ demand/ spec/ workplans/ docs/ wiki/ issues/ history/`, mapping
+   each to the canon model it references (Information Space, Governance,
+   Purpose/Demand, Task) rather than redefining those concepts.
+3. Route un-reviewed inbound through `demand/`; promote to `workplans/` only
+   after a review/decision trail (no demand-as-task).
+4. Apply the `yymmdd-` prefix in `research/` and `history/` so explorations and
+   archives stay chronologically retrievable.
+5. Adopt the SCOPE→INTENT operating mode: work = closing the gap from current
+   SCOPE to target INTENT, refining both as learning accrues.
+6. Declare a `LayoutConformanceLevel` (`minimal` / `core` / `full`) for the repo
+   and record which directories are intentionally omitted.
+
+## Expected Outputs (in the consumer repo)
+
+- root `INTENT.md` and `SCOPE.md`,
+- the chosen canonical directories in use as defined,
+- a declared conformance level,
+- a short note on intentional omissions and any repo-specific deviations.
+
+## Non-Goals
+
+- Do not modify the Repository Layout Standard from a consumer workplan without a
+  canon-side EvolutionRequest.
+- Do not treat the layout as mandatory; partial conformance is valid.
+- Do not let `spec/` or `docs/` silently redefine `SCOPE.md`; scope changes
+  belong in `SCOPE.md` under governance.
+- Do not edit `issues/` as if it were the ticket system of record (it is a
+  mirror).

infospace/evaluations/repository-layout/demand-intake.yaml

@@ -0,0 +1,116 @@
+id: demand/repository-layout/intake
+title: Canonical Repository Layout Demand Intake
+status: reviewed
+type: demand-intake
+uses:
+  - model/purpose-demand-extension
+  - model/governance
+source:
+  artifact: infospace/evaluations/repository-layout/source-demand.md
+  arrival_surface: demand/
+  arrival_note: >-
+    Arrived in the repo-level demand/ inbound directory, which the source
+    document itself defines as un-reviewed inbound. Processed here as a
+    DemandSignal before any canon artifact is authored.
+  captured_date: "2026-06-08"
+  resolution:
+    resolved_date: "2026-06-13"
+    moved_to: infospace/evaluations/repository-layout/source-demand.md
+    note: >-
+      Now reviewed, the raw demand left the demand/ inbound directory (per the
+      standard's own rule) and is retained as the captured original beside this
+      evaluation pack. The repo-root demand/ directory was emptied and removed.
+  follow_up_owner: canon
+
+consumer_purpose:
+  id: purpose/canonical-repository-layout
+  concept: ConsumerPurpose
+  consumer: bernd-worsch / cross-domain (custodian, railiance, markitect, coulomb_social, personhood, foerster_capabilities, netkingdom)
+  anchored_in: >-
+    Consumer intent to make documentation across many repositories
+    retrieval-oriented and uniform, so humans and agents can find the right
+    information at the right working-memory cost.
+  declared_purpose: >-
+    A canonical, recommendation-level documentation layout for repositories —
+    INTENT.md / SCOPE.md plus research/, demand/, spec/, workplans/, docs/,
+    wiki/, issues/, history/ — with a SCOPE-to-INTENT gap-closing operating mode.
+  use_case:
+    id: usecase/uniform-doc-retrieval
+    concept: UseCase
+    description: >-
+      A maintainer or agent entering any conforming repository can locate
+      intent, current scope, raw demand, specs, active work, stakeholder docs,
+      collaborative wiki, mirrored tickets, and archived material by directory
+      convention rather than per-repo discovery.
+
+demand_signal:
+  id: signal/repository-layout-recommendation
+  concept: DemandSignal
+  observation: >-
+    An explicit, written recommendation for a canonical repository documentation
+    layout, distilled from lived practice and offered to the canon to "pick up".
+  signal_type: explicit-request
+  strength: single-but-high-intent
+  provenance:
+    prior_art:
+      - CoulombSocial
+      - HelixForge
+      - MarkiTect
+    note: >-
+      Layout is presented as evolved best practice from these three repos'
+      documentation experience; yawex prior-art material is named as research/
+      content. Background doc types (PRD / TechSpec / UseCaseCatalog /
+      ArchitectureBlueprint) reference the InfoTechPrimers space on coulomb.social.
+  consumer_need:
+    id: need/uniform-retrievable-docs
+    concept: ConsumerNeed
+    description: >-
+      Need for a shared, low-friction documentation structure that keeps working
+      memory uncluttered (history/ out of daily scope) and routes inbound
+      demand through systematic review (demand/ -> tasks/workplans).
+    horizon: current
+
+# Preliminary fit only — the binding PurposeFit / placement decision is T02.
+preliminary_purpose_fit:
+  concept: PurposeFit
+  state: gap
+  rationale: >-
+    The canon owns adjacent concepts (Information Space for knowledge packaging
+    and retrieval; Governance + Purpose/Demand for INTENT/SCOPE/PURPOSES and the
+    demand/ intake surface; Task for workplans/history) but does not yet own a
+    named cross-cutting convention that prescribes a canonical repository
+    documentation directory set. This is a producer-facing convention the canon
+    does not currently provide.
+  matched_canon:
+    - model/information-space
+    - model/governance
+    - model/purpose-demand-extension
+    - model/task
+    - pattern/intent-scope-purposes
+  note: Binding fit evaluation and ownership mapping are deferred to T02.
+
+scope_pressure:
+  concept: ScopePressure
+  state: flagged-for-review
+  current_scope_ref: SCOPE.md
+  pressure: >-
+    SCOPE.md currently frames the repo as a seed corpus of kernel/models/
+    standards/profiles/patterns and does not promise a producer-facing repository
+    documentation-layout convention. Adopting this demand would extend the canon
+    to own such a convention (working hypothesis: a new standard), so it must go
+    through governance scope-pressure review rather than silently expanding scope.
+  alignment_with_producer_intent: >-
+    Aligns with the canon's stated purpose of providing interoperable, retrievable
+    structures and seed conventions for infospaces and agent use; the convention
+    is recommendation-level, matching the canon's non-coercive posture.
+  recommended_disposition: add_standard_candidate
+  decision_authority: canon governance
+  review_gate: ITC-WP-0012-T02
+
+disposition:
+  intake_outcome: accepted_for_analysis
+  next_step: >-
+    Proceed to T02 placement decision (review gate): decide canon ownership,
+    map each layout element to an existing model, and emit explicit placement +
+    extension candidates before any standard text is written.
+  no_artifact_authored: true

infospace/evaluations/repository-layout/placement-decision.yaml

@@ -0,0 +1,163 @@
+id: demand/repository-layout/placement-decision
+title: Canonical Repository Layout Placement Decision
+status: reviewed
+type: placement-decision
+review_gate: ITC-WP-0012-T02
+uses:
+  - model/purpose-demand-extension
+  - model/governance
+inputs:
+  demand_intake: infospace/evaluations/repository-layout/demand-intake.yaml
+  source_artifact: infospace/evaluations/repository-layout/source-demand.md
+
+# ---------------------------------------------------------------------------
+# Decision: where does this convention belong in the canon line of structures?
+# ---------------------------------------------------------------------------
+decision:
+  placement: standard
+  proposed_id: itc-repo-layout
+  proposed_title: InfoTechCanonRepositoryLayoutStandard
+  proposed_path: infospace/standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+  conformance_posture: recommendation
+  rationale: >-
+    The proposal is a named, cross-cutting documentation convention that spans
+    several existing models without redefining any of them — the canon's own
+    definition of a Standard ("cross-cutting conventions or named analytical/
+    design frameworks", canon.yaml classification). It is a sibling to the
+    Tagging and CARING standards, not a domain model (it introduces no new domain
+    entities), not a profile (it is not a concrete proof of a model against a
+    scenario), and not a pattern (it prescribes a directory contract, not a
+    reusable solution shape). The source is explicit that it is a recommendation,
+    so conformance is graded, not mandatory.
+  rejected_alternatives:
+    - placement: model
+      why_not: >-
+        Would imply new domain concepts the canon must own permanently; the
+        convention instead references concepts already owned by Information
+        Space, Governance, Purpose/Demand, and Task.
+    - placement: profile
+      why_not: >-
+        Profiles are concrete proofs of models against a scenario (e.g.
+        small-saas); a repository documentation layout is a general convention,
+        not a scenario proof.
+    - placement: pattern
+      why_not: >-
+        Patterns capture a context/problem/solution shape (e.g.
+        intent-scope-purposes); the demand is a prescriptive directory set and
+        operating mode, which reads as a standard, not a pattern. The standard
+        may cite the intent-scope-purposes pattern.
+
+# ---------------------------------------------------------------------------
+# Ownership map: each layout element points at the model that already owns the
+# concepts it relies on. The standard REFERENCES these; it must not redefine.
+# ---------------------------------------------------------------------------
+ownership_map:
+  - element: "INTENT.md / SCOPE.md + SCOPE->INTENT gap-closing operating mode"
+    owned_by:
+      - model/governance
+      - model/purpose-demand-extension
+      - pattern/intent-scope-purposes
+    note: >-
+      INTENT/SCOPE/PURPOSES distinction and the gap-closing loop are already
+      owned. The standard cites them and locates them as repo-root files.
+    no_collapse: Keep INTENT vs SCOPE vs PURPOSES distinct.
+  - element: "demand/"
+    owned_by:
+      - model/purpose-demand-extension
+    note: >-
+      The raw inbound surface for DemandSignal capture before review. This very
+      workplan dogfooded it (demand/CanonicalRepositoryLayout.md).
+    no_collapse: demand/ holds un-reviewed DemandSignals, not Tasks.
+  - element: "research/"
+    owned_by:
+      - model/information-space
+    note: >-
+      Exploration results in problem/solution space; yymmdd-prefixed. Knowledge
+      packaging and retrieval are Information Space concerns.
+  - element: "spec/ (PRD / TechSpec / UseCaseCatalog / ArchitectureBlueprint)"
+    owned_by:
+      - model/governance
+      - model/information-space
+    note: >-
+      Specs provide guardrails (Governance directive surface) packaged as
+      retrievable knowledge (Information Space). Doc-type background lives in the
+      InfoTechPrimers space on coulomb.social (external reference).
+  - element: "workplans/"
+    owned_by:
+      - model/task
+    note: >-
+      Workplans carry Tasks, registered with the State Hub. Task Model owns
+      backlog/readiness/commitment/progress/completion semantics.
+    no_collapse: Workplan/Task are work structure; demand/ is pre-work.
+  - element: "docs/"
+    owned_by:
+      - model/information-space
+    note: Stakeholder-facing documentation (users, developers, humans, agents).
+  - element: "wiki/"
+    owned_by:
+      - model/information-space
+    note: Interconnected collective knowledge without a fixed perspective.
+  - element: "issues/"
+    owned_by:
+      - model/task
+    note: >-
+      Mirror of an external ticket system to ease access; maps to the Task Model
+      surface. The standard treats it as a mirror, not the system of record.
+  - element: "history/"
+    owned_by:
+      - model/task
+      - model/information-space
+    note: >-
+      Archive of finished/canceled material; yymmdd-prefixed; out of scope for
+      daily working memory. Finished/canceled workplans move here (Task
+      lifecycle) and archived knowledge persists (Information Space).
+
+# ---------------------------------------------------------------------------
+# Placement + extension candidates (WP-0009 discipline: explicit, reviewable,
+# no silent edits to existing standards/models).
+# ---------------------------------------------------------------------------
+candidates:
+  - id: candidate/repository-layout-standard
+    change_type: new-standard
+    target: infospace/standards/repository-layout/
+    summary: >-
+      Author the InfoTechCanonRepositoryLayoutStandard defining the canonical
+      directory set, yymmdd-prefix conventions (research/, history/), and the
+      SCOPE->INTENT operating mode, referencing existing model concepts.
+    disposition: approved-for-T03
+  - id: candidate/canon-registration
+    change_type: registration
+    target:
+      - canon.yaml (standards:)
+      - infospace/infospace.yaml (disciplines:)
+      - artifact index + retrieval generation
+      - validation.py structural checks
+    summary: Register the new standard so it is loaded, indexed, retrievable, and validated.
+    disposition: approved-for-T03
+  - id: candidate/conformance-levels
+    change_type: standard-internal
+    target: infospace/standards/repository-layout/
+    summary: >-
+      Define graded conformance (e.g. minimal / core / full) so adopting repos
+      can be partial-conformant, honoring the source's recommendation posture.
+    disposition: approved-for-T03
+  - id: candidate/dogfood-canon-repo
+    change_type: repo-reconciliation
+    target: info-tech-canon repo layout
+    summary: >-
+      Reconcile this repo's own layout against the standard and record tensions
+      (repo already uses spec/, wiki/, workplans/, seeds/; infospace uses the
+      distinct kernel/models/standards layout). Decide dogfooding extent.
+    disposition: deferred-to-T04
+  - id: candidate/consumer-adoption-brief
+    change_type: consumer-brief
+    target: infospace/agent/consumer-briefs/ (or evaluations pack)
+    summary: >-
+      Adoption brief so the seven tracked domains can opt in from their own
+      repos; per-repo adoption work stays in consumer repos (WP-0009 boundary).
+    disposition: deferred-to-T05
+
+disposition:
+  outcome: extend_scope_via_new_standard
+  recommended_next_step: Proceed to T03 — author and register the standard.
+  no_silent_edits: true

infospace/evaluations/repository-layout/reconciliation.yaml

@@ -0,0 +1,80 @@
+# Repository Layout Standard — reconciliation against info-tech-canon's own layout
+# ITC-WP-0012-T04. Resolves placement-decision candidate/dogfood-canon-repo.
+type: repo-reconciliation
+workplan: ITC-WP-0012
+task: ITC-WP-0012-T04
+standard: standard/repository-layout
+created: "2026-06-13"
+
+decision:
+  dogfood_extent: partial
+  declared_conformance_level: core
+  summary: >-
+    info-tech-canon adopts the Repository Layout Standard at recommendation
+    level, as-is. It already satisfies the core level and is not restructured to
+    chase full conformance now. The infospace/ content layout is explicitly out
+    of scope of this documentation-layout convention.
+
+current_layout:
+  root_documents:
+    - INTENT.md        # present — Governance (Intent)
+    - SCOPE.md         # present — Governance (Scope)
+  directories_present:
+    - demand/          # transient inbound; emptied + removed after this demand was resolved
+    - spec/            # present
+    - wiki/            # present
+    - workplans/       # present; State-Hub-registered
+    - seeds/           # repo-specific: RC seed corpus, not part of the standard's set
+    - infospace/       # the concrete infospace content (distinct layout, see tension below)
+    - src/ tests/      # Python service shell, not documentation directories
+  directories_absent:
+    - research/        # no dated explorations packaged yet
+    - docs/            # stakeholder docs live inside infospace/ today
+    - issues/          # no external-ticket mirror maintained here
+    - history/         # finished workplans tracked via status, not yet relocated
+
+conformance_assessment:
+  minimal: satisfied        # INTENT.md + SCOPE.md at root
+  core: satisfied           # + demand/ (as-needed), workplans/, docs-equivalent in infospace/
+  full: not_satisfied       # research/, issues/, history/ and yymmdd- prefixes not adopted
+  note: >-
+    Conformance is self-declared and graded (standard §7). The canon claims
+    'core' and omits directories it does not currently need.
+
+tensions:
+  - id: infospace-content-layout
+    tension: >-
+      infospace/ uses a kernel/models/standards/profiles/patterns CONTENT layout,
+      which is a different concern from this DOCUMENTATION layout. The standard's
+      §9 already calls this out; the two layouts coexist and are not reconciled
+      into one.
+    resolution: keep_distinct
+  - id: seeds-directory
+    tension: >-
+      seeds/ is repo-specific (RC seed corpus) and has no slot in the standard's
+      canonical set.
+    resolution: out_of_scope_repo_specific
+  - id: docs-location
+    tension: >-
+      Stakeholder/agent documentation lives under infospace/ (agent briefs,
+      views, retrieval indexes) rather than a root docs/. Functionally covers the
+      docs/ purpose without the directory name.
+    resolution: satisfied_by_equivalent
+  - id: history-relocation
+    tension: >-
+      Finished/canceled workplans currently stay in workplans/ with a status
+      field rather than moving to history/. The standard recommends relocation.
+    resolution: deferred
+    note: >-
+      Not adopted now to avoid churn against State-Hub workplan conventions;
+      revisit if workplans/ grows large enough to clutter working memory.
+
+dogfood_actions_taken:
+  - This demand was processed through demand/ and, once reviewed, the raw file
+    left demand/ for the evaluation pack (source-demand.md); the empty demand/
+    directory was removed — exercising the standard's own demand-resolution rule.
+
+not_done_now:
+  - Creating research/, issues/, or history/ directories.
+  - Relocating finished workplans to history/.
+  - Restructuring infospace/ (explicitly a separate content-layout concern).

infospace/evaluations/repository-layout/source-demand.md

@@ -0,0 +1,32 @@
+This is a canonical layout for repository contained documentation information. There are various perspectives
+on why to document what how. This guide provides a system to allow for efficient retrieval of information. 
+The structure is based in best practices from the CoulombSocial, HelixForge, MarkiTect experiences and will evolve over time. 
+
+This is a recommendation not a strict requirement. 
+Please base the layout of repositories on the following outline:
+
+INTENT.md captures the aspiration and boundries. We will be working to explore the problemspace and implement a 
+solution and capture a top level view of what we achieve in a SCOPE.md file. 
+Our mode of operation will be closing the gap of SCOPE to INTENT while learning and refining both where necessary. There should be a canonical set of directories for documentation structuring our mode of work as follows.
+
+research/ is a directory to provide results about explorations in the problem and solution space. Each exploration should have a yymmdd-prefix to the markdown file or subdirectory if multiple files or sources are provided. The yawex prior art stuff should go there.
+
+demand/ is a inbound directory for feature requests, requirements, suggestions and opportunities to improve. 
+This directory should contain what has not been systematically reviewed and captured in tasks or workplans.
+Information here can be raw and needs additional scrutiny to decide if the implementation should pick up on 
+the demand and how.
+
+spec/ is a directory for specification files that provide guidance and guardrails for the implementation. Typically we will establish a ProductRequirementsDocument.md and TechnicalSpecificationDocument.md and maybe  UseCaseCatalog.md and ArchitectureBlueprint.md files. Background information on those types of documents can be found in the InfoTechPrimers space on coulomb.social.
+
+workplans/ is a directory for all workplan.md that contain tasks for implementation. Those will be registered with the statehub and should conform to the standards provided by the statehub infrastructure. Workplans that have been finished or canceled should move to history
+
+docs/ is a directory for documentation targeted at stakeholders for the repo be it users, developers, humand or agents. If documentation is wrong or stale it can and should be rewritten based on what the repo actually does.
+
+wiki/ is a directory for interconnected collective gathering of information without a specific perspective. This
+directory is powerful if connected with an wiki ui where creators, users and investors can collaborate.
+
+issues/ all or some of this information might be captured systematically as tickes in a ticket system. 
+This directory can provide a mirror of relevant open tickets to ease access to the information from customer 
+support, dev-sec-ops work organization tickets and the like.
+
+history/ is a directory to move material to that is no longer needed but should be kept around. Use yymmdd-prefix to mark when some file or directory has been archived. Stuff in history should only be considered if some research or diagnostic needs it. Files here are out of scope for regular daily tasks to not boggle down working memory unnecessarily.

infospace/indexes/artifact-tree.yaml

@@ -1,5 +1,5 @@
 root: infospace
-file_count: 154
+file_count: 161
 files:
 - path: README.md
   directory: .
@@ -145,6 +145,9 @@ files:
 - path: agent/briefs/standard-caring.md
   directory: agent/briefs
   name: standard-caring.md
+- path: agent/briefs/standard-repository-layout.md
+  directory: agent/briefs
+  name: standard-repository-layout.md
 - path: agent/briefs/standard-tagging.md
   directory: agent/briefs
   name: standard-tagging.md
@@ -229,6 +232,21 @@ files:
 - path: evaluations/repo-scoping/extension-candidates.yaml
   directory: evaluations/repo-scoping
   name: extension-candidates.yaml
+- path: evaluations/repository-layout/consumer-adoption-brief.md
+  directory: evaluations/repository-layout
+  name: consumer-adoption-brief.md
+- path: evaluations/repository-layout/demand-intake.yaml
+  directory: evaluations/repository-layout
+  name: demand-intake.yaml
+- path: evaluations/repository-layout/placement-decision.yaml
+  directory: evaluations/repository-layout
+  name: placement-decision.yaml
+- path: evaluations/repository-layout/reconciliation.yaml
+  directory: evaluations/repository-layout
+  name: reconciliation.yaml
+- path: evaluations/repository-layout/source-demand.md
+  directory: evaluations/repository-layout
+  name: source-demand.md
 - path: evaluations/user-engine/consumer-workplan-brief.md
   directory: evaluations/user-engine
   name: consumer-workplan-brief.md
@@ -430,6 +448,9 @@ files:
 - path: standards/caring/benchmarks/kubernetes-rbac/native-concepts.yaml
   directory: standards/caring/benchmarks/kubernetes-rbac
   name: native-concepts.yaml
+- path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+  directory: standards/repository-layout
+  name: InfoTechCanonRepositoryLayoutStandard.md
 - path: standards/tagging/InfoTechCanonTaggingStandard.md
   directory: standards/tagging
   name: InfoTechCanonTaggingStandard.md

infospace/indexes/concept-ownership.yaml

@@ -1,4 +1,4 @@
-concept_count: 85
+concept_count: 90
 concepts:
 - concept: CARING Kubernetes RBAC Benchmark
   owner: benchmark/caring/kubernetes-rbac
@@ -336,6 +336,26 @@ concepts:
   owner: standard/caring
   path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
   source: frontmatter.owned_concepts
+- concept: InfoTechCanon Repository Layout Standard
+  owner: standard/repository-layout
+  path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+  source: artifact_title
+- concept: CanonicalRepositoryLayout
+  owner: standard/repository-layout
+  path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+  source: frontmatter.owned_concepts
+- concept: RepositoryDocumentationDirectory
+  owner: standard/repository-layout
+  path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+  source: frontmatter.owned_concepts
+- concept: LayoutConformanceLevel
+  owner: standard/repository-layout
+  path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+  source: frontmatter.owned_concepts
+- concept: ScopeIntentOperatingMode
+  owner: standard/repository-layout
+  path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+  source: frontmatter.owned_concepts
 - concept: InfoTechCanon Tagging Standard
   owner: standard/tagging
   path: standards/tagging/InfoTechCanonTaggingStandard.md

infospace/indexes/import-matrix.yaml

@@ -58,6 +58,7 @@ artifacts:
 - small-saas/tenant/globex
 - small-saas/user/ada-admin
 - standard/caring
+- standard/repository-layout
 - standard/tagging
 rows:
 - artifact: benchmark/caring/kubernetes-rbac
@@ -720,6 +721,16 @@ rows:
     - imports
     standard/tagging:
     - imports
+- artifact: standard/repository-layout
+  targets:
+    kernel/itc-core:
+    - conforms_to
+    model/governance:
+    - imports
+    model/information-space:
+    - imports
+    model/task:
+    - imports
 - artifact: standard/tagging
   targets:
     kernel/itc-core:

infospace/infospace.yaml

@@ -35,6 +35,8 @@ disciplines:
     path: standards/tagging/InfoTechCanonTaggingStandard.md
   - name: CARING Access Governance Standard
     path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
+  - name: Repository Layout Standard
+    path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
 schemas:
   standard: schemas/standard.schema.yaml
   concept: schemas/concept.schema.yaml

infospace/standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md

@@ -0,0 +1,214 @@
+---
+id: itc-repo-layout:RepositoryLayoutStandard
+title: InfoTechCanon Repository Layout Standard
+short_name: ITC-REPO-LAYOUT
+type: standard
+standard_family: InfoTechCanon
+repository_context: info-tech-canon
+recommended_path: standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
+status: RC1-seed
+version: 0.1.0-RC1
+canonical_owner: InfoTechCanonRepositoryLayoutStandard
+namespace: itc-repo-layout
+classification: standard
+primary_cluster: documentation-convention
+conformance_posture: recommendation
+imports:
+  - InfoTechCanonCore
+  - InfoTechCanonInformationSpaceModel
+  - InfoTechCanonGovernanceModel
+  - InfoTechCanonTaskModel
+related:
+  - InfoTechCanonKernelMap
+  - InfoTechCanonPurposeDemandExtension
+  - IntentScopePurposesPattern
+owned_concepts:
+  - CanonicalRepositoryLayout
+  - RepositoryDocumentationDirectory
+  - LayoutConformanceLevel
+  - ScopeIntentOperatingMode
+provenance:
+  source_demand: infospace/evaluations/repository-layout/source-demand.md
+  demand_intake: infospace/evaluations/repository-layout/demand-intake.yaml
+  placement_decision: infospace/evaluations/repository-layout/placement-decision.yaml
+  prior_art:
+    - CoulombSocial
+    - HelixForge
+    - MarkiTect
+---
+
+# InfoTechCanon Repository Layout Standard
+
+**Short Name:** `ITC-REPO-LAYOUT`
+**Document Status:** Seed Standard Release Candidate 1
+**Version:** 0.1.0-RC1
+**Repository Context:** `info-tech-canon`
+**Document Type:** InfoTechCanon Domain Standard
+**Conformance Posture:** Recommendation (graded, not mandatory)
+**Intended Audience:** Repository maintainers, project owners, DevSecOps teams,
+documentation authors, knowledge-system builders, and AI agents that retrieve
+from or write into repositories.
+
+---
+
+# 1. Purpose
+
+The **InfoTechCanon Repository Layout Standard** defines a canonical,
+retrieval-oriented documentation layout for repositories: a stable set of
+top-level documents and directories so that humans and agents can locate the
+right information at the right working-memory cost, in any conforming repository,
+by convention rather than per-repo discovery.
+
+It exists to make repository documentation **findable and uniform** without
+forcing every repository into a rigid mold. The source demand is explicit that
+this is a **recommendation, not a strict requirement**; this standard therefore
+encodes graded conformance (§7) so a repository can adopt the parts that fit.
+
+This standard provides:
+
+- a canonical top-level document set (`INTENT.md`, `SCOPE.md`),
+- a canonical documentation directory set
+  (`research/ demand/ spec/ workplans/ docs/ wiki/ issues/ history/`),
+- per-directory semantics that **reference** existing canon model concepts
+  rather than redefining them,
+- naming conventions (the `yymmdd-` prefix for `research/` and `history/`),
+- the SCOPE→INTENT gap-closing operating mode,
+- graded conformance levels,
+- and anti-patterns.
+
+# 2. Position in InfoTechCanon
+
+The Repository Layout Standard is a **domain standard** within InfoTechCanon —
+a named, cross-cutting convention, sibling to the Tagging Standard and the CARING
+Access Governance Standard. It introduces no new domain entities of its own; its
+per-directory semantics **import** concepts already owned by other artifacts and
+must not redefine them:
+
+```text
+Information Space Model
+  owns knowledge packaging, retrieval, links, briefs, and stakeholder docs.
+  -> research/, docs/, wiki/, and the knowledge side of spec/ and history/.
+
+Governance Model
+  owns intent, scope, decisions, directives, and acceptance.
+  -> INTENT.md, SCOPE.md, and the guardrail side of spec/.
+
+Purpose And Demand Model Extension (candidate)
+  owns ConsumerPurpose, DemandSignal, PurposeFit, ScopePressure.
+  -> demand/ as the un-reviewed DemandSignal intake surface.
+
+Task Model
+  owns work items: backlog, readiness, commitment, progress, completion.
+  -> workplans/, issues/ (mirror), and the lifecycle side of history/.
+
+Intent Scope Purposes Pattern (candidate)
+  describes the SCOPE->INTENT gap-closing operating mode this standard adopts.
+```
+
+This standard owns only the **layout convention** itself: which documents and
+directories exist, what each is *for* at the repository level, how they are
+named, and how a repository declares the degree to which it conforms.
+
+# 3. Top-Level Documents
+
+A conforming repository SHOULD provide two orientation documents at its root.
+
+| Document | Captures | Canon owner referenced |
+| --- | --- | --- |
+| `INTENT.md` | The aspiration and boundaries — why the repository exists and what it is trying to become. | Governance (Intent) |
+| `SCOPE.md` | A top-level view of what the repository currently achieves, includes, excludes, and promises. | Governance (Scope) |
+
+`INTENT` and `SCOPE` are kept **distinct** (no-collapse guardrail): intent is the
+aspiration, scope is the current boundary. Consumer purposes are a third plane and
+are **not** recorded here — they belong to the Purpose/Demand surface.
+
+# 4. Canonical Directory Set
+
+Each directory below is a **RepositoryDocumentationDirectory**. The "Owns at repo
+level" column states the repository-level purpose; the "Canon concept referenced"
+column points at the model that already owns the underlying concept. The standard
+never re-defines those concepts.
+
+| Directory | Owns at repo level | Canon concept referenced |
+| --- | --- | --- |
+| `research/` | Results of explorations in the problem and solution space. Each exploration is a `yymmdd-` prefixed file, or a `yymmdd-` prefixed subdirectory when it has multiple files/sources. | Information Space (knowledge packaging, retrieval) |
+| `demand/` | Inbound, **un-reviewed** feature requests, requirements, suggestions, and opportunities. Raw material that still needs scrutiny before becoming work. | Purpose/Demand extension (`DemandSignal` intake) |
+| `spec/` | Specification files that provide guidance and guardrails for implementation — typically `ProductRequirementsDocument.md`, `TechnicalSpecificationDocument.md`, and optionally `UseCaseCatalog.md`, `ArchitectureBlueprint.md`. | Governance (directive) + Information Space (packaging) |
+| `workplans/` | Workplan files carrying implementation tasks, registered with the State Hub and conforming to its conventions. | Task Model |
+| `docs/` | Documentation targeted at stakeholders (users, developers, humans, agents). Rewritten when stale to match what the repo actually does. | Information Space |
+| `wiki/` | Interconnected, perspective-free collective knowledge; powerful when backed by a wiki UI for collaboration. | Information Space |
+| `issues/` | A mirror of relevant open tickets from an external ticket system, for ease of access. The external system remains the system of record. | Task Model (mirror, not source of truth) |
+| `history/` | Material no longer needed for daily work but worth keeping. `yymmdd-` prefixed by archival date; consulted only when research or diagnostics require it, so it does not clutter working memory. | Task Model (lifecycle) + Information Space (archive) |
+
+## 4.1 No-collapse rules
+
+- `demand/` holds un-reviewed `DemandSignal`s; `workplans/` holds committed Tasks.
+  Demand is **pre-work** and must not be treated as a Task until reviewed.
+- `issues/` is a **mirror**; it does not own ticket state.
+- `docs/` is stakeholder-facing truth-to-current-behavior; `wiki/` is
+  perspective-free collaborative knowledge; `research/` is dated exploration.
+  These are distinct and not interchangeable.
+- Finished or canceled workplans **move** from `workplans/` to `history/`.
+
+# 5. Naming Conventions
+
+- **`yymmdd-` prefix** — required for entries in `research/` and `history/`. It
+  records *when* an exploration was performed or *when* material was archived,
+  giving a chronological, sortable retrieval order. A multi-file exploration uses
+  a `yymmdd-` prefixed subdirectory.
+- Specification documents in `spec/` use stable, self-describing names
+  (`ProductRequirementsDocument.md`, etc.) so they are addressable by convention.
+
+# 6. SCOPE→INTENT Operating Mode
+
+The standard adopts the operating mode named in the source demand and described by
+the **Intent Scope Purposes Pattern**:
+
+```text
+INTENT defines where the repository is going.
+SCOPE  defines where the repository currently is.
+Work   = closing the gap from SCOPE to INTENT,
+         refining both as learning accrues.
+```
+
+`demand/` feeds candidate gap-closers in; reviewed demand becomes `workplans/`
+work; `research/` records what was learned while closing the gap; `history/`
+retires what is done. This makes the *reason* a repository's interfaces, specs,
+and scope evolve traceable rather than accidental.
+
+# 7. Conformance
+
+Because the source is explicit that the layout is a recommendation, conformance is
+**graded**. A repository declares its `LayoutConformanceLevel`:
+
+| Level | Requirement |
+| --- | --- |
+| `minimal` | `INTENT.md` and `SCOPE.md` exist at the root. |
+| `core` | `minimal` plus `demand/`, `workplans/`, and `docs/` are present and used as defined. |
+| `full` | `core` plus `research/`, `spec/`, `wiki/`, `issues/`, and `history/` are present, with the `yymmdd-` prefix honored in `research/` and `history/`. |
+
+A repository MAY omit any directory it does not need and still claim the highest
+level it satisfies. Conformance is self-declared; this standard provides the
+vocabulary, not an enforcement gate.
+
+# 8. Anti-Patterns
+
+- **Demand-as-task** — promoting raw `demand/` items straight into work without a
+  review/decision trail. Route them through demand review first.
+- **Scope creep by directory** — letting `spec/` or `docs/` silently redefine
+  `SCOPE.md`; scope changes belong in `SCOPE.md` under governance.
+- **Working-memory clutter** — keeping dead material in active directories instead
+  of moving it to `history/`.
+- **Undated exploration/archive** — `research/` or `history/` entries without a
+  `yymmdd-` prefix, losing chronological retrievability.
+- **Mirror-as-source** — editing `issues/` as if it were the ticket system of
+  record.
+
+# 9. Relationship to This Repository
+
+`info-tech-canon` is itself a producer repository and a candidate adopter. The
+reconciliation of this standard against the canon's own layout — and the decision
+about how far the canon dogfoods it — is recorded alongside this standard's
+evaluation pack (see the repository-layout reconciliation notes). Note that the
+canon's `infospace/` uses a distinct **kernel/models/standards** content layout,
+which is a separate concern from this **documentation** layout.

infospace/validation/latest.json

@@ -1,14 +1,14 @@
 {
   "details": {
-    "artifact_count": 60,
-    "relationship_count": 273
+    "artifact_count": 61,
+    "relationship_count": 277
   },
   "errors": [],
   "metrics": {
     "coherence_components": 1.0,
     "consistency_cycles": 0.0,
     "coverage_ratio": 1.0,
-    "granularity_entropy": 4.32498473489172,
+    "granularity_entropy": 4.329602269609256,
     "redundancy_ratio": 0.0
   },
   "ok": true,

infospace/views/by-concept.md

@@ -2,7 +2,7 @@
 
 # By Concept
 
-Concept count: **85**
+Concept count: **90**
 
 | Concept | Owner | Source |
 | --- | --- | --- |
@@ -90,6 +90,11 @@ Concept count: **85**
 | CARINGAnalysisFitnessTest | `standard/caring` | `frontmatter.owned_concepts` |
 | CARINGAnalysisProcedure | `standard/caring` | `frontmatter.owned_concepts` |
 | CARINGRedesignProcedure | `standard/caring` | `frontmatter.owned_concepts` |
+| InfoTechCanon Repository Layout Standard | `standard/repository-layout` | `artifact_title` |
+| CanonicalRepositoryLayout | `standard/repository-layout` | `frontmatter.owned_concepts` |
+| RepositoryDocumentationDirectory | `standard/repository-layout` | `frontmatter.owned_concepts` |
+| LayoutConformanceLevel | `standard/repository-layout` | `frontmatter.owned_concepts` |
+| ScopeIntentOperatingMode | `standard/repository-layout` | `frontmatter.owned_concepts` |
 | InfoTechCanon Tagging Standard | `standard/tagging` | `artifact_title` |
 
 ## Duplicate Candidates

infospace/views/by-mapping-target.md

@@ -63,6 +63,7 @@
 - `profile/small-saas` via `conforms_to`
 - `review-kit/alignment` via `conforms_to`
 - `standard/caring` via `conforms_to`
+- `standard/repository-layout` via `conforms_to`
 - `standard/tagging` via `conforms_to`
 
 ## `model/access-control`
@@ -137,6 +138,7 @@
 - `review-kit/alignment/workflow` via `uses`
 - `small-saas/policy/tenant-isolation` via `uses`
 - `standard/caring` via `imports`
+- `standard/repository-layout` via `imports`
 
 ## `model/information-space`
 
@@ -145,6 +147,7 @@
 - `comparison/repo-scoping/report` via `uses`
 - `kernel/itc-kernel-map` via `maps`
 - `model/purpose-demand-extension` via `uses`
+- `standard/repository-layout` via `imports`
 
 ## `model/landscape`
 
@@ -264,6 +267,7 @@
 - `review-kit/alignment/workplan-template` via `uses`
 - `small-saas/task/onboard-tenant` via `uses`
 - `standard/caring` via `imports`
+- `standard/repository-layout` via `imports`
 - `standard/tagging` via `imports`
 
 ## `pattern/intent-scope-purposes`

infospace/views/by-standard.md

@@ -23,6 +23,13 @@
 - Path: `standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md`
 - Relationships: 11
 
+## InfoTechCanon Repository Layout Standard
+
+- ID: `standard/repository-layout`
+- Kind: `standard`
+- Path: `standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md`
+- Relationships: 4
+
 ## InfoTechCanon Tagging Standard
 
 - ID: `standard/tagging`

infospace/views/import-matrix.md

@@ -2,65 +2,66 @@
 
 # Import Matrix
 
-| Artifact | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/data` | `model/devsecops` | `model/governance` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/tagging` |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `benchmark/caring/kubernetes-rbac` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `stress_tests` |  | `stress_tests` | `stress_tests` |  |  | `stress_tests` | `stress_tests` |  |  | `stress_tests` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` | `uses` |
-| `benchmark/caring/kubernetes-rbac/access-descriptors` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |
-| `benchmark/caring/kubernetes-rbac/caring-mapping` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  | `maps` |  |  |  |  |  |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |
-| `benchmark/caring/kubernetes-rbac/findings` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` |  |  |  |  |  |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` |  |
-| `benchmark/caring/kubernetes-rbac/native-concepts` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |
-| `comparison/repo-scoping/canon-benefit-analysis` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` |  |  |  |  | `maps` |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |
-| `comparison/repo-scoping/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `comparison/repo-scoping/extension-candidates` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` | `proposes` |  |  |  |  | `proposes` |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `comparison/repo-scoping/frame` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `comparison/repo-scoping/report` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  |  |  |  | `compares` |  | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `concept-catalog/purpose-demand` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `conformance/railiance-fabric` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |
-| `conformance/railiance-fabric/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `conformance/railiance-fabric/entity-edge-capture-criteria` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `conformance/railiance-fabric/mapping-expectations` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` | `maps` |  | `maps` | `maps` | `maps` |  | `maps` | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `conformance/railiance-fabric/visualization-examples` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `illustrates` | `illustrates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `evaluation/user-engine` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |
-| `evaluation/user-engine/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `evaluation/user-engine/interface-card-expectations` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |
-| `evaluation/user-engine/questions` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `evaluation/user-engine/small-saas-alignment` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `example/consumer-purpose-portfolio` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `illustrates` |  |  | `illustrates` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `kernel/itc-core` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `kernel/itc-kernel-map` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` |  | `maps` | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` |
-| `mapping/purpose-demand-governance-candidates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  |  |  | `maps` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/access-control` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/data` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/devsecops` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/governance` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/information-space` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/landscape` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/network` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/observability` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/organization` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/purpose-demand-extension` |  |  |  |  |  |  |  |  |  |  | `introduces` |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `extends` | `uses` |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/security` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/task` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `pattern/intent-scope-purposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `implements` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `profile/small-saas` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `requires` | `requires` | `requires` | `requires` |  | `requires` | `requires` | `requires` | `requires` |  | `requires` | `requires` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `requires` | `requires` |
-| `review-kit/alignment` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |
-| `review-kit/alignment/model-selection-guide` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` |  | `uses` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |
-| `review-kit/alignment/schema` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `review-kit/alignment/scorecard` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `review-kit/alignment/workflow` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `review-kit/alignment/workplan-template` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/control/namespace-per-tenant` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  | `instantiates` |  |  |  |  |  |  |  |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  | `uses` |  |
-| `small-saas/dataset/subscription-ledger` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  | `governed_by` | `owned_by` |  |  |  | `partitioned_for` | `partitioned_for` |  |  |  |
-| `small-saas/deployment/production` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  | `uses` |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `implements` |  |  |  |  |  | `deploys` |  |  |  | `separates` | `separates` |  |  |  |
-| `small-saas/evidence/access-review-2026-05` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/incident/cross-tenant-access-attempt` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  | `instantiates` |  |  |  |  |  |  | `constrained_by` |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/policy/tenant-isolation` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `requires` |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/service/billing-portal` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `owned_by` |  |  |  |  |  |
-| `small-saas/system/billing-system` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `serves` | `serves` |  |  |  |
-| `small-saas/task/onboard-tenant` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  | `governed_by` |  |  |  | `owned_by` | `changes` |  |  |  |  |
-| `small-saas/team/platform` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/tenant/acme` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_by` |  |  |  |  |  |  |  |  |  |  |  | `represented_by` |  |  |
-| `small-saas/tenant/globex` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_by` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/user/ada-admin` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  | `access_evidenced_by` |  | `has_access_under` |  |  |  | `member_of` |  |  |  |  |  |
-| `standard/caring` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `imports` | `imports` | `imports` | `imports` |  |  | `imports` | `imports` | `imports` |  | `imports` | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `imports` |
-| `standard/tagging` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| Artifact | `benchmark/caring/kubernetes-rbac` | `benchmark/caring/kubernetes-rbac/access-descriptors` | `benchmark/caring/kubernetes-rbac/caring-mapping` | `benchmark/caring/kubernetes-rbac/findings` | `benchmark/caring/kubernetes-rbac/native-concepts` | `comparison/repo-scoping/canon-benefit-analysis` | `comparison/repo-scoping/consumer-workplan-brief` | `comparison/repo-scoping/extension-candidates` | `comparison/repo-scoping/frame` | `comparison/repo-scoping/report` | `concept-catalog/purpose-demand` | `conformance/railiance-fabric` | `conformance/railiance-fabric/consumer-workplan-brief` | `conformance/railiance-fabric/entity-edge-capture-criteria` | `conformance/railiance-fabric/mapping-expectations` | `conformance/railiance-fabric/visualization-examples` | `evaluation/user-engine` | `evaluation/user-engine/consumer-workplan-brief` | `evaluation/user-engine/interface-card-expectations` | `evaluation/user-engine/questions` | `evaluation/user-engine/small-saas-alignment` | `example/consumer-purpose-portfolio` | `kernel/itc-core` | `kernel/itc-kernel-map` | `mapping/purpose-demand-governance-candidates` | `model/access-control` | `model/data` | `model/devsecops` | `model/governance` | `model/information-space` | `model/landscape` | `model/network` | `model/observability` | `model/organization` | `model/purpose-demand-extension` | `model/security` | `model/task` | `pattern/intent-scope-purposes` | `profile/small-saas` | `review-kit/alignment` | `review-kit/alignment/model-selection-guide` | `review-kit/alignment/schema` | `review-kit/alignment/scorecard` | `review-kit/alignment/workflow` | `review-kit/alignment/workplan-template` | `small-saas/control/namespace-per-tenant` | `small-saas/dataset/subscription-ledger` | `small-saas/deployment/production` | `small-saas/evidence/access-review-2026-05` | `small-saas/incident/cross-tenant-access-attempt` | `small-saas/policy/tenant-isolation` | `small-saas/service/billing-portal` | `small-saas/system/billing-system` | `small-saas/task/onboard-tenant` | `small-saas/team/platform` | `small-saas/tenant/acme` | `small-saas/tenant/globex` | `small-saas/user/ada-admin` | `standard/caring` | `standard/repository-layout` | `standard/tagging` |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| `benchmark/caring/kubernetes-rbac` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `stress_tests` |  | `stress_tests` | `stress_tests` |  |  | `stress_tests` | `stress_tests` |  |  | `stress_tests` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  | `uses` |
+| `benchmark/caring/kubernetes-rbac/access-descriptors` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
+| `benchmark/caring/kubernetes-rbac/caring-mapping` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  | `maps` |  |  |  |  |  |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |
+| `benchmark/caring/kubernetes-rbac/findings` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` |  |  |  |  |  |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` |  |  |
+| `benchmark/caring/kubernetes-rbac/native-concepts` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |
+| `comparison/repo-scoping/canon-benefit-analysis` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` |  |  |  |  | `maps` |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |
+| `comparison/repo-scoping/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/extension-candidates` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` | `proposes` |  |  |  |  | `proposes` |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/frame` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/report` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  |  |  |  | `compares` |  | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `concept-catalog/purpose-demand` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `conformance/railiance-fabric` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |
+| `conformance/railiance-fabric/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `conformance/railiance-fabric/entity-edge-capture-criteria` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `conformance/railiance-fabric/mapping-expectations` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` | `maps` |  | `maps` | `maps` | `maps` |  | `maps` | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `conformance/railiance-fabric/visualization-examples` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `illustrates` | `illustrates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `evaluation/user-engine` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
+| `evaluation/user-engine/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `evaluation/user-engine/interface-card-expectations` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
+| `evaluation/user-engine/questions` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `evaluation/user-engine/small-saas-alignment` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `example/consumer-purpose-portfolio` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `illustrates` |  |  | `illustrates` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `kernel/itc-core` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `kernel/itc-kernel-map` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` |  | `maps` | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  | `maps` |
+| `mapping/purpose-demand-governance-candidates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  |  |  | `maps` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/access-control` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/data` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/devsecops` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/governance` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/information-space` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/landscape` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/network` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/observability` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/organization` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/purpose-demand-extension` |  |  |  |  |  |  |  |  |  |  | `introduces` |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `extends` | `uses` |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/security` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/task` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `pattern/intent-scope-purposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `implements` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `profile/small-saas` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `requires` | `requires` | `requires` | `requires` |  | `requires` | `requires` | `requires` | `requires` |  | `requires` | `requires` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `requires` |  | `requires` |
+| `review-kit/alignment` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
+| `review-kit/alignment/model-selection-guide` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` | `uses` |  | `uses` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |
+| `review-kit/alignment/schema` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `review-kit/alignment/scorecard` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `review-kit/alignment/workflow` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `review-kit/alignment/workplan-template` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/control/namespace-per-tenant` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  | `instantiates` |  |  |  |  |  |  |  |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  | `uses` |  |  |
+| `small-saas/dataset/subscription-ledger` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  | `governed_by` | `owned_by` |  |  |  | `partitioned_for` | `partitioned_for` |  |  |  |  |
+| `small-saas/deployment/production` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  | `uses` |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `implements` |  |  |  |  |  | `deploys` |  |  |  | `separates` | `separates` |  |  |  |  |
+| `small-saas/evidence/access-review-2026-05` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/incident/cross-tenant-access-attempt` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  | `instantiates` |  |  |  |  |  |  | `constrained_by` |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/policy/tenant-isolation` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `requires` |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/service/billing-portal` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `owned_by` |  |  |  |  |  |  |
+| `small-saas/system/billing-system` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `serves` | `serves` |  |  |  |  |
+| `small-saas/task/onboard-tenant` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  | `governed_by` |  |  |  | `owned_by` | `changes` |  |  |  |  |  |
+| `small-saas/team/platform` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/tenant/acme` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_by` |  |  |  |  |  |  |  |  |  |  |  | `represented_by` |  |  |  |
+| `small-saas/tenant/globex` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_by` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/user/ada-admin` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  | `access_evidenced_by` |  | `has_access_under` |  |  |  | `member_of` |  |  |  |  |  |  |
+| `standard/caring` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `imports` | `imports` | `imports` | `imports` |  |  | `imports` | `imports` | `imports` |  | `imports` | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `imports` |
+| `standard/repository-layout` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `imports` | `imports` |  |  |  |  |  |  | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `standard/tagging` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |

infospace/views/kernel-overview.md

@@ -3,7 +3,7 @@
 # Kernel Overview
 
 - Infospace: `canon`
-- Artifacts: 60
+- Artifacts: 61
 
 ## Artifact Kinds
 
@@ -39,7 +39,7 @@
 - `profile`: 1
 - `profile-alignment`: 1
 - `profile-artifact`: 13
-- `standard`: 2
+- `standard`: 3
 - `visualization-example-set`: 1
 
 ## Relationship Types
@@ -47,7 +47,7 @@
 - `access_evidenced_by`: 1
 - `changes`: 1
 - `compares`: 1
-- `conforms_to`: 18
+- `conforms_to`: 19
 - `constrained_by`: 1
 - `deploys`: 1
 - `evaluates`: 2
@@ -57,7 +57,7 @@
 - `has_access_under`: 1
 - `illustrates`: 4
 - `implements`: 2
-- `imports`: 11
+- `imports`: 14
 - `instantiates`: 13
 - `introduces`: 1
 - `isolated_by`: 2

infospace/views/repository-tree.md

@@ -2,7 +2,7 @@
 
 # Repository Tree
 
-File count: **154**
+File count: **161**
 
 - `README.md`
 - `agent/README.md`
@@ -52,6 +52,7 @@ File count: **154**
 - `agent/briefs/review-kit-alignment-workplan-template.md`
 - `agent/briefs/review-kit-alignment.md`
 - `agent/briefs/standard-caring.md`
+- `agent/briefs/standard-repository-layout.md`
 - `agent/briefs/standard-tagging.md`
 - `agent/consumer-briefs/railiance-fabric.md`
 - `agent/consumer-briefs/repo-scoping.md`
@@ -80,6 +81,11 @@ File count: **154**
 - `evaluations/repo-scoping/comparison-report.md`
 - `evaluations/repo-scoping/consumer-workplan-brief.md`
 - `evaluations/repo-scoping/extension-candidates.yaml`
+- `evaluations/repository-layout/consumer-adoption-brief.md`
+- `evaluations/repository-layout/demand-intake.yaml`
+- `evaluations/repository-layout/placement-decision.yaml`
+- `evaluations/repository-layout/reconciliation.yaml`
+- `evaluations/repository-layout/source-demand.md`
 - `evaluations/user-engine/consumer-workplan-brief.md`
 - `evaluations/user-engine/evaluation-pack.yaml`
 - `evaluations/user-engine/interface-card-expectations.yaml`
@@ -147,6 +153,7 @@ File count: **154**
 - `standards/caring/benchmarks/kubernetes-rbac/caring-mapping.yaml`
 - `standards/caring/benchmarks/kubernetes-rbac/findings-and-canon-pressure.yaml`
 - `standards/caring/benchmarks/kubernetes-rbac/native-concepts.yaml`
+- `standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md`
 - `standards/tagging/InfoTechCanonTaggingStandard.md`
 - `validation/README.md`
 - `validation/latest.json`

registry/README.md

@@ -0,0 +1,12 @@
+# Capability Registry
+
+Markdown-first capability index for federation and reuse planning.
+
+## Authoring
+
+1. Copy a capability entry template (see reuse-surface `templates/capability-entry.template.md`).
+2. Add the row to `indexes/capabilities.yaml`.
+3. Run `reuse-surface validate` from a checkout with the CLI installed.
+4. Merge to `main` and verify publish with `reuse-surface establish --publish-check`.
+
+Federation contract: reuse-surface `docs/RegistryFederation.md`.

registry/indexes/capabilities.yaml

@@ -0,0 +1,4 @@
+version: 1
+updated: '2026-06-16'
+domain: helix_forge
+capabilities: []

tests/test_cli.py

@@ -11,7 +11,7 @@ def test_cli_inspect_emits_json(capsys) -> None:
     assert exit_code == 0
     payload = json.loads(capsys.readouterr().out)
     assert payload["ok"] is True
-    assert payload["infospace"]["artifact_count"] == 60
+    assert payload["infospace"]["artifact_count"] == 61
 
 
 def test_cli_missing_profile_uses_structured_error(capsys) -> None:

tests/test_service.py

@@ -21,7 +21,7 @@ def test_inspect_canon_counts_artifact_kinds() -> None:
 
     assert payload["ok"] is True
     assert payload["infospace"]["slug"] == "canon"
-    assert payload["infospace"]["artifact_count"] == 60
+    assert payload["infospace"]["artifact_count"] == 61
     assert payload["infospace"]["kinds"] == {
         "access-descriptor-set": 1,
         "alignment-review-kit": 1,
@@ -55,14 +55,14 @@ def test_inspect_canon_counts_artifact_kinds() -> None:
         "profile-alignment": 1,
         "profile": 1,
         "profile-artifact": 13,
-        "standard": 2,
+        "standard": 3,
         "visualization-example-set": 1,
     }
 
 
 def test_model_and_standard_lists_are_filtered() -> None:
     assert list_models()["count"] == 11
-    assert list_standards()["count"] == 2
+    assert list_standards()["count"] == 3
 
 
 def test_review_kit_exports_workflow_and_template() -> None:
@@ -90,14 +90,14 @@ def test_validate_canon_passes_scaffold() -> None:
     assert payload["ok"] is True
     assert payload["errors"] == []
     assert "warnings" in payload
-    assert payload["details"]["artifact_count"] == 60
+    assert payload["details"]["artifact_count"] == 61
 
 
 def test_graph_exports_relationship_summary() -> None:
     payload = artifact_graph()
 
     assert payload["ok"] is True
-    assert payload["graph"]["node_count"] == 60
+    assert payload["graph"]["node_count"] == 61
     assert payload["graph"]["edge_count"] > 15
 
 

workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0001
 type: workplan
 title: "Infospace Scaffold And Seed Placement"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: high

workplans/ITC-WP-0002-service-surface-cli-json-api.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0002
 type: workplan
 title: "Service Surface Baseline CLI JSON API"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: high

workplans/ITC-WP-0003-validation-indexes-and-generated-views.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0003
 type: workplan
 title: "Validation Indexes And Generated Views"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: high

workplans/ITC-WP-0004-small-saas-profile-proof.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0004
 type: workplan
 title: "Small SaaS Profile Proof"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: high

workplans/ITC-WP-0005-retrieval-agent-briefs-and-interface-cards.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0005
 type: workplan
 title: "Retrieval Agent Briefs And Interface Cards"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: medium

workplans/ITC-WP-0006-purpose-and-demand-model.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0006
 type: workplan
 title: "Purpose And Demand Model Extension"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: high

workplans/ITC-WP-0007-user-engine-evaluation-readiness.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0007
 type: workplan
 title: "User Engine Evaluation Readiness"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: high

workplans/ITC-WP-0008-railiance-fabric-conformance-support.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0008
 type: workplan
 title: "Railiance Fabric Conformance Support"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: high

workplans/ITC-WP-0009-repo-scoping-comparison-and-extension.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0009
 type: workplan
 title: "Repo Scoping Comparison And Extension"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: high

workplans/ITC-WP-0010-caring-kubernetes-rbac-benchmark.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0010
 type: workplan
 title: "CARING Kubernetes RBAC Benchmark"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: medium

workplans/ITC-WP-0011-canon-consumer-alignment-review-kit.md

@@ -2,7 +2,8 @@
 id: ITC-WP-0011
 type: workplan
 title: "Canon Consumer Alignment Review Kit"
-domain: canon
+domain: infotech
+topic_slug: canon
 repo: info-tech-canon
 status: finished
 priority: high

workplans/ITC-WP-0012-canonical-repository-layout-standard.md

@@ -0,0 +1,167 @@
+---
+id: ITC-WP-0012
+type: workplan
+title: "Canonical Repository Layout Standard Integration"
+domain: infotech
+topic_slug: canon
+repo: info-tech-canon
+status: finished
+priority: medium
+created: "2026-06-08"
+updated: "2026-06-13"
+depends_on_workplans:
+  - ITC-WP-0005
+  - ITC-WP-0006
+state_hub_workstream_id: "f40ecb8b-7d81-46e6-a420-f7843f708175"
+---
+
+# ITC-WP-0012 - Canonical Repository Layout Standard Integration
+
+## Goal
+
+Take the raw demand in `demand/CanonicalRepositoryLayout.md` through the canon's
+own Purpose/Demand intake and integrate it into the canon's line of provided
+structures (kernel / models / standards / profiles / patterns) **without**
+silently editing existing models or collapsing concepts.
+
+## Intent
+
+`demand/CanonicalRepositoryLayout.md` proposes a canonical, retrieval-oriented
+documentation layout for repositories — `INTENT.md` / `SCOPE.md` plus
+`research/`, `demand/`, `spec/`, `workplans/`, `docs/`, `wiki/`, `issues/`,
+`history/` — distilled from CoulombSocial, HelixForge, and MarkiTect experience.
+It is explicitly a *recommendation, not a strict requirement*.
+
+The document arrived in `demand/`, which it itself defines as un-reviewed inbound.
+It must therefore be processed as a `DemandSignal` under the Purpose And Demand
+Model Extension (ITC-WP-0006) before any canon artifact is written. The layout is
+a **named cross-cutting convention**, so the working hypothesis is that it lands
+as a new **standard** whose per-directory semantics *reference* existing models
+(Information Space, Governance + PURPOSES, Task) rather than redefining them. The
+placement decision is an explicit review gate (T02), not a foregone conclusion.
+
+This work follows the WP-0009 discipline: produce a comparison, explicit
+placement/extension candidates, and reviewable deliverables — never blend the new
+convention into existing standards by hand.
+
+## Tasks
+
+### T01 - Demand intake
+
+```task
+id: ITC-WP-0012-T01
+status: done
+priority: high
+state_hub_task_id: "9ea93c0f-e69b-4ab5-81c4-75d43a4273cf"
+```
+
+- Record `demand/CanonicalRepositoryLayout.md` as a `DemandSignal` using the
+  Purpose And Demand Model Extension (`ConsumerPurpose`, `DemandSignal`,
+  `PurposeFit`, `ScopePressure`).
+- Capture provenance: prior art is the CoulombSocial / HelixForge / MarkiTect
+  documentation practice named in the source.
+- Assess fit against current SCOPE.md and flag the scope pressure (this proposes
+  a producer-facing convention the canon does not yet own).
+- Do not author any standard/model artifact in this task — intake only.
+
+### T02 - Placement decision (review gate)
+
+```task
+id: ITC-WP-0012-T02
+status: done
+priority: high
+state_hub_task_id: "55232b4f-f286-410e-9795-99c8a2cdf25b"
+```
+
+- Decide where the convention belongs in the canon line of structures.
+  Recommendation: a new **standard** (sibling to `tagging/` and `caring/`), not a
+  model, profile, or pattern, because it is a named cross-cutting convention.
+- Map each layout element to existing canon ownership so nothing is re-defined:
+  - `INTENT.md` / `SCOPE.md` and the SCOPE→INTENT gap-closing loop → Governance +
+    Purpose/Demand extension.
+  - `demand/` → `DemandSignal` intake surface (Purpose/Demand extension).
+  - `research/`, `docs/`, `wiki/` → Information Space Model (knowledge packaging,
+    retrieval, links, briefs).
+  - `spec/` (PRD / TechSpec / UseCaseCatalog / ArchitectureBlueprint) →
+    Governance + Information Space.
+  - `workplans/` and `history/` (finished/canceled move to history) → Task Model
+    + State Hub workplan conventions.
+  - `issues/` → mirror of an external ticket system; map to Task Model surface.
+- Output explicit placement + extension candidates for review (mirroring
+  WP-0009), not silent edits.
+
+### T03 - Author the standard artifact
+
+```task
+id: ITC-WP-0012-T03
+status: done
+priority: high
+state_hub_task_id: "b9e30be4-c567-4a15-a8ee-8d2898dee9a5"
+```
+
+- Author `infospace/standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md`
+  (namespace e.g. `itc-repo-layout`) defining the canonical directory set, the
+  `yymmdd-` prefix conventions (research/, history/), and the SCOPE→INTENT
+  operating mode.
+- Reference — do not duplicate — concepts owned by Information Space, Governance,
+  Purpose/Demand, and Task models. Honor the no-collapse guardrails.
+- Encode conformance as a **recommendation** (the source is explicit it is not a
+  strict requirement): define conformance levels so adopting repos can be
+  partial-conformant.
+- Register the artifact: add to `canon.yaml`, `infospace/infospace.yaml`
+  disciplines, the artifact index, and retrieval generation; add structural
+  validation for the new standard's directories/relationships.
+
+### T04 - Reconcile and regenerate
+
+```task
+id: ITC-WP-0012-T04
+status: done
+priority: medium
+state_hub_task_id: "8a89122f-737d-4348-83a8-909b251fa1ae"
+```
+
+- Reconcile the standard against this repo's *own* layout and note tensions: the
+  canon already uses `spec/`, `wiki/`, `workplans/`, `seeds/`; the infospace uses
+  the kernel/models/standards layout (a distinct concern from doc layout). Record
+  whether the canon repo will dogfood the convention (e.g. `research/` for the
+  yawex prior art, moving finished workplans to `history/`).
+- Run `make validate`, `make index`, `make tree`, `make agent-briefs`; commit the
+  regenerated indexes, briefs, tree, and `infospace/validation/latest.json`.
+- Move `demand/CanonicalRepositoryLayout.md` to its resolved state once captured
+  (per the convention, reviewed demand leaves the raw inbound directory).
+
+### T05 - Consumer adoption brief
+
+```task
+id: ITC-WP-0012-T05
+status: done
+priority: low
+state_hub_task_id: "7313abf2-e9d3-40d9-8d27-0279d8f4b36c"
+```
+
+- Produce a short adoption brief so the seven tracked domains can opt into the
+  layout from their own repos. Keep per-repo adoption work in those repos, not
+  here (same boundary as WP-0009).
+
+## Acceptance
+
+- The demand is recorded as a reviewed `DemandSignal` with explicit purpose fit
+  and scope pressure.
+- The placement decision and extension candidates are explicit and reviewed
+  before any standard text is written.
+- A registered `repository-layout` standard exists, references (does not
+  duplicate) existing model concepts, and encodes recommendation-level
+  conformance.
+- `make validate` is green; indexes, briefs, tree, and validation output are
+  regenerated.
+- `demand/CanonicalRepositoryLayout.md` no longer sits unreviewed in `demand/`.
+
+## Implementation Notes
+
+- Source demand: `demand/CanonicalRepositoryLayout.md` (recommendation, not a
+  strict requirement; prior art = CoulombSocial / HelixForge / MarkiTect).
+- Follows the WP-0009 pattern: compare, surface candidates, keep consumer
+  adoption in consumer repos.
+- `state_hub_workstream_id` and per-task `state_hub_task_id` are filled in on
+  registration with the State Hub.

workplans/index.yaml

@@ -2,7 +2,7 @@ repository: info-tech-canon
 type: workplan-registry
 status: active
 created: "2026-05-23"
-updated: "2026-05-23"
+updated: "2026-06-08"
 
 implementation_decisions:
   infospace_root: infospace/
@@ -165,3 +165,17 @@ workplans:
       - model and standard selection guide
       - consumer workplan templates
       - CLI JSON API review-kit surface
+
+  - id: ITC-WP-0012
+    title: Canonical Repository Layout Standard Integration
+    status: finished
+    priority: medium
+    path: workplans/ITC-WP-0012-canonical-repository-layout-standard.md
+    depends_on:
+      - ITC-WP-0005
+      - ITC-WP-0006
+    produces:
+      - reviewed repository-layout demand signal
+      - repository-layout standard placement and extension candidates
+      - registered repository-layout standard
+      - consumer adoption brief