coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat(ITC-WP-0017): establish AgenticDrivesFunctional pattern
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a025c2-407a-7a32-b40a-f37a52f03f62
This commit is contained in:
tegwick 2026-08-22 18:54:01 +02:00
parent 9e7e1d8c1e
commit 0ab196829e
21 changed files with 725 additions and 109 deletions
Download patch file Download diff file Expand all files Collapse all files

37
infospace/agent/briefs/practice-pattern-agentic-drives-functional.md Normal file
View file

@ -0,0 +1,37 @@
---
id: agent-brief/practice-pattern-agentic-drives-functional
artifact_id: practice-pattern/agentic-drives-functional
source_path: patterns/AgenticDrivesFunctional.md
source_kind: practice-pattern
generated: true
---
<!-- GENERATED by info_tech_canon; do not edit by hand. -->
# Agent Brief: AgenticDrivesFunctional
- Artifact ID: `practice-pattern/agentic-drives-functional`
- Kind: `practice-pattern`
- Canonical path: `patterns/AgenticDrivesFunctional.md`
- Full source: `patterns/AgenticDrivesFunctional.md`
- Summary: Reusable canon PracticePattern: AgenticDrivesFunctional.
## Retrieval Hints
Imports and anchors:
- `model/capability`
- `model/governance`
- `model/observability`
- `model/task`
- `scheme/practice-pattern`
## Owned Concepts
- `AgenticDrivesFunctional`
- `AgenticFallback`
- `DemandSignature`
- `FunctionalInterfaceCandidate`
## Related Distinctions
- **Agentic fallback vs direct functional interface**: Use cross-repository agentic work to interpret novel demand; use an owned API, CLI, or MCP surface when the outcome is stable and recurring.

5
infospace/agent/global-agent-brief.md
View file

@ -5,8 +5,8 @@
This brief summarizes the current canon service surface for agents.
- Infospace slug: `canon`
- Artifact count: 70
- Retrieval index items: 70
- Artifact count: 71
- Retrieval index items: 71
- Primary confidence command: `make validate`
- Refresh generated indexes and views with: `make index`
- Refresh agent briefs and interface templates with: `make agent-briefs`
@ -29,6 +29,7 @@ This brief summarizes the current canon service surface for agents.
## Common Distinctions
- **Agentic fallback vs direct functional interface**: Use cross-repository agentic work to interpret novel demand; use an owned API, CLI, or MCP surface when the outcome is stable and recurring.
- **Interface deprecation vs retirement vs removal**: Deprecation guides and observes callers, retirement ends legacy behavior while retaining a metered tombstone, and removal deletes that tombstone only after the evidence gate passes.
- **Actor vs Subject vs Principal**: Use actor for the acting entity in a context, subject for the entity a policy evaluates, and principal for the authenticated identity bound to access decisions.
- **Organization Role vs AccessRole vs CARING role**: Organization roles describe responsibility or position; access roles describe permissions; CARING roles classify access-governance needs and analysis.

58
infospace/agent/retrieval-index.json
View file

