Ecosystem Architecture Review — Phase D
A holistic, Enterprise-Architecture-style review of the ecosystem, based only on the portal’s own documented evidence (registries, capability pages, digests, dependency maps, ADRs). It produces recommendations only — no existing architecture is modified. Companion pages: Architecture Risks · Strategic Opportunities · Recommended Architecture Evolution · updated Capability Reuse Map · proposed ADR 0005.
Evidence discipline. Every finding cites a portal page. Nothing new was inferred about implementations; where the portal already records uncertainty (mock-mode, unbuilt loops, declared-not-wired), this review carries that uncertainty forward rather than resolving it.
Executive summary
The ecosystem has a sound layered thesis and strong reuse instincts — most visibly the domain-agnostic, pack-driven Website Assessment engine, where a new vertical is a new pack, not new code. The main architectural weaknesses are not implementation bugs; they are placement and consolidation issues that will compound as the ecosystem grows:
- Reusable capabilities are trapped inside venture/app repositories — most importantly the assessment
engine lives inside
inexisstudios(a venture marketing site), so consumers depend on a venture repo for a platform capability. - Two parallel “opportunity” scoring models and recommendation logic split across three layers create consolidation debt and a risk of prospect-facing inconsistency.
- Foundational loops are unbuilt (FIP Phases 1–5, the lab’s core run/eval loop, the Hermes learning loop) and cross-repo consumption is mostly mock, so the end-to-end capability is proven in spec more than in production.
The headline recommendation is to introduce a Platform Services layer and extract reusable services (assessment, opportunity/COP, retrieval, evaluation) out of venture repos, with the intelligence pack as the single source of truth for rules and scoring. See ADR 0005 (proposed).
Findings at a glance
| # | Area | Key finding | Severity |
|---|---|---|---|
| 1 | Capability ownership | Website Assessment has 4 co-owners and no single accountable owner | High |
| 2 | Duplication | Two opportunity scores; recommendation logic in 3 layers | High |
| 3 | Layer boundaries | Reusable engine sits in a venture repo; “Applications & Agents” conflates services and apps | High |
| 4 | Dependency health | outreachagent → inexisstudios API is a hidden venture-coupling; unused pack dependency in leadplatform |
Medium-High |
| 5 | Capability reuse | Assessment & COP capabilities trapped in apps; lab under-utilised | Medium-High |
| 6 | Information flow | Long intelligence transformation chain; repeated scoring; multiple approval gates | Medium |
1 · Capability Ownership
| Capability | Owner (documented) | Ownership clear? | Appropriate? | Note |
|---|---|---|---|---|
| Reusable AI Skills | shared-skills |
✅ Yes | ✅ Yes | Clean single owner |
| Knowledge Intelligence | personalops/FIP |
✅ Yes | ✅ Yes | Clean |
| Intelligence Productization | intelproducts (+ FIP builders) |
🔶 Mostly | ✅ Yes | Producer (FIP) / contract (intelproducts) split is intentional and documented |
| Reproducible Evaluation | website-intelligence-lab |
✅ Yes | 🔶 See §3 | Owner clear; layer placement questionable |
| Website Assessment | 4 repos (engine/pack/authoring/harness) | ❌ Diffuse | 🔶 Partly | No single accountable owner for the end-to-end capability |
| Commercial Opportunity & Outreach | outreachagent (+ pack skills) |
🔶 Mostly | 🔶 See §5 | Owner is an app; reusable pattern trapped there |
| Architecture & Docs Governance | portfolio-portal |
✅ Yes | ✅ Yes | Clean |
Overlapping responsibilities: scoring and recommendation responsibilities are shared across the engine
(inexisstudios), the pack (intelproducts), and the COP (outreachagent) — see §2.
Recommendations (ownership):
- Designate an explicit capability owner for Website Assessment: the pack (
intelproducts) owns rules & scoring truth; the engine owns execution; the COP owns commercial framing. Document the seam. - Should ownership move? The assessment engine should move out of
inexisstudios(a venture repo) into a platform service (§3). Ownership of the capability then sits with the platform, not a venture.
2 · Duplication (classified)
| Duplication | Evidence | Classification |
|---|---|---|
Opportunity scoring in two places — pack’s 0–100 domain-weighted score vs leadplatform’s own “Opportunity Intelligence” scoring (distinct dimensions) |
Reuse Map; leadplatform opportunity-scoring-spec |
Architectural debt → should be consolidated |
Recommendation logic in three layers — engine rule-based recs → pack recommendation-library (REC-001…015) → COP recommendation.action enum |
cap-website-assessment | Intentional pipeline, but must stay aligned → consolidate source (pack) |
Duplicated intelligence via vendoring — full intelproducts pack tree copied into leadplatform/vendor/ |
intelproducts digest | Intentional (pinned contract) — but drift risk (§4) |
Duplicated / near-duplicate skills — revops⟷revenue-operations, database-designer⟷database-schema-designer, 4 competitor skills, create-llms⟷update-llms |
shared-skills digest, recommendations | Architectural debt → should be consolidated (within the library) |
| Duplicated approval workflows — human-approval gate in FIP (asset promotion), in the engine (report approve), in outreach (“nothing auto-sent”) | personalops, cap-website-assessment | Intentional per domain — candidate for a shared “approval-gate” pattern |
AI prompting surfaces spread across repos — engine “AI-explains” narrative, pack report-generation-guidance, outreach-messaging skills, proposal-generator |
pack + engine + outreach evidence | Temporary → should consolidate a shared claims/tone guardrail (esp. regulated verticals) |
Recommendations (duplication): make the pack the single source of truth for rules, scoring, and
recommendations; have leadplatform consume the assessment/COP rather than maintain a second score; converge
AI prompt surfaces onto a shared, fact-grounded guardrail; consolidate near-duplicate skills.
3 · Layer Boundaries
Current model (6 layers): Shared Skills → Intelligence Platform → Intelligence Products → Applications & Agents → Ventures → Customer-facing. Evaluating each:
| Layer | Boundary assessment |
|---|---|
| Shared Skills | Clear. Minor internal duplication (§2). |
| Intelligence Platform | Blurred: it bundles the knowledge platform (FIP) with the evaluation harness (lab). The lab does not produce intelligence — it evaluates engines. It behaves like a platform service, not an intelligence platform. |
| Intelligence Products | Clear (packs). Minor: consumer skills co-located with product data — acceptable. |
| Applications & Agents | Conflated. This layer currently holds both a reusable service (the assessment engine inside inexisstudios) and venture apps/agents. A reusable, domain-agnostic API is not the same architectural kind as a venture site. |
| Platform Services (not currently a layer) | Missing. The ecosystem has clear platform-service candidates (assessment API, COP evaluation, retrieval, evaluation harness) with no home — so they live inside venture/app repos. |
| Ventures / Customer-facing | Under-populated (vision); fine for now. |
Recommendation: introduce an explicit Platform Services layer between Intelligence Products and the
Applications/Ventures. Reclassify the evaluation harness (lab) and the assessment engine (extracted
from inexisstudios) and the opportunity/COP evaluation as platform services. This tightens the
Intelligence Platform to mean knowledge intelligence (FIP) and gives reusable services a proper home. See
ADR 0005 (proposed) and the target model in
Architecture Evolution.
4 · Dependency Health
| Concern | Evidence | Assessment |
|---|---|---|
| Hidden venture coupling | outreachagent depends on inexisstudios /api/assessments for a core capability |
The assessment API is buried inside a venture marketing-site repo; consumers are coupled to a venture. Missing abstraction: a standalone Assessment Service. |
| Unused / unnecessary dependency | leadplatform vendors the full website-assessment pack but wires only the proposal pack |
Carries an unused dependency; declared-not-wired. |
| Pack drift (hidden dependency) | Consumers pin intelproducts as submodules |
Stale pins = scoring against outdated intelligence — a hidden version dependency. |
| Circular dependencies | Dependency map | None currently. The FIP→pack→engine→outcomes→(Hermes)→pack loop is planned, not yet a cycle; design it as a feedback loop (one-way writes into a new pack version), not a mutation cycle. |
| Two data platforms | Supabase (FIP) + Cloudflare D1/R2 (engine) | Mild fragmentation; a hidden operational dependency on two stores. Not urgent. |
| Missing abstractions | Across capabilities | (a) Assessment Service; (b) one Opportunity-score abstraction; © shared approval-gate; (d) retrieval-as-a-service to reduce vendoring. |
Recommended dependency directions: consumers should depend on platform-service contracts, never on a
venture repo. Extract the Assessment Service so the direction becomes outreachagent → Assessment Service
(platform), not outreachagent → inexisstudios (venture). Keep the FIP→pack→consumer flow one-way; feed
outcomes back only as new pack versions.
5 · Capability Reuse
| Question | Finding |
|---|---|
| Capabilities that should move into the platform | The Assessment engine (from inexisstudios) and the COP/opportunity evaluation (from outreachagent) are reusable and should become platform services. |
| Capabilities trapped inside a venture/app | Assessment engine (in a venture site); COP evaluation (in an outreach agent). |
| Under-utilised platform capabilities | The evaluation harness (lab) — Phase-1 seed, not yet used by the engine (engine self-tests, not lab runs); FIP retrieval (search_assets) — consumers reach intelligence via vendored packs, not the retrieval API; several packs without consumer skills (cinnamon-stories, some domains). |
| Opportunities to reduce future repositories | The pack-driven, domain-agnostic pattern already means new vertical = new pack, not new repo. Extending this to platform services means new venture = compose services + a pack, not a new stack — materially fewer repos over time. |
Recommendation: treat “trapped” capabilities as extraction candidates; make the platform-service + pack composition the default way to launch a venture.
6 · Information Flow
Documented end-to-end lifecycle (see Intelligence Platform runtime flow and Website Assessment runtime):
graph LR
KE[Knowledge estate] --> FIP[FIP capture→approve→structure]
FIP --> KA[(knowledge_assets)]
KA --> SYN[synthesis / builder skills]
SYN --> PACK[(intelligence pack)]
PACK -->|vendored/pinned| ENG[Assessment engine]
URL[Website URL] --> ENG
ENG --> RPT[Report/score]
RPT --> COP[COP]
COP --> OUT[Outreach / CRM]
OUT --> VEN[Venture outcome]
VEN -. future Hermes .-> PACK
Unnecessary transformations / repeated processing (evidence-based):
- Long representation chain for the same intelligence: markdown (estate) →
knowledge_assets→ pack markdown/JSON → enginepack.generated.json→ applied. Each hop is a drift point. Some hops are necessary (contract stability) but the chain is hand-maintained today. - Repeated “opportunity” processing: the pack produces a score and
leadplatformcomputes its own — the same conceptual output twice (§2). - Multiple human-approval gates on one prospect’s journey (asset promotion in FIP upstream; report approval in the engine; send approval in outreach) — governance is correct, but the assessment→outreach path carries two or three gates.
Simplification opportunities: one scoring source; automate the intelligence chain (the
portfolio-portal-orchestrator and pack-publication automation); a retrieval/assessment service to remove
pack vendoring; a single, well-placed approval gate for the assessment→outreach path (keep FIP’s upstream
gate for canonical intelligence).
What this review deliberately does not claim
- It does not assert any capability is more built than the portal already documents (mock-mode, unbuilt FIP phases, Phase-1 lab, declared-not-wired leadplatform all stand).
- It does not redesign implementations — only placement, ownership, and consolidation.
- All structural changes are proposals (see ADR 0005, status proposed); existing architecture is unchanged.