Capability Decision Framework

For any proposed feature, service, or repository, this framework decides where it belongs in the layered architecture — before it is built. Use it with the Capability Decision Matrix (the quick lookup) and the four-part test (the gate).

Destinations map to the ecosystem layers. Platform Services is a proposed layer (ADR 0005, status proposed); until adopted, its candidates live at the Applications layer but should be built extraction-ready.

Primary decision tree

graph TD
    START([Proposed feature / service / repo]) --> GATE{Passes the four-part test?<br/>real problem · reduces coupling · clear owner · one-paragraph}
    GATE -->|no| WAIT[[Wait / reject — record why]]
    GATE -->|yes| Q1{Is it reusable AI behaviour / competence<br/>usable by many repos?}
    Q1 -->|yes| SS[[Shared Skills · L1]]
    Q1 -->|no| Q2{Does it capture / structure / retrieve<br/>knowledge into intelligence?}
    Q2 -->|yes| IP[[Intelligence Platform · L2]]
    Q2 -->|no| Q3{Is it a published, versioned,<br/>immutable artefact consumers pin?}
    Q3 -->|yes| IPR[[Intelligence Products · L3]]
    Q3 -->|no| Q4{Is it a reusable service<br/>used across ≥2 ventures?<br/>assessment · opportunity · retrieval · evaluation}
    Q4 -->|yes| PS[[Platform Services · L4 — proposed]]
    Q4 -->|no| Q5{Is it specific to one venture / an app or agent?}
    Q5 -->|yes| VEN[[Venture / Application · L5]]
    Q5 -->|no| Q6{Is it a customer-touching experience?}
    Q6 -->|yes| CX[[Customer-facing Solution · L6]]
    Q6 -->|no| Q7{Is it documentation / architecture governance?}
    Q7 -->|yes| DOCS[[portfolio-portal · Docs/Governance]]
    Q7 -->|no| Q8{Is it automation of the portal itself?}
    Q8 -->|yes| ORCH[[orchestrator skill · Docs/Automation]]
    Q8 -->|no| REVIEW[[Ambiguous → architecture review]]

Secondary checks (after a destination is chosen)

“Is it really reusable, or venture-specific?” (the trap to avoid)

The review found reusable capabilities trapped inside venture repos (Architecture Review §5). Apply this test:

graph TD
    A{Would a second venture want this unchanged?} -->|yes| B{Is it currently inside a venture repo?}
    A -->|no| VEN[Keep in the venture]
    B -->|yes| EXTRACT[[Extraction candidate → Platform Services]]
    B -->|no| OK[Correctly placed]

“Infrastructure?” resolution

Infrastructure is not a separate layer — it belongs within the platform/service it hosts (e.g. the WIL Docker/Caddy stack lives in website-intelligence-lab). Route infrastructure to the owning platform, not a new repo.

“Intelligence vs product?” resolution

If it captures/structures/retrieves → Intelligence Platform (L2).
If it is the published, versioned output → Intelligence Products (L3).
The producer/consumer split (ADR 0003) is the deciding line.

Worked examples (evidence-based)

Proposal	Path through the tree	Destination
A new documentation skill	Q1 yes (reusable competence)	Shared Skills (L1)
A new industry assessment pack	Q3 yes (published, versioned, immutable)	Intelligence Products (L3)
The assessment engine (existing, in `inexisstudios`)	Q4 yes (reusable across ventures)	Platform Services (L4, proposed) — currently trapped in a venture (extraction candidate)
A retrieval API over `knowledge_assets`	Q4 yes (reusable service)	Platform Services (L4, proposed)
Inbound Lanka’s booking site	Q5 → Q6 yes (customer experience)	Customer-facing (L6)
A new capability page	Q7 yes	portfolio-portal (Docs)

Rules of thumb

Default to the lowest reusable layer a thing can honestly live at — it maximises leverage (Principle 9).
Never place a reusable service inside a venture repo — build it extraction-ready.
When ambiguous, review — don’t guess; run an architecture review and record an ADR.