Capability Reuse Map

For every major capability: who provides it, who consumes it, what assets are shared, what intelligence it depends on, where there are reuse opportunities, and where there are duplication risks. This is the reuse-and-risk companion to the Capability Registry. Evidence-based; honesty markers ✅ / 🔶 / ⏳ / 🧭.

Reuse table

Capability	Provider	Consumers	Shared assets	Intelligence dependencies	Reuse opportunities	Duplication risks
Reusable AI Skills	`shared-skills`	all layers	169 skills, scripts, templates	— (foundation)	Package as a distributable skills pack	Duplicate skills within the library (revops/revenue-operations, etc.)
Knowledge Intelligence	`personalops`/FIP	FIP, packs, agents	`knowledge_assets`, `search_assets()`	knowledge estate	One retrieval layer for proposal/outreach/assessment	—
Intelligence Productization	`intelproducts` (+FIP)	`leadplatform`, `outreachagent`	versioned packs + consumer skills	Knowledge Intelligence	New industry/venture packs from same engine	Packs vendored per-consumer (submodule) can drift if not re-pinned
Reproducible Evaluation	`website-intelligence-lab`	external engines	Runs, benchmarks, reference catalog	—	Evaluate any engine (assessment, migration, proposal)	Engine-side scoring vs lab benchmark could diverge if not both provenanced
Website Assessment	`inexisstudios` + `intelproducts` + `personalops` + lab	`outreachagent` ✅, `leadplatform` ⏳	pack (rules/scoring/recs), `/api/assessments` contract	Knowledge Intelligence, Productization	Domain-agnostic + pack-driven → new verticals = new packs (cleaning, travel proven)	Two opportunity-scoring models (pack scoring vs leadplatform’s own); recommendation logic in 3 places
Commercial Opportunity & Outreach	`outreachagent` (+ packs)	Inexis Digital sales	COP schema v2 (frozen), outreach-messaging skills	Website Assessment	COP contract reusable by leadplatform	leadplatform maintains a separate opportunity score (potential overlap with COP)
Architecture & Docs Governance	`portfolio-portal` (+skills)	whole ecosystem	digests, diagrams, ADRs, `llms.txt`	Reusable AI Skills	Automate via orchestrator	—

Provider → consumer graph

graph TD
    SKILLS[[Reusable AI Skills]]:::prov
    KI[[Knowledge Intelligence]]:::prov
    IPZ[[Intelligence Productization]]:::prov
    EVAL[[Reproducible Evaluation]]:::prov
    WA[[Website Assessment]]:::prov
    CO[[Commercial Opportunity & Outreach]]:::prov
    GOV[[Architecture & Docs Governance]]:::prov

    SKILLS -.underpins.-> KI & IPZ & EVAL & WA & CO & GOV
    KI --> IPZ --> WA
    EVAL -.evaluates.-> WA
    WA --> CO
    CO --> INEXIS[Inexis Digital venture]
    IPZ -->|proposal pack| LEAD[leadplatform]
    WA -.declared.-> LEAD
    classDef prov fill:#e6f0ff,stroke:#356;

Duplication-risk hotspots

graph LR
    subgraph Risk1["⚠ Opportunity scoring in two places"]
        PACKSCORE["intelproducts pack<br/>domain-weighted 0–100 score"]
        LEADSCORE["leadplatform<br/>own 'Opportunity Intelligence' scoring<br/>(distinct dimensions)"]
    end
    subgraph Risk2["⚠ Recommendation logic layered in three places"]
        ENGREC["inexisstudios engine<br/>rule-based recommendations"]
        PACKREC["intelproducts<br/>recommendation-library REC-001…015"]
        COPREC["outreachagent COP<br/>recommendation.action enum"]
    end
    PACKSCORE -.risk of divergence.- LEADSCORE
    ENGREC -.must stay aligned.- PACKREC -.must stay aligned.- COPREC

Findings & recommendations (recorded, not actioned)

Two opportunity scores. intelproducts pack scoring (website quality, 0–100) and leadplatform’s own “Opportunity Intelligence” scoring use different dimensions (leadplatform/docs/specs/opportunity-scoring-spec.md). Reuse opportunity: have leadplatform consume the assessment/COP rather than maintain a parallel score. Risk: two “opportunity” numbers that can disagree in front of a prospect.
Recommendation logic in three layers (engine rules → pack library → COP action). This is a deliberate pipeline, but the three must stay aligned; a change to pack REC-* should be reflected in the engine and COP mapping. Recommend: treat the pack as the single source and pin versions everywhere.
Pack drift via vendoring. Consumers vendor intelproducts as pinned submodules — good for stability, but stale pins mean consumers score against old intelligence. Recommend: track pinned pack versions in the registry.
Strong reuse win: the engine is domain-agnostic + pack-driven — new verticals/ventures (cleaning, travel→Inbound Lanka) are new packs, not new code. This is the ecosystem’s best demonstrated reuse and should be the template for future capabilities.

Promote any accepted item to an ADR; see architecture recommendations for the running log and ADR 0004.

Phase-D ecosystem-review update (2026-07-05)

The Phase-D Architecture Review re-examined reuse across the whole ecosystem. Updated conclusions:

Reusability verdict per capability

Capability	Genuinely reusable?	Blocker to reuse	Action
Reusable AI Skills	✅ Yes	Internal duplication only	Consolidate near-duplicates
Knowledge Intelligence	🔶 Partly	Retrieval API unbuilt (FIP Phases 1–5)	Build capture→retrieve; expose retrieval-as-a-service
Intelligence Productization	✅ Yes	Vendoring drift	Track pins in registry
Reproducible Evaluation	🔶 Under-utilised	Phase-1 seed; engine not yet run against it	Wire the engine’s runs through the lab
Website Assessment	✅ Reusable engine, ❌ trapped in a venture repo	Lives inside `inexisstudios`	Extract to a Platform Service (R1)
Commercial Opportunity	🔶 Reusable pattern, trapped in `outreachagent`	COP logic in an app	Extract COP/opportunity evaluation to a service
Architecture & Docs Governance	✅ Yes	Manual upkeep	Build the orchestrator

Capabilities that should move into the platform

Assessment engine (inexisstudios → Platform Services).
Opportunity/COP evaluation (outreachagent → Platform Services).
Retrieval (expose FIP search_assets as a service to replace pack vendoring).

Capabilities trapped inside a venture / app

Website Assessment (venture marketing site); Commercial Opportunity (outreach agent).

Under-utilised platform capabilities

Reproducible Evaluation (lab, Phase-1 seed); FIP retrieval; packs without consumer skills (cinnamon-stories, some domains).

Opportunities to reduce future repositories

Make service + pack composition the default launch pattern → new venture = compose, not build → fewer repos.

Direction change proposed in ADR 0005 (status: proposed). Full analysis: Architecture Review, Risks, Opportunities, Evolution.