@ -1,5 +1,13 @@
{
"common_distinctions": [
{
"id": "agentic-fallback-direct-interface",
"source_artifacts": [
"practice-pattern/agentic-drives-functional"
],
"summary": "Use cross-repository agentic work to interpret novel demand; use an owned API, CLI, or MCP surface when the outcome is stable and recurring.",
"title": "Agentic fallback vs direct functional interface"
},
{
"id": "interface-deprecation-retirement-removal",
"source_artifacts": [
@ -51,7 +59,7 @@
}
],
"infospace": "canon",
"item_count": 70,
"item_count": 71,
"items": [
{
"canonical_path": "assimilation/it-capability-canon/ASSIMILATION.md",
@ -1531,6 +1539,54 @@
"title": "Intent Scope Purposes Pattern",
"warnings": []
},
{
"canonical_path": "patterns/AgenticDrivesFunctional.md",
"id": "practice-pattern/agentic-drives-functional",
"imports": [
"model/capability",
"model/governance",
"model/observability",
"model/task",
"scheme/practice-pattern"
],
"kind": "practice-pattern",
"owned_concepts": [
"AgenticDrivesFunctional",
"AgenticFallback",
"DemandSignature",
"FunctionalInterfaceCandidate"
],
"relationships": [
{
"target": "scheme/practice-pattern",
"type": "conforms_to"
},
{
"target": "model/capability",
"type": "uses"
},
{
"target": "model/governance",
"type": "uses"
},
{
"target": "model/observability",
"type": "uses"
},
{
"target": "model/task",
"type": "uses"
},
{
"target": "practice-pattern/interface-deprecation-strangler",
"type": "related_to"
}
],
"source_path": "patterns/AgenticDrivesFunctional.md",
"summary": "Reusable canon PracticePattern: AgenticDrivesFunctional.",
"title": "AgenticDrivesFunctional",
"warnings": []
},
{
"canonical_path": "patterns/InterfaceDeprecationStrangler.md",
"id": "practice-pattern/interface-deprecation-strangler",

13
infospace/agent/retrieval-index.md
View file

@ -4,10 +4,11 @@
Schema: `info-tech-canon.retrieval-index.v1`
Infospace: `canon`
Items: **70**
Items: **71**
## Common Distinctions
- **Agentic fallback vs direct functional interface**: Use cross-repository agentic work to interpret novel demand; use an owned API, CLI, or MCP surface when the outcome is stable and recurring. Sources: `practice-pattern/agentic-drives-functional`
- **Interface deprecation vs retirement vs removal**: Deprecation guides and observes callers, retirement ends legacy behavior while retaining a metered tombstone, and removal deletes that tombstone only after the evidence gate passes. Sources: `practice-pattern/interface-deprecation-strangler`
- **Actor vs Subject vs Principal**: Use actor for the acting entity in a context, subject for the entity a policy evaluates, and principal for the authenticated identity bound to access decisions. Sources: `model/organization`, `model/access-control`, `standard/caring`
- **Organization Role vs AccessRole vs CARING role**: Organization roles describe responsibility or position; access roles describe permissions; CARING roles classify access-governance needs and analysis. Sources: `model/organization`, `model/access-control`, `standard/caring`
@ -456,6 +457,16 @@ Items: **70**
- Imports and anchors: `model/governance`, `model/task`
- Owned concepts: `Intent Scope Purposes Pattern`, `IntentScopePurposePattern`
### AgenticDrivesFunctional
- ID: `practice-pattern/agentic-drives-functional`
- Kind: `practice-pattern`
- Canonical path: `patterns/AgenticDrivesFunctional.md`
- Source path: `patterns/AgenticDrivesFunctional.md`
- Summary: Reusable canon PracticePattern: AgenticDrivesFunctional.
- Imports and anchors: `model/capability`, `model/governance`, `model/observability`, `model/task`, `scheme/practice-pattern`
- Owned concepts: `AgenticDrivesFunctional`, `AgenticFallback`, `DemandSignature`, `FunctionalInterfaceCandidate`
### InterfaceDeprecationStrangler
- ID: `practice-pattern/interface-deprecation-strangler`

39
infospace/agent/retrieval-index.yaml
View file

@ -1,6 +1,6 @@
schema: info-tech-canon.retrieval-index.v1
infospace: canon
item_count: 70
item_count: 71
items:
- id: assimilation/it-capability-canon
kind: assimilation
@ -973,6 +973,37 @@ items:
- type: uses
target: model/task
warnings: []
- id: practice-pattern/agentic-drives-functional
kind: practice-pattern
title: AgenticDrivesFunctional
canonical_path: patterns/AgenticDrivesFunctional.md
source_path: patterns/AgenticDrivesFunctional.md
summary: 'Reusable canon PracticePattern: AgenticDrivesFunctional.'
owned_concepts:
- AgenticDrivesFunctional
- AgenticFallback
- DemandSignature
- FunctionalInterfaceCandidate
imports:
- model/capability
- model/governance
- model/observability
- model/task
- scheme/practice-pattern
relationships:
- type: conforms_to
target: scheme/practice-pattern
- type: uses
target: model/capability
- type: uses
target: model/governance
- type: uses
target: model/observability
- type: uses
target: model/task
- type: related_to
target: practice-pattern/interface-deprecation-strangler
warnings: []
- id: practice-pattern/interface-deprecation-strangler
kind: practice-pattern
title: InterfaceDeprecationStrangler
@ -1623,6 +1654,12 @@ items:
target: model/task
warnings: []
common_distinctions:
- id: agentic-fallback-direct-interface
title: Agentic fallback vs direct functional interface
summary: Use cross-repository agentic work to interpret novel demand; use an owned
API, CLI, or MCP surface when the outcome is stable and recurring.
source_artifacts:
- practice-pattern/agentic-drives-functional
- id: interface-deprecation-retirement-removal
title: Interface deprecation vs retirement vs removal
summary: Deprecation guides and observes callers, retirement ends legacy behavior

21
infospace/artifacts/index.yaml
View file

@ -619,6 +619,27 @@ artifacts:
relationships:
- type: conforms_to
target: kernel/itc-core
- id: practice-pattern/agentic-drives-functional
path: patterns/AgenticDrivesFunctional.md
kind: practice-pattern
title: AgenticDrivesFunctional
provenance:
placement: generalized
placement_workplan: ITC-WP-0017
known_use: repo-manager/src/repo_manager/commands/registrar_reconcile.py
relationships:
- type: conforms_to
target: scheme/practice-pattern
- type: uses
target: model/capability
- type: uses
target: model/governance
- type: uses
target: model/observability
- type: uses
target: model/task
- type: related_to
target: practice-pattern/interface-deprecation-strangler
- id: practice-pattern/interface-deprecation-strangler
path: patterns/InterfaceDeprecationStrangler.md
kind: practice-pattern

5
infospace/indexes/artifact-tree.yaml
View file

@ -1,5 +1,5 @@
root: infospace
file_count: 190
file_count: 191
files:
- path: README.md
directory: .
@ -406,6 +406,9 @@ files:
- path: models/task/InfoTechCanonTaskModel.md
directory: models/task
name: InfoTechCanonTaskModel.md
- path: patterns/AgenticDrivesFunctional.md
directory: patterns
name: AgenticDrivesFunctional.md
- path: patterns/InterfaceDeprecationStrangler.md
directory: patterns
name: InterfaceDeprecationStrangler.md

30
infospace/indexes/concept-ownership.yaml
View file

@ -1,4 +1,4 @@
concept_count: 114
concept_count: 119
concepts:
- concept: "Assimilation \u2014 IT Capability Canon (ITCC) v0.1"
owner: assimilation/it-capability-canon
@ -268,6 +268,28 @@ concepts:
owner: pattern/intent-scope-purposes
path: patterns/intent-scope-purposes.md
source: frontmatter.owned_concepts
- &id001
concept: AgenticDrivesFunctional
owner: practice-pattern/agentic-drives-functional
path: patterns/AgenticDrivesFunctional.md
source: artifact_title
- &id002
concept: AgenticDrivesFunctional
owner: practice-pattern/agentic-drives-functional
path: patterns/AgenticDrivesFunctional.md
source: frontmatter.owned_concepts
- concept: AgenticFallback
owner: practice-pattern/agentic-drives-functional
path: patterns/AgenticDrivesFunctional.md
source: frontmatter.owned_concepts
- concept: DemandSignature
owner: practice-pattern/agentic-drives-functional
path: patterns/AgenticDrivesFunctional.md
source: frontmatter.owned_concepts
- concept: FunctionalInterfaceCandidate
owner: practice-pattern/agentic-drives-functional
path: patterns/AgenticDrivesFunctional.md
source: frontmatter.owned_concepts
- concept: InterfaceDeprecationStrangler
owner: practice-pattern/interface-deprecation-strangler
path: patterns/InterfaceDeprecationStrangler.md
@ -456,5 +478,9 @@ concepts:
owner: standard/tagging
path: standards/tagging/InfoTechCanonTaggingStandard.md
source: artifact_title
duplicate_candidates: []
duplicate_candidates:
- normalized: agenticdrivesfunctional
candidates:
- *id001
- *id002
ownership_conflicts: []

15
infospace/indexes/import-matrix.yaml
View file

@ -43,6 +43,7 @@ artifacts:
- model/security
- model/task
- pattern/intent-scope-purposes
- practice-pattern/agentic-drives-functional
- practice-pattern/interface-deprecation-strangler
- practice/intake-and-assimilation
- profile/small-saas
@ -498,6 +499,20 @@ rows:
- implements
model/task:
- uses
- artifact: practice-pattern/agentic-drives-functional
targets:
model/capability:
- uses
model/governance:
- uses
model/observability:
- uses
model/task:
- uses
practice-pattern/interface-deprecation-strangler:
- related_to
scheme/practice-pattern:
- conforms_to
- artifact: practice-pattern/interface-deprecation-strangler
targets:
model/devsecops:

369
infospace/patterns/AgenticDrivesFunctional.md Normal file
View file

@ -0,0 +1,369 @@
---
id: practice-pattern/agentic-drives-functional
title: AgenticDrivesFunctional
type: practice-pattern
scheme: practice-pattern/0.1
status: active
version: "0.1"
summary: Use agentic cross-repository work as a demand sensor, then turn repeated stable demands into direct functional interfaces.
aliases:
- Agentic Demand-to-Interface Loop
- Cross-Repo Demand Compiler
uses:
- model/capability
- model/governance
- model/observability
- model/task
related_patterns:
- practice-pattern/interface-deprecation-strangler
known_uses:
- repo-manager-scoped-identifier-registrar
owned_concepts:
- AgenticDrivesFunctional
- AgenticFallback
- DemandSignature
- FunctionalInterfaceCandidate
---
# AgenticDrivesFunctional
## Intent
Use agentic cross-repository communication to discover and refine missing
capabilities, but do not let recurring agent-to-agent work become a permanent
pseudo-interface. When a stable demand repeats, give its owner a direct API,
CLI, MCP, or equivalent functional surface so callers can obtain the result
without carrying a to-do across coding-agent sessions.
The recurring review question is:
> Can we provide the tasks we need do for others as interfaces they can use
> directly?
Here, *functional* means an interface that directly provides the required
service capability. It does not refer to the functional-programming paradigm.
## Context
Use this pattern where repositories have distinct ownership and their worker
agents can exchange suggestions, requirements, tasks, or workplans. A caller
sometimes needs a result owned by another repository and cannot obtain it from
an existing service API, CLI command, MCP tool, or other discoverable direct
surface.
The demand may initially be too novel or ambiguous to justify an interface.
The target repository's worker can interpret it when that repository next
handles open work. Over time, similar requests may reveal a stable service
capability that callers should no longer need an agent to relay.
## Problem
Cross-repository work records are exceptionally flexible: they preserve an
unresolved need until the right owner can interpret it. That flexibility has a
high marginal cost. Every relay adds queue time, context reconstruction, agent
turns, tokens, status checks, and opportunities to lose constraints. When a
third party must approve part of the work, the to-do and its approval state may
be carried through several sessions without producing the result.
Building an interface for every first request is not a solution. The first
request may be exceptional, its inputs and outputs may still be unclear, and a
premature contract creates maintenance and security obligations. The practice
must use agentic work to learn the right interface, then recognize when the
learning channel has become repetitive overhead.
## Forces
- Novel demands need interpretation, negotiation, and repository-owner
judgment before their contract is known.
- Frequent demands need low latency and predictable cost.
- The target repository owns its capability, security policy, and compatibility
obligations; a caller cannot define these unilaterally.
- Request text varies even when the desired outcome is semantically the same.
- An interface built from one anecdote can fossilize the wrong abstraction.
- A work-record queue tolerates exceptions well but scales poorly as a routine
integration surface.
- APIs, CLIs, and MCP tools have development, documentation, versioning,
observability, and support costs.
- Authorization, credential custody, destructive-action confirmation, and
third-party approval remain necessary even when the surrounding work is
automated.
- Approvals often outlive one agent session and therefore need durable,
queryable state rather than conversational memory.
- The cheapest interface may expose only the stable preparation, validation,
status, or evidence steps while retaining a governed human decision.
## Solution
Therefore, treat agentic cross-repository work as a metered fallback and demand
sensor, and compile repeated stable demand into a direct functional interface:
1. Search the owner's published API, CLI, MCP, capability, and reuse surfaces
before creating cross-repository work.
2. If no adequate direct surface exists, route a typed record to the owning
repository. Use a suggestion for an uncertain opportunity, a requirement
for a needed outcome or constraint, and a task or workplan only after the
owner accepts implementation work.
3. Preserve the request's provenance, desired outcome, inputs, constraints,
urgency, and approval or authority boundary. Do not prescribe an
implementation that belongs to the target owner.
4. Have the owner classify each inbound request by a semantic demand signature:
desired capability, input shape, output or effect, authorization context,
approval needs, and important quality constraints.
5. Review recurring demand signatures. Repetition triggers an interface review,
not automatic implementation. Consider frequency, number of callers,
stability, latency, token cost, failure rate, approval handoffs, and the cost
of maintaining a contract.
6. Extract the stable functional core into the narrowest suitable direct
surface. An API fits service-to-service calls, a CLI fits local or operator
workflows, and MCP fits tool-mediated agent use. A combination may share one
underlying capability contract.
7. Keep governed boundaries explicit. The interface may validate, plan,
estimate, request approval, report approval state, execute an already
authorized operation, and return evidence. It must not invent authority,
expose credentials, or bypass a third party's approval.
8. Publish the interface with ownership, contract, examples, error semantics,
authorization requirements, and discovery metadata. Migrate known callers
and direct new callers to it.
9. Meter both direct use and continued agentic fallback. Retain the fallback for
novel or exceptional cases, while phasing out the repetitive request shape
when evidence shows the interface satisfies it.
The goal is not to eliminate agentic collaboration. It is to reserve that
expensive, general mechanism for ambiguity and change rather than routine
execution.
## Structure
```text
Caller repository
-> discover direct surfaces
-> adequate: call functional interface
-> missing: route typed cross-repo demand
|
Target repository worker
-> interpret and deliver the exceptional request
-> record semantic demand signature + cost + approval boundary
|
Demand review
-> novel/unstable: retain agentic fallback
-> repeated/stable: define functional interface candidate
|
Owned API / CLI / MCP capability
-> direct result, durable approval state, and evidence
-> meter use and remaining fallback
```
The caller owns a clear statement of need. The target repository owns the
capability and interface. The approving party retains approval authority. The
demand review connects observations to an interface decision.
## Dynamics
### 1. Discover before routing
The caller first looks for a supported direct surface. This makes published
interfaces the normal path and prevents stale agent habits from generating
unnecessary tasks.
### 2. Route and learn
When the surface is absent, the caller sends the smallest typed demand record
that preserves the need. The target worker resolves or refines it during its
normal intake cycle and records the semantic demand signature. The work record
is both coordination and evidence of an interface gap.
### 3. Detect recurrence
At an owner-defined cadence, the target reviews semantically equivalent
requests rather than matching titles literally. Recurrence across time or
callers, repeated approval relays, high latency, or disproportionate token cost
can justify an interface candidate. Each repository declares thresholds suited
to its traffic; no universal occurrence count is implied.
### 4. Extract the stable core
The owner separates routine mechanics from judgment. Stable validation,
planning, execution, status, and evidence become callable operations. Novel
policy choices and exceptional negotiation remain agentic. Where third-party
approval is unavoidable, the interface makes the approval request and state
durable but leaves the decision with the authorized party.
### 5. Shift traffic and keep learning
Known callers adopt the new surface. Direct-use and fallback observations show
whether the abstraction is right. A fallback request with a new shape refines
the interface or remains an exception; repeated old-shape requests indicate a
discovery, usability, or coverage problem.
### 6. Strangle the repetitive relay
Once the direct interface is verified, use the evidence and staged guidance of
`InterfaceDeprecationStrangler` where appropriate to stop accepting the old
repetitive route as normal work. Keep an explicit path for genuinely novel
demands.
## Invariants
1. Callers try an adequate discoverable direct interface before routing work to
another repository.
2. A cross-repository demand identifies the owning repository and preserves
provenance, outcome, constraints, and authority boundaries.
3. Target owners classify recurrence by semantic outcome, not wording alone.
4. Repetition creates a review obligation, not an automatic obligation to
publish an interface.
5. The target repository owns the extracted capability contract and its
lifecycle.
6. The direct surface performs or returns the recurring function; merely
automating creation of the same task is not functional extraction.
7. No task, API, CLI, or MCP call transfers authority that the caller does not
possess.
8. Credentials and sensitive approval material remain in their governed
custody boundary.
9. The interface exposes durable status and evidence when execution or approval
is asynchronous.
10. Novel and exceptional requests retain a supported agentic path.
11. Interface and fallback observations are sufficient to decide whether to
expand, correct, retain, or retire either path.
## Evidence
The practice should produce privacy-bounded evidence for:
- the direct surfaces checked before routing;
- typed inbound records and their owning repository;
- semantic demand signatures, occurrences, distinct callers, and time span;
- queue-to-result latency, agent turns or estimated token cost, retries, and
failure outcomes;
- approval handoffs and time spent awaiting authorized decisions;
- the interface-candidate decision and locally chosen threshold or rationale;
- the stable input, output, effect, error, authorization, and evidence contract;
- adoption by known callers and direct-interface usage;
- continued fallback, classified as coverage gap, discoverability problem,
exceptional demand, or caller migration debt; and
- the decision to expand, hold, redesign, or phase out a repetitive path.
Evidence should support an economic and operational judgment. Token count alone
does not prove an interface is worthwhile, and request frequency alone does not
prove the requested operation is safe to automate.
## Consequences
Repeated cross-repository work becomes faster, cheaper, more predictable, and
less dependent on coding-agent continuity. Repository owners learn interface
requirements from observed demand rather than speculation. Approval waiting
can become durable and queryable, reducing repeated explanation without
weakening the approver's control.
The cost is demand classification, metering, interface design, documentation,
compatibility management, and ongoing ownership. Some requests will remain too
rare or judgment-heavy to extract. Running both paths during adoption adds
temporary complexity, and a poorly chosen interface can encode accidental
workflow details as a long-lived contract.
## Failure Modes
- **TaskQueueAsAPI:** routine callers permanently create work records instead
of receiving the function they need.
- **TaskCreationFacade:** a new API only creates the same downstream task and is
presented as functional extraction.
- **OneRequestPlatform:** an interface is built after one exceptional demand
without evidence of stability or recurrence.
- **LiteralDuplicateCounting:** differently worded instances of the same demand
are missed, or similar words with different authority are conflated.
- **OwnerBypass:** callers dictate or implement another repository's contract
without its owner accepting lifecycle responsibility.
- **ApprovalLaundering:** automation treats a routed task or prior conversation
as authorization for a protected operation.
- **CredentialRelay:** secrets are copied through work records because the
interface boundary was designed around convenience rather than custody.
- **GodInterface:** unrelated recurring requests are combined into an overly
broad surface instead of bounded capabilities.
- **InvisibleInterface:** the owner builds a surface but does not publish it, so
agents continue routing tasks.
- **NoEscapeHatch:** the direct interface replaces the only path for novel or
exceptional cases.
- **UnmeteredMigration:** tasks are closed without evidence that callers use the
replacement or that the recurring demand is satisfied.
## When Not to Use
Do not extract a direct interface when demand is genuinely one-off, inputs and
outcomes are still unstable, the work is principally negotiation or creative
judgment, or safe execution cannot be bounded by a service contract. Also do
not delay an obvious, already-defined interface merely to accumulate task
counts; existing standards, controlled callers, and clear ownership may already
provide sufficient evidence.
For emergencies, security incidents, or irreversible operations, follow the
applicable response and approval policy first. The pattern may improve later
handling, but it does not justify waiting for demand analysis or bypassing a
required decision.
## Known Uses
### Repo Manager scoped identifier registrar
HelixForge repositories repeatedly needed State Hub work-record UUIDs assigned
and projected. Coding agents could route the need to the repository or session
holding registrar authority, but each relay consumed context and could stall on
the governed mutation boundary.
`repo-manager` extracted the stable operation into
`rmgr registrar-reconcile`. The command discovers missing workplan and task
identifiers, checks repository cleanliness and upstream synchronization,
verifies the authoritative State Hub, serializes registrar use, invokes the
existing registration adapter, verifies writeback, commits the bounded change,
and can push it. It does not expose registrar credentials or let an ordinary
agent impersonate the registrar. Explicit `--confirm-primary` preserves the
authority-sensitive choice of hub.
This is a concrete demand-to-interface transition: the caller now invokes the
owned CLI directly and receives structured evidence rather than carrying a UUID
assignment task across repository agents. `ITC-WP-0017` itself was registered
through this surface on 2026-08-22.
Implementation references:
- repository: `repo-manager`;
- command: `rmgr registrar-reconcile`;
- implementation: `src/repo_manager/commands/registrar_reconcile.py`; and
- contract: `docs/work-record-uuid-derivation_v1.md`.
### General HelixForge cross-repository routing
HelixForge agents route suggestions, requirements, tasks, and workplans to
repository owners when no direct surface exists. This is observed use of the
demand-sensing fallback, not evidence that every routed demand deserves an
interface. Owners can use the resulting records to identify the next stable
capability worth extracting.
## Related Patterns
`InterfaceDeprecationStrangler`
(`practice-pattern/interface-deprecation-strangler`) complements this pattern
after extraction. `AgenticDrivesFunctional` discovers and establishes the
successor interface from repeated demand; `InterfaceDeprecationStrangler`
guides callers, meters remaining use, and gates retirement of the repetitive
legacy path on evidence.
## Adoption Checklist
- [ ] Publish and make existing API, CLI, MCP, and reuse surfaces discoverable.
- [ ] Define the typed cross-repository fallback and its ownership rules.
- [ ] Capture outcome, constraints, provenance, and approval boundaries.
- [ ] Classify inbound work by semantic demand signature.
- [ ] Choose a review cadence and locally meaningful candidate criteria.
- [ ] Compare relay latency and cost with interface lifecycle cost.
- [ ] Separate stable mechanics from judgment and protected decisions.
- [ ] Give asynchronous approvals durable status without moving authority.
- [ ] Publish the narrowest suitable functional surface and examples.
- [ ] Migrate known callers and meter direct use plus continued fallback.
- [ ] Preserve an explicit route for novel and exceptional demands.
- [ ] Record the evidence and decision for expansion, redesign, or retirement.
## Evolution
Version 0.1 names the feedback loop and records Repo Manager's scoped registrar
as its first complete known use. Further uses should test whether demand
signatures need a shared machine-readable form and whether repos benefit from a
common review report for interface-candidate economics.

1
infospace/patterns/README.md
View file

@ -12,6 +12,7 @@ frontmatter is described by
| PracticePattern | Status | Purpose |
| --- | --- | --- |
| [AgenticDrivesFunctional](AgenticDrivesFunctional.md) | active | Use agentic cross-repo work to discover demand, then extract repeated stable demands into direct functional interfaces. |
| [InterfaceDeprecationStrangler](InterfaceDeprecationStrangler.md) | active | Phase out an interface through caller guidance, usage evidence, staged retirement, and an evidence-gated removal. |
The older [Intent Scope Purposes Pattern](intent-scope-purposes.md) predates the

6
infospace/validation/latest.json
View file

@ -1,14 +1,14 @@
{
"details": {
"artifact_count": 70,
"relationship_count": 296
"artifact_count": 71,
"relationship_count": 302
},
"errors": [],
"metrics": {
"coherence_components": 1.0,
"consistency_cycles": 0.0,
"coverage_ratio": 1.0,
"granularity_entropy": 4.566569747645274,
"granularity_entropy": 4.580874882166957,
"redundancy_ratio": 0.0
},
"ok": true,

9
infospace/views/by-concept.md
View file

@ -2,7 +2,7 @@
# By Concept
Concept count: **114**
Concept count: **119**
| Concept | Owner | Source |
| --- | --- | --- |
@ -73,6 +73,11 @@ Concept count: **114**
| InfoTechCanon Task Model | `model/task` | `artifact_title` |
| Intent Scope Purposes Pattern | `pattern/intent-scope-purposes` | `artifact_title` |
| IntentScopePurposePattern | `pattern/intent-scope-purposes` | `frontmatter.owned_concepts` |
| AgenticDrivesFunctional | `practice-pattern/agentic-drives-functional` | `artifact_title` |
| AgenticDrivesFunctional | `practice-pattern/agentic-drives-functional` | `frontmatter.owned_concepts` |
| AgenticFallback | `practice-pattern/agentic-drives-functional` | `frontmatter.owned_concepts` |
| DemandSignature | `practice-pattern/agentic-drives-functional` | `frontmatter.owned_concepts` |
| FunctionalInterfaceCandidate | `practice-pattern/agentic-drives-functional` | `frontmatter.owned_concepts` |
| InterfaceDeprecationStrangler | `practice-pattern/interface-deprecation-strangler` | `artifact_title` |
| Intake and Assimilation Practice | `practice/intake-and-assimilation` | `artifact_title` |
| Small SaaS System Profile | `profile/small-saas` | `artifact_title` |
@ -123,7 +128,7 @@ Concept count: **114**
## Duplicate Candidates
No duplicate concept candidates detected.
- `agenticdrivesfunctional`
## Ownership Conflicts

9
infospace/views/by-mapping-target.md
View file

@ -110,6 +110,7 @@
## `model/capability`
- `kernel/itc-kernel-map` via `maps`
- `practice-pattern/agentic-drives-functional` via `uses`
## `model/data`
@ -161,6 +162,7 @@
- `model/data` via `uses`
- `model/purpose-demand-extension` via `extends`
- `pattern/intent-scope-purposes` via `uses`
- `practice-pattern/agentic-drives-functional` via `uses`
- `practice-pattern/interface-deprecation-strangler` via `uses`
- `profile/small-saas` via `requires`
- `review-kit/alignment` via `uses`
@ -214,6 +216,7 @@
- `conformance/railiance-fabric/mapping-expectations` via `maps`
- `kernel/itc-kernel-map` via `maps`
- `model/capability` via `uses`
- `practice-pattern/agentic-drives-functional` via `uses`
- `practice-pattern/interface-deprecation-strangler` via `uses`
- `profile/small-saas` via `requires`
- `review-kit/alignment/model-selection-guide` via `uses`
@ -294,6 +297,7 @@
- `model/observability` via `uses`
- `model/purpose-demand-extension` via `uses`
- `pattern/intent-scope-purposes` via `uses`
- `practice-pattern/agentic-drives-functional` via `uses`
- `profile/small-saas` via `requires`
- `review-kit/alignment` via `uses`
- `review-kit/alignment/model-selection-guide` via `uses`
@ -311,6 +315,10 @@
- `comparison/repo-scoping/report` via `uses`
- `example/consumer-purpose-portfolio` via `illustrates`
## `practice-pattern/interface-deprecation-strangler`
- `practice-pattern/agentic-drives-functional` via `related_to`
## `profile/small-saas`
- `evaluation/user-engine` via `evaluates`
@ -341,6 +349,7 @@
## `scheme/practice-pattern`
- `practice-pattern/agentic-drives-functional` via `conforms_to`
- `practice-pattern/interface-deprecation-strangler` via `conforms_to`
## `small-saas/control/namespace-per-tenant`

145
infospace/views/import-matrix.md
View file

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

9
infospace/views/kernel-overview.md
View file

@ -3,7 +3,7 @@
# Kernel Overview
- Infospace: `canon`
- Artifacts: 70
- Artifacts: 71
## Artifact Kinds
@ -39,7 +39,7 @@
- `native-concept-map`: 1
- `pattern`: 1
- `practice`: 1
- `practice-pattern`: 1
- `practice-pattern`: 2
- `practice-pattern-scheme`: 1
- `profile`: 1
- `profile-alignment`: 1
@ -52,7 +52,7 @@
- `access_evidenced_by`: 1
- `changes`: 1
- `compares`: 1
- `conforms_to`: 24
- `conforms_to`: 25
- `constrained_by`: 1
- `deploys`: 1
- `derived_from`: 1
@ -73,9 +73,10 @@
- `part_of`: 22
- `partitioned_for`: 2
- `proposes`: 7
- `related_to`: 1
- `represented_by`: 1
- `requires`: 13
- `separates`: 2
- `serves`: 2
- `stress_tests`: 6
- `uses`: 121
- `uses`: 125

3
infospace/views/repository-tree.md
View file

@ -2,7 +2,7 @@
# Repository Tree
File count: **190**
File count: **191**
- `README.md`
- `agent/README.md`
@ -139,6 +139,7 @@ File count: **190**
- `models/organization/InfoTechCanonOrganizationModel.md`
- `models/security/InfoTechCanonSecurityModel.md`
- `models/task/InfoTechCanonTaskModel.md`
- `patterns/AgenticDrivesFunctional.md`
- `patterns/InterfaceDeprecationStrangler.md`
- `patterns/PracticePatternScheme.md`
- `patterns/README.md`

11
src/info_tech_canon/generation.py
View file

@ -48,6 +48,17 @@ RETRIEVAL_ARTIFACT_KINDS = {
}
CONSUMER_BRIEF_IDS = ("user-engine", "railiance-fabric", "repo-scoping")
COMMON_DISTINCTIONS = [
{
"id": "agentic-fallback-direct-interface",
"title": "Agentic fallback vs direct functional interface",
"summary": (
"Use cross-repository agentic work to interpret novel demand; use an "
"owned API, CLI, or MCP surface when the outcome is stable and recurring."
),
"source_artifacts": [
"practice-pattern/agentic-drives-functional",
],
},
{
"id": "interface-deprecation-retirement-removal",
"title": "Interface deprecation vs retirement vs removal",

2
tests/test_cli.py
View file

@ -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"] == 70
assert payload["infospace"]["artifact_count"] == 71
def test_cli_missing_profile_uses_structured_error(capsys) -> None:

23
tests/test_service.py
View file

@ -25,7 +25,7 @@ def test_inspect_canon_counts_artifact_kinds() -> None:
assert payload["ok"] is True
assert payload["infospace"]["slug"] == "canon"
assert payload["infospace"]["artifact_count"] == 70
assert payload["infospace"]["artifact_count"] == 71
assert payload["infospace"]["kinds"] == {
"access-descriptor-set": 1,
"alignment-review-kit": 1,
@ -59,7 +59,7 @@ def test_inspect_canon_counts_artifact_kinds() -> None:
"native-concept-map": 1,
"pattern": 1,
"practice": 1,
"practice-pattern": 1,
"practice-pattern": 2,
"practice-pattern-scheme": 1,
"profile-alignment": 1,
"profile": 1,
@ -99,25 +99,28 @@ def test_validate_canon_passes_scaffold() -> None:
assert payload["ok"] is True
assert payload["errors"] == []
assert "warnings" in payload
assert payload["details"]["artifact_count"] == 70
assert payload["details"]["artifact_count"] == 71
def test_graph_exports_relationship_summary() -> None:
payload = artifact_graph()
assert payload["ok"] is True
assert payload["graph"]["node_count"] == 70
assert payload["graph"]["node_count"] == 71
assert payload["graph"]["edge_count"] > 15
def test_interface_deprecation_strangler_is_a_registered_practice_pattern() -> None:
def test_practice_patterns_are_registered() -> None:
payload = list_artifacts(kind="practice-pattern")
assert payload["count"] == 1
pattern = payload["artifacts"][0]
assert pattern["id"] == "practice-pattern/interface-deprecation-strangler"
assert pattern["title"] == "InterfaceDeprecationStrangler"
assert pattern["path"] == "patterns/InterfaceDeprecationStrangler.md"
assert payload["count"] == 2
patterns = {pattern["id"]: pattern for pattern in payload["artifacts"]}
agentic = patterns["practice-pattern/agentic-drives-functional"]
assert agentic["title"] == "AgenticDrivesFunctional"
assert agentic["path"] == "patterns/AgenticDrivesFunctional.md"
strangler = patterns["practice-pattern/interface-deprecation-strangler"]
assert strangler["title"] == "InterfaceDeprecationStrangler"
assert strangler["path"] == "patterns/InterfaceDeprecationStrangler.md"
def test_capability_review_joins_a_minimal_record(tmp_path) -> None:

24
workplans/ITC-WP-0017-agentic-drives-functional.md
View file

@ -5,7 +5,7 @@ title: "AgenticDrivesFunctional PracticePattern"
domain: infotech
topic_slug: canon
repo: info-tech-canon
status: active
status: finished
priority: medium
created: "2026-08-22"
updated: "2026-08-22"
@ -31,7 +31,7 @@ and approval relays.
```task
id: ITC-WP-0017-T01
status: progress
status: done
priority: high
state_hub_task_id: "dc7f97f0-251c-5344-a951-12f66c58b71e"
```
@ -45,7 +45,7 @@ clear.
```task
id: ITC-WP-0017-T02
status: pending
status: done
priority: medium
state_hub_task_id: "ce2cb013-7f15-5818-b80b-0cb1f52ddaab"
```
@ -56,15 +56,23 @@ the canon.
## Acceptance
- [ ] `AgenticDrivesFunctional` conforms to PracticePattern v0.1.
- [ ] The pattern distinguishes direct interfaces from cross-repo task routing.
- [ ] Repetition is treated as evidence for interface review, not an automatic
- [x] `AgenticDrivesFunctional` conforms to PracticePattern v0.1.
- [x] The pattern distinguishes direct interfaces from cross-repo task routing.
- [x] Repetition is treated as evidence for interface review, not an automatic
mandate to build an interface.
- [ ] Interfaces preserve authorization, credential custody, and third-party
- [x] Interfaces preserve authorization, credential custody, and third-party
approval boundaries.
- [ ] The pattern is registered, retrieval-visible, validated, committed, and
- [x] The pattern is registered, retrieval-visible, validated, committed, and
synchronized.
## Result
Completed 2026-08-22. The canon now carries the active
`AgenticDrivesFunctional` PracticePattern, backed by Repo Manager's scoped
identifier registrar as its first complete known use. The artifact is indexed,
agent-retrievable, related to `InterfaceDeprecationStrangler`, and validated by
the canon service and full test suite.
## Out of scope
- Implementing a new service API, CLI, or MCP interface in a consumer repo.