ITC-WP-0012: integrate Repository Layout Standard

Register the InfoTechCanon Repository Layout Standard as a domain standard
(itc-repo-layout), processed from demand through the canon's Purpose/Demand
intake without collapsing existing model concepts.

- Register standard in artifacts/index.yaml, canon.yaml, infospace.yaml;
  regenerate indexes, views, briefs, tree, and validation (validate green).
- T04: add reconciliation.yaml (partial/as-is dogfooding, declared core
  conformance, recorded tensions); resolve the demand by moving it out of
  demand/ to the evaluation pack as source-demand.md and removing demand/.
- T05: add consumer-adoption-brief.md for downstream repos.
- Update test artifact/standard counts (60->61, standards 2->3).
- Mark T03/T04/T05 done; workplan and registry status -> finished.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

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
+- Artifact count: 61
-- Retrieval index items: 60
+- 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,
+    "artifact_count": 61,
-    "relationship_count": 273
+    "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` |
+| 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` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `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/access-descriptors` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
-| `benchmark/caring/kubernetes-rbac/caring-mapping` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  | `maps` |  |  |  |  |  |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |
+| `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/findings` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` |  |  |  |  |  |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` |  |  |
-| `benchmark/caring/kubernetes-rbac/native-concepts` | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |
+| `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/canon-benefit-analysis` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` |  |  |  |  | `maps` |  | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |
-| `comparison/repo-scoping/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `comparison/repo-scoping/extension-candidates` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` | `proposes` |  |  |  |  | `proposes` |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/extension-candidates` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `proposes` | `proposes` |  |  |  |  | `proposes` |  | `proposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `comparison/repo-scoping/frame` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/frame` |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `comparison/repo-scoping/report` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  |  |  |  | `compares` |  | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `comparison/repo-scoping/report` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  |  |  |  | `compares` |  | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `concept-catalog/purpose-demand` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `concept-catalog/purpose-demand` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `conformance/railiance-fabric` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `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/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/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/mapping-expectations` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` | `maps` |  | `maps` | `maps` | `maps` |  | `maps` | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `conformance/railiance-fabric/visualization-examples` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `illustrates` | `illustrates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `conformance/railiance-fabric/visualization-examples` |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `illustrates` | `illustrates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `evaluation/user-engine` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |
+| `evaluation/user-engine` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |
-| `evaluation/user-engine/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `evaluation/user-engine/consumer-workplan-brief` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `evaluation/user-engine/interface-card-expectations` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `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/questions` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` | `uses` |  | `uses` |  |  |  |  | `uses` | `uses` | `uses` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `evaluation/user-engine/small-saas-alignment` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `evaluation/user-engine/small-saas-alignment` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  |  |  |  |  |  |  |  | `uses` |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  | `evaluates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `example/consumer-purpose-portfolio` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `illustrates` |  |  | `illustrates` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `example/consumer-purpose-portfolio` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `illustrates` |  |  | `illustrates` | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `kernel/itc-core` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `kernel/itc-core` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `kernel/itc-kernel-map` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` | `maps` |  | `maps` | `maps` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` | `maps` |
+| `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` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `mapping/purpose-demand-governance-candidates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `maps` |  |  |  |  |  | `maps` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/access-control` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/access-control` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/data` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/data` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/devsecops` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/devsecops` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/governance` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/governance` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/information-space` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/information-space` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/landscape` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/landscape` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/network` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/network` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/observability` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/observability` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/organization` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/organization` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/purpose-demand-extension` |  |  |  |  |  |  |  |  |  |  | `introduces` |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `extends` | `uses` |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/purpose-demand-extension` |  |  |  |  |  |  |  |  |  |  | `introduces` |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  | `extends` | `uses` |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/security` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/security` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `model/task` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `model/task` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `pattern/intent-scope-purposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `implements` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `pattern/intent-scope-purposes` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `implements` |  | `uses` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `profile/small-saas` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `requires` | `requires` | `requires` | `requires` |  | `requires` | `requires` | `requires` | `requires` |  | `requires` | `requires` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `requires` | `requires` |
+| `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` | `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/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/schema` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `review-kit/alignment/scorecard` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `review-kit/alignment/scorecard` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `review-kit/alignment/workflow` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `review-kit/alignment/workflow` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `uses` |  | `uses` |  |  | `part_of` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `review-kit/alignment/workplan-template` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `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/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/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/deployment/production` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  | `uses` |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `implements` |  |  |  |  |  | `deploys` |  |  |  | `separates` | `separates` |  |  |  |  |
-| `small-saas/evidence/access-review-2026-05` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/evidence/access-review-2026-05` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/incident/cross-tenant-access-attempt` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  | `instantiates` |  |  |  |  |  |  | `constrained_by` |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  |  |  |
+| `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/policy/tenant-isolation` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  | `requires` |  |  | `evidenced_by` |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/service/billing-portal` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `owned_by` |  |  |  |  |  |
+| `small-saas/service/billing-portal` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  | `part_of` |  | `owned_by` |  |  |  |  |  |  |
-| `small-saas/system/billing-system` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `serves` | `serves` |  |  |  |
+| `small-saas/system/billing-system` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `serves` | `serves` |  |  |  |  |
-| `small-saas/task/onboard-tenant` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  | `governed_by` |  |  |  | `owned_by` | `changes` |  |  |  |  |
+| `small-saas/task/onboard-tenant` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  | `governed_by` |  |  |  | `owned_by` | `changes` |  |  |  |  |  |
-| `small-saas/team/platform` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
+| `small-saas/team/platform` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
-| `small-saas/tenant/acme` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_by` |  |  |  |  |  |  |  |  |  |  |  | `represented_by` |  |  |
+| `small-saas/tenant/acme` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_by` |  |  |  |  |  |  |  |  |  |  |  | `represented_by` |  |  |  |
-| `small-saas/tenant/globex` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `uses` |  |  |  |  | `instantiates` |  |  |  |  |  |  | `isolated_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` |  |  |  |  |  |
+| `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/caring` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  | `imports` | `imports` | `imports` | `imports` |  |  | `imports` | `imports` | `imports` |  | `imports` | `imports` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `imports` |
-| `standard/tagging` |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  | `conforms_to` |  |  |  |  |  |  |  |  |  |  |  |  |  | `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`

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-0012-canonical-repository-layout-standard.md

@@ -0,0 +1,166 @@
+---
+id: ITC-WP-0012
+type: workplan
+title: "Canonical Repository Layout Standard Integration"
+domain: 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