{"schemaVersion":1,"stats":{"generatedAt":null,"totalNodes":150,"totalEdges":740,"pages":70,"repositories":7,"capabilities":7,"ventures":2,"layers":4,"technologies":20,"adrs":7,"principles":12,"operatingPrinciples":9,"glossaryTerms":32,"diagrams":61,"edgeTypes":{"references":553,"implements":12,"providedBy":12,"inLayer":13,"relatedCapability":13,"consumes":15,"consumedBy":15,"relatesTo":46,"belongsToLayer":7,"usesTechnology":24,"supportsRepository":24,"inSystem":3,"hasMember":3}},"nodes":[{"id":"/architecture/architecture-evolution","kind":"page","entityType":"architecture","title":"Recommended Architecture Evolution","route":"/architecture/architecture-evolution","sourcePath":"portal/architecture/architecture-evolution.md","slug":null,"frontmatter":{"title":"Recommended Architecture Evolution","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Where the ecosystem should go over 12–24 months, expressed as target architecture (not implementation","headings":[{"depth":2,"text":"A · Current architecture (as documented)","id":"a-current-architecture-as-documented"},{"depth":2,"text":"B · Recommended architecture (12–24 months)","id":"b-recommended-architecture-12-24-months"},{"depth":2,"text":"C · Long-term vision (24 months +)","id":"c-long-term-vision-24-months"},{"depth":2,"text":"Horizon summary","id":"horizon-summary"},{"depth":2,"text":"Related","id":"related"}],"diagrams":3,"links":["architecture-review.md","../decisions/0005-platform-services-and-consolidation.md","strategic-opportunities.md","architecture-review.md","architecture-risks.md","strategic-opportunities.md","../decisions/0005-platform-services-and-consolidation.md","../portfolio-overview.md","principles.md"],"body":"\n# Recommended Architecture Evolution\n\nWhere the ecosystem should go over **12–24 months**, expressed as **target architecture** (not implementation\ndetail). Produced by the [Phase-D Architecture Review](/architecture/architecture-review). It cleanly separates three\nhorizons: **current**, **recommended (12–24 mo)**, and **long-term vision**. All of this is a **recommendation**\n— the current architecture is unchanged; direction changes are proposed in\n[ADR 0005](/decisions/0005-platform-services-and-consolidation).\n\n---\n\n## A · Current architecture (as documented)\n\nSix layers, with reusable capabilities embedded inside venture/app repos and manual portal upkeep.\n\n```mermaid\ngraph TD\n L1[L1 Shared Skills ✅] --> L2[L2 Intelligence Platform
FIP 🔶 + Lab 🔶]\n L2 --> L3[L3 Intelligence Products
intelproducts ✅]\n L3 --> L4[L4 Applications & Agents
inexisstudios · leadplatform · outreachagent 🔶]\n L4 --> L5[L5 Ventures 🧭]\n L5 --> L6[L6 Customer-facing 🧭]\n note[Reusable assessment engine lives INSIDE inexisstudios;
two opportunity scores; loops unbuilt; portal maintained by hand]\n L4 -.-> note\n```\n\n**Characteristics (documented):** strong pack-driven reuse; but the assessment engine is trapped in a venture\nrepo, opportunity scoring is duplicated, foundational loops (FIP 1–5, lab core, Hermes) are unbuilt, cross-repo\nconsumption is mostly mock, and the portal is hand-maintained.\n\n---\n\n## B · Recommended architecture (12–24 months)\n\nIntroduce a **Platform Services** layer, extract reusable services, make the **pack the single source of truth**,\nand automate the portal. Ventures become **thin compositions** of services + packs.\n\n```mermaid\ngraph TD\n L1[L1 · Shared Skills] --> L2[L2 · Intelligence Platform
FIP knowledge only]\n L2 --> L3[L3 · Intelligence Products
packs = single source of truth]\n L3 --> PS[L4 · Platform Services ⟵ NEW
Assessment · Opportunity/COP · Retrieval · Evaluation]\n PS --> L5[L5 · Ventures & Apps
thin: compose services + a pack]\n L5 --> L6[L6 · Customer-facing]\n ORCH[[portfolio-portal-orchestrator]] -.auto-documents.-> ALL[(the whole ecosystem)]\n OUT[Outcomes] -. one-way Hermes feedback .-> L3\n\n classDef new fill:#e6ffe6,stroke:#1f7a1f;\n class PS new;\n```\n\n**Key moves (each tied to a review finding):**\n| Move | Addresses | From → To |\n|------|-----------|-----------|\n| **Extract a Platform Services layer** | §3, R1 | Reusable services live in venture repos → in the platform |\n| **Assessment Service** (out of `inexisstudios`) | R1, §5 | `outreachagent → inexisstudios` (venture) → `→ Assessment Service` (platform) |\n| **Single scoring source** (pack) | §2, R2 | Two opportunity scores → one; recommendations pinned to pack |\n| **Retrieval-as-a-service** | §4, §5 | Vendored pack trees → query a retrieval service |\n| **Tighten Intelligence Platform** | §3 | FIP + Lab bundled → FIP = intelligence; Lab = evaluation *service* |\n| **Automate the portal** | R8 | Hand-maintained digests/diagrams → orchestrator-generated |\n| **Close the loops** | R7, R3 | FIP 1–5, lab core, Hermes unbuilt → built; measured, self-improving |\n\n**Target dependency direction:** consumers depend only on **platform-service contracts** and **pinned packs** —\nnever on a venture repo. Feedback (Hermes) flows one-way as **new immutable pack versions**.\n\n---\n\n## C · Long-term vision (24 months +)\n\nA **self-improving, measured, and partly commercialised** AI platform.\n\n```mermaid\ngraph LR\n subgraph Platform[\"Reusable AI Platform\"]\n SK[Shared Skills] --> KI[Knowledge Intelligence]\n KI --> PK[Versioned Packs]\n PK --> SVC[Platform Services
assessment · opportunity · retrieval · evaluation]\n SVC --> AG[Governed agents
OpenClaw as service consumer]\n end\n SVC --> INT[Internal ventures
Inexis Digital · Consulting · Inbound Lanka · City Retreats]\n SVC --> EXT[External customers
Assessment SaaS · licensable packs]\n OUT[Measured outcomes] -->|Hermes closed loop| PK\n ORCH[[Self-documenting portal]] -.-> Platform\n```\n\n**Vision characteristics:**\n- **Closed measurement loop** — every recommendation is outcome-weighted (Hermes), so quality compounds.\n- **Thin ventures** — launching a venture is composing platform services + a domain pack, not building a stack.\n- **Governed AI orchestration** — agents (incl. OpenClaw) are consumers of well-defined services, under one\n claims/tone guardrail.\n- **Self-documenting** — the orchestrator keeps the portal true automatically.\n- **Commercialised surfaces** — the Assessment Service, intelligence packs, and skills library become external\n products (see [Strategic Opportunities](/architecture/strategic-opportunities)).\n\n---\n\n## Horizon summary\n\n| Dimension | Current | Recommended (12–24 mo) | Long-term vision |\n|-----------|---------|------------------------|------------------|\n| Reusable services | Trapped in venture/app repos | Extracted into a Platform Services layer | Multi-tenant, some external |\n| Scoring / recommendations | Duplicated across 2–3 places | Single source of truth (pack) | Outcome-weighted (Hermes) |\n| Foundational loops | Unbuilt (FIP/lab/Hermes) | Built (capture→retrieve, runs→eval) | Closed, self-improving |\n| Portal upkeep | Manual | Orchestrator-generated | Self-documenting |\n| Ventures | Bespoke apps | Thin service compositions | Compose-to-launch |\n| Commercial surface | Internal only | Extraction enables options | Assessment SaaS + data/skills products |\n\n> **Boundaries of this recommendation:** it changes *placement, ownership, and automation* — not the proven\n> domain logic. It does not assume any unbuilt loop is built; it recommends the sequence to build them. Adoption\n> is via ADRs, one accepted decision at a time, preserving the evidence-first philosophy.\n\n## Related\n- [Architecture Review](/architecture/architecture-review) · [Architecture Risks](/architecture/architecture-risks) · [Strategic Opportunities](/architecture/strategic-opportunities)\n- Proposed [ADR 0005](/decisions/0005-platform-services-and-consolidation) · [Portfolio Overview](/overview) · [Principles](/architecture/principles)\n"},{"id":"/architecture/architecture-review","kind":"page","entityType":"architecture","title":"Ecosystem Architecture Review (Phase D)","route":"/architecture/architecture-review","sourcePath":"portal/architecture/architecture-review.md","slug":null,"frontmatter":{"title":"Ecosystem Architecture Review (Phase D)","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"A holistic, Enterprise-Architecture-style review of the ecosystem, based only on the portal's own","headings":[{"depth":2,"text":"Executive summary","id":"executive-summary"},{"depth":2,"text":"Findings at a glance","id":"findings-at-a-glance"},{"depth":2,"text":"1 · Capability Ownership","id":"1-capability-ownership"},{"depth":2,"text":"2 · Duplication (classified)","id":"2-duplication-classified"},{"depth":2,"text":"3 · Layer Boundaries","id":"3-layer-boundaries"},{"depth":2,"text":"4 · Dependency Health","id":"4-dependency-health"},{"depth":2,"text":"5 · Capability Reuse","id":"5-capability-reuse"},{"depth":2,"text":"6 · Information Flow","id":"6-information-flow"},{"depth":2,"text":"What this review deliberately does not claim","id":"what-this-review-deliberately-does-not-claim"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["architecture-risks.md","strategic-opportunities.md","architecture-evolution.md","capability-reuse-map.md","../decisions/0005-platform-services-and-consolidation.md","../capabilities/cap-website-assessment.md","../decisions/0005-platform-services-and-consolidation.md","../capabilities/cap-reusable-ai-skills.md","../capabilities/cap-knowledge-intelligence.md","../capabilities/cap-intelligence-productization.md","../capabilities/cap-reproducible-evaluation.md","../capabilities/cap-website-assessment.md","../capabilities/cap-commercial-opportunity.md","../capabilities/cap-architecture-governance.md","capability-reuse-map.md","../capabilities/cap-website-assessment.md","../repos/intelproducts.md","../repos/shared-skills.md","recommendations.md","../repos/personalops.md","../capabilities/cap-website-assessment.md","../decisions/0005-platform-services-and-consolidation.md","architecture-evolution.md","intelligence-platform.md#4--runtime-information-flow","../capabilities/cap-website-assessment.md#4--runtime-information-flow","../decisions/0005-platform-services-and-consolidation.md","architecture-risks.md","strategic-opportunities.md","architecture-evolution.md","capability-reuse-map.md","principles.md","system-of-systems.md"],"body":"\n# Ecosystem Architecture Review — Phase D\n\nA holistic, Enterprise-Architecture-style review of the ecosystem, based **only on the portal's own\ndocumented evidence** (registries, capability pages, digests, dependency maps, ADRs). It produces\n**recommendations only** — no existing architecture is modified. Companion pages:\n[Architecture Risks](/architecture/architecture-risks) · [Strategic Opportunities](/architecture/strategic-opportunities) ·\n[Recommended Architecture Evolution](/architecture/architecture-evolution) · updated [Capability Reuse Map](/architecture/capability-reuse-map) ·\nproposed [ADR 0005](/decisions/0005-platform-services-and-consolidation).\n\n> **Evidence discipline.** Every finding cites a portal page. Nothing new was inferred about\n> implementations; where the portal already records uncertainty (mock-mode, unbuilt loops, declared-not-wired),\n> this review carries that uncertainty forward rather than resolving it.\n\n## Executive summary\n\nThe ecosystem has a **sound layered thesis and strong reuse instincts** — most visibly the\ndomain-agnostic, pack-driven [Website Assessment](/capabilities/cap-website-assessment) engine, where a\nnew vertical is a new *pack*, not new code. The main architectural weaknesses are **not implementation bugs**;\nthey are **placement and consolidation** issues that will compound as the ecosystem grows:\n\n1. **Reusable capabilities are trapped inside venture/app repositories** — most importantly the assessment\n engine lives inside `inexisstudios` (a venture marketing site), so consumers depend on a venture repo for a\n platform capability.\n2. **Two parallel \"opportunity\" scoring models** and **recommendation logic split across three layers** create\n consolidation debt and a risk of prospect-facing inconsistency.\n3. **Foundational loops are unbuilt** (FIP Phases 1–5, the lab's core run/eval loop, the Hermes learning loop)\n and **cross-repo consumption is mostly mock**, so the end-to-end capability is proven in spec more than in\n production.\n\nThe headline recommendation is to introduce a **Platform Services layer** and extract reusable services\n(assessment, opportunity/COP, retrieval, evaluation) out of venture repos, with the intelligence **pack as the\nsingle source of truth** for rules and scoring. See [ADR 0005 (proposed)](/decisions/0005-platform-services-and-consolidation).\n\n## Findings at a glance\n\n| # | Area | Key finding | Severity |\n|---|------|-------------|----------|\n| 1 | Capability ownership | Website Assessment has 4 co-owners and no single accountable owner | High |\n| 2 | Duplication | Two opportunity scores; recommendation logic in 3 layers | High |\n| 3 | Layer boundaries | Reusable engine sits in a venture repo; \"Applications & Agents\" conflates services and apps | High |\n| 4 | Dependency health | `outreachagent` → `inexisstudios` API is a hidden venture-coupling; unused pack dependency in `leadplatform` | Medium-High |\n| 5 | Capability reuse | Assessment & COP capabilities trapped in apps; lab under-utilised | Medium-High |\n| 6 | Information flow | Long intelligence transformation chain; repeated scoring; multiple approval gates | Medium |\n\n---\n\n## 1 · Capability Ownership\n\n| Capability | Owner (documented) | Ownership clear? | Appropriate? | Note |\n|-----------|--------------------|------------------|--------------|------|\n| [Reusable AI Skills](/capabilities/cap-reusable-ai-skills) | `shared-skills` | ✅ Yes | ✅ Yes | Clean single owner |\n| [Knowledge Intelligence](/capabilities/cap-knowledge-intelligence) | `personalops`/FIP | ✅ Yes | ✅ Yes | Clean |\n| [Intelligence Productization](/capabilities/cap-intelligence-productization) | `intelproducts` (+ FIP builders) | 🔶 Mostly | ✅ Yes | Producer (FIP) / contract (intelproducts) split is intentional and documented |\n| [Reproducible Evaluation](/capabilities/cap-reproducible-evaluation) | `website-intelligence-lab` | ✅ Yes | 🔶 See §3 | Owner clear; layer placement questionable |\n| [Website Assessment](/capabilities/cap-website-assessment) | **4 repos** (engine/pack/authoring/harness) | ❌ **Diffuse** | 🔶 Partly | **No single accountable owner** for the end-to-end capability |\n| [Commercial Opportunity & Outreach](/capabilities/cap-commercial-opportunity) | `outreachagent` (+ pack skills) | 🔶 Mostly | 🔶 See §5 | Owner is an app; reusable pattern trapped there |\n| [Architecture & Docs Governance](/capabilities/cap-architecture-governance) | `portfolio-portal` | ✅ Yes | ✅ Yes | Clean |\n\n**Overlapping responsibilities:** scoring and recommendation responsibilities are shared across the engine\n(`inexisstudios`), the pack (`intelproducts`), and the COP (`outreachagent`) — see §2.\n\n**Recommendations (ownership):**\n- Designate an explicit **capability owner** for Website Assessment: the **pack (`intelproducts`) owns rules &\n scoring truth**; the **engine owns execution**; the COP owns commercial framing. Document the seam.\n- Should ownership move? The **assessment engine should move out of `inexisstudios`** (a venture repo) into a\n platform service (§3). Ownership of the *capability* then sits with the platform, not a venture.\n\n---\n\n## 2 · Duplication (classified)\n\n| Duplication | Evidence | Classification |\n|-------------|----------|----------------|\n| **Opportunity scoring in two places** — pack's 0–100 domain-weighted score vs `leadplatform`'s own \"Opportunity Intelligence\" scoring (distinct dimensions) | [Reuse Map](/architecture/capability-reuse-map); leadplatform `opportunity-scoring-spec` | **Architectural debt → should be consolidated** |\n| **Recommendation logic in three layers** — engine rule-based recs → pack `recommendation-library` (REC-001…015) → COP `recommendation.action` enum | [cap-website-assessment](/capabilities/cap-website-assessment) | **Intentional pipeline, but must stay aligned → consolidate source (pack)** |\n| **Duplicated intelligence via vendoring** — full `intelproducts` pack tree copied into `leadplatform/vendor/` | [intelproducts digest](/repos/intelproducts) | **Intentional** (pinned contract) — but drift risk (§4) |\n| **Duplicated / near-duplicate skills** — `revops`⟷`revenue-operations`, `database-designer`⟷`database-schema-designer`, 4 competitor skills, `create-llms`⟷`update-llms` | [shared-skills digest](/repos/shared-skills), [recommendations](/architecture/recommendations) | **Architectural debt → should be consolidated** (within the library) |\n| **Duplicated approval workflows** — human-approval gate in FIP (asset promotion), in the engine (report approve), in outreach (\"nothing auto-sent\") | [personalops](/repos/personalops), [cap-website-assessment](/capabilities/cap-website-assessment) | **Intentional** per domain — candidate for a shared \"approval-gate\" pattern |\n| **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) |\n\n**Recommendations (duplication):** make the **pack the single source of truth** for rules, scoring, and\nrecommendations; have `leadplatform` consume the assessment/COP rather than maintain a second score; converge\nAI prompt surfaces onto a shared, fact-grounded guardrail; consolidate near-duplicate skills.\n\n---\n\n## 3 · Layer Boundaries\n\nCurrent model (6 layers): Shared Skills → Intelligence Platform → Intelligence Products → **Applications &\nAgents** → Ventures → Customer-facing. Evaluating each:\n\n| Layer | Boundary assessment |\n|-------|--------------------|\n| **Shared Skills** | Clear. Minor internal duplication (§2). |\n| **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. |\n| **Intelligence Products** | Clear (packs). Minor: consumer *skills* co-located with product data — acceptable. |\n| **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. |\n| **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. |\n| **Ventures / Customer-facing** | Under-populated (vision); fine for now. |\n\n**Recommendation:** introduce an explicit **Platform Services** layer between Intelligence Products and the\nApplications/Ventures. Reclassify the **evaluation harness (lab)** and the **assessment engine** (extracted\nfrom `inexisstudios`) and the **opportunity/COP evaluation** as platform services. This tightens the\nIntelligence Platform to mean *knowledge intelligence (FIP)* and gives reusable services a proper home. See\n[ADR 0005 (proposed)](/decisions/0005-platform-services-and-consolidation) and the target model in\n[Architecture Evolution](/architecture/architecture-evolution).\n\n---\n\n## 4 · Dependency Health\n\n| Concern | Evidence | Assessment |\n|---------|----------|------------|\n| **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.** |\n| **Unused / unnecessary dependency** | `leadplatform` vendors the full website-assessment pack but wires only the proposal pack | Carries an **unused dependency**; declared-not-wired. |\n| **Pack drift (hidden dependency)** | Consumers pin `intelproducts` as submodules | Stale pins = scoring against outdated intelligence — a **hidden version dependency**. |\n| **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. |\n| **Two data platforms** | Supabase (FIP) + Cloudflare D1/R2 (engine) | Mild fragmentation; a **hidden operational dependency** on two stores. Not urgent. |\n| **Missing abstractions** | Across capabilities | (a) Assessment Service; (b) one Opportunity-score abstraction; (c) shared approval-gate; (d) retrieval-as-a-service to reduce vendoring. |\n\n**Recommended dependency directions:** consumers should depend on **platform-service contracts**, never on a\nventure repo. Extract the Assessment Service so the direction becomes `outreachagent → Assessment Service`\n(platform), not `outreachagent → inexisstudios` (venture). Keep the FIP→pack→consumer flow one-way; feed\noutcomes back only as *new pack versions*.\n\n---\n\n## 5 · Capability Reuse\n\n| Question | Finding |\n|----------|---------|\n| 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. |\n| Capabilities **trapped inside a venture/app** | Assessment engine (in a venture site); COP evaluation (in an outreach agent). |\n| **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). |\n| 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. |\n\n**Recommendation:** treat \"trapped\" capabilities as extraction candidates; make the platform-service +\npack composition the default way to launch a venture.\n\n---\n\n## 6 · Information Flow\n\nDocumented end-to-end lifecycle (see [Intelligence Platform runtime flow](/architecture/intelligence-platform#4--runtime-information-flow)\nand [Website Assessment runtime](/capabilities/cap-website-assessment#4--runtime-information-flow)):\n\n```mermaid\ngraph LR\n KE[Knowledge estate] --> FIP[FIP capture→approve→structure]\n FIP --> KA[(knowledge_assets)]\n KA --> SYN[synthesis / builder skills]\n SYN --> PACK[(intelligence pack)]\n PACK -->|vendored/pinned| ENG[Assessment engine]\n URL[Website URL] --> ENG\n ENG --> RPT[Report/score]\n RPT --> COP[COP]\n COP --> OUT[Outreach / CRM]\n OUT --> VEN[Venture outcome]\n VEN -. future Hermes .-> PACK\n```\n\n**Unnecessary transformations / repeated processing (evidence-based):**\n- **Long representation chain for the same intelligence:** markdown (estate) → `knowledge_assets` → pack\n markdown/JSON → engine `pack.generated.json` → applied. Each hop is a drift point. Some hops are necessary\n (contract stability) but the chain is **hand-maintained** today.\n- **Repeated \"opportunity\" processing:** the pack produces a score *and* `leadplatform` computes its own — the\n same conceptual output twice (§2).\n- **Multiple human-approval gates** on one prospect's journey (asset promotion in FIP upstream; report approval\n in the engine; send approval in outreach) — governance is correct, but the **assessment→outreach path carries\n two or three gates**.\n\n**Simplification opportunities:** one scoring source; **automate the intelligence chain** (the\n`portfolio-portal-orchestrator` and pack-publication automation); a **retrieval/assessment service** to remove\npack vendoring; a **single, well-placed approval gate** for the assessment→outreach path (keep FIP's upstream\ngate for canonical intelligence).\n\n---\n\n## What this review deliberately does **not** claim\n- It does not assert any capability is more built than the portal already documents (mock-mode, unbuilt FIP\n phases, Phase-1 lab, declared-not-wired leadplatform all stand).\n- It does not redesign implementations — only **placement, ownership, and consolidation**.\n- All structural changes are **proposals** (see [ADR 0005](/decisions/0005-platform-services-and-consolidation),\n status *proposed*); existing architecture is unchanged.\n\n## Related\n- [Architecture Risks](/architecture/architecture-risks) · [Strategic Opportunities](/architecture/strategic-opportunities) · [Architecture Evolution](/architecture/architecture-evolution)\n- [Capability Reuse Map](/architecture/capability-reuse-map) · [Architecture Principles](/architecture/principles) · [System dependency map](/architecture/system-of-systems)\n"},{"id":"/architecture/architecture-risks","kind":"page","entityType":"architecture","title":"Architecture Risks","route":"/architecture/architecture-risks","sourcePath":"portal/architecture/architecture-risks.md","slug":null,"frontmatter":{"title":"Architecture Risks","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The ecosystem's architectural risk register, produced by the Phase-D Architecture Review.","headings":[{"depth":2,"text":"Risk register","id":"risk-register"},{"depth":2,"text":"Risk map (impact × likelihood)","id":"risk-map-impact-likelihood"},{"depth":2,"text":"Priority summary","id":"priority-summary"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["architecture-review.md","../decisions/0005-platform-services-and-consolidation.md","../decisions/0005-platform-services-and-consolidation.md","architecture-review.md","strategic-opportunities.md","architecture-evolution.md","capability-reuse-map.md"],"body":"\n# Architecture Risks\n\nThe ecosystem's architectural risk register, produced by the [Phase-D Architecture Review](/architecture/architecture-review).\nEvery risk is grounded in documented portal evidence; none asserts un-evidenced implementation detail. Priority\nis a function of impact × likelihood × strategic leverage.\n\n**Likelihood/impact scale:** Low · Medium · High. **Priority:** P1 (address next) · P2 (plan) · P3 (watch).\n\n## Risk register\n\n| ID | Risk | Impact | Likelihood | Affected repos | Recommended mitigation | Priority |\n|----|------|--------|-----------|----------------|------------------------|----------|\n| **R1** | **Reusable assessment engine trapped in a venture repo** — the domain-agnostic assessment API lives inside `inexisstudios` (a venture marketing site), so consumers couple to a venture. | High | Present (certain) | `inexisstudios`, `outreachagent`, `leadplatform` | Extract to a standalone **Assessment Service** in a new Platform Services layer ([ADR 0005](/decisions/0005-platform-services-and-consolidation)). | **P1** |\n| **R2** | **Two divergent opportunity-scoring models** — pack 0–100 domain score vs `leadplatform`'s own scoring; can disagree in front of a prospect. | Medium-High | Medium | `intelproducts`, `leadplatform`, `outreachagent` | Single source of truth (pack); have `leadplatform` consume the assessment/COP. | **P1** |\n| **R3** | **Inference-derived scoring weights, no learning loop** — weights are \"review-gated defaults, not empirical\"; **Hermes** feedback loop unbuilt. | Medium | High (documented) | `intelproducts`, `inexisstudios` | Instrument outcomes; build Hermes to replace defaults with outcome-derived weights. | P2 |\n| **R4** | **End-to-end flow mostly mock** — assessment runs `ASSESSMENT_MODE=mock` by default in `outreachagent`; live run not operationally validated. | Medium | Present | `outreachagent`, `inexisstudios` | Operational live-run validation; track live-vs-mock in current-state. | P2 |\n| **R5** | **Pack drift via stale submodule pins** — consumers vendor `intelproducts`; stale pins score against outdated intelligence. | Medium | Medium | `leadplatform` (+ future consumers) | Track pinned pack versions in the registry; CI pin-freshness check. | P2 |\n| **R6** | **Non-durable crawler** — engine crawler jobs are in-memory / not durable across restarts (Phase 3d planned). | Medium | Medium | `inexisstudios` | Durable queue (Cloudflare Queues/Durable Objects); complete Phase 3d. | P2 |\n| **R7** | **Foundational loops unbuilt** — FIP Phases 1–5 not started; lab core run/eval loop pending. Higher capabilities depend on these. | High (strategic) | High | `personalops`, `website-intelligence-lab` | Prioritise FIP capture→retrieve loop and the lab adapter→runs→eval loop. | **P1** |\n| **R8** | **Documentation & knowledge duplication as the ecosystem grows** — manual portal upkeep, near-duplicate skills, long hand-maintained intelligence chain. | Medium | High | `portfolio-portal`, `shared-skills`, `intelproducts` | Build the `portfolio-portal-orchestrator`; automate pack publication; consolidate skills. | P2 |\n| **R9** | **AI prompt surfaces spread across repos** — engine narrative, pack report guidance, outreach skills → risk of divergent claims/tone, especially regulated verticals. | Medium | Medium | `inexisstudios`, `intelproducts`, `outreachagent` | Shared, fact-grounded claims/tone guardrail; health verticals already route to human review — extend that discipline. | P2 |\n| **R10** | **Two data platforms** — Supabase (FIP) + Cloudflare D1/R2 (engine) fragment operations & backup/governance. | Low-Medium | Present | `personalops`, `inexisstudios` | A deliberate data-platform strategy (not necessarily consolidation); document the boundary. | P3 |\n| **R11** | **Key-person concentration** — single founder owns all systems; private tools, no team. | High | Structural | all | The portal itself mitigates (captured knowledge, onboarding, AI-context). Continue capability documentation; keep digests current. | P2 |\n| **R12** | **Circular feedback risk (future)** — the planned Hermes loop (outcomes → re-weight pack) could couple consumers back into the producer if designed as mutation rather than a new pack version. | Medium | Low (future) | `intelproducts`, `personalops`, `inexisstudios` | Design Hermes as a **one-way feedback** that publishes a *new* immutable pack version; never mutate a consumed pack. | P3 |\n\n## Risk map (impact × likelihood)\n\n```mermaid\nquadrantChart\n title Architecture risk map\n x-axis Low Likelihood --> High Likelihood\n y-axis Low Impact --> High Impact\n quadrant-1 Address next (P1)\n quadrant-2 Plan mitigation\n quadrant-3 Watch\n quadrant-4 Monitor\n R1 engine trapped: [0.9, 0.85]\n R2 dual scoring: [0.55, 0.7]\n R3 no learning loop: [0.8, 0.55]\n R7 unbuilt loops: [0.8, 0.9]\n R8 doc duplication: [0.8, 0.5]\n R11 key person: [0.9, 0.8]\n R6 crawler durability: [0.5, 0.5]\n R10 two data stores: [0.6, 0.35]\n```\n\n## Priority summary\n- **P1 (address next):** R1 (extract Assessment Service), R2 (single scoring source), R7 (build foundational loops).\n- **P2 (plan):** R3, R4, R5, R6, R8, R9, R11.\n- **P3 (watch):** R10, R12.\n\n> Risks are recommendations, not changes. Promote accepted mitigations to ADRs; the direction change for R1–R2\n> is captured in proposed [ADR 0005](/decisions/0005-platform-services-and-consolidation).\n\n## Related\n- [Architecture Review](/architecture/architecture-review) · [Strategic Opportunities](/architecture/strategic-opportunities) · [Architecture Evolution](/architecture/architecture-evolution) · [Capability Reuse Map](/architecture/capability-reuse-map)\n"},{"id":"/architecture/capability-reuse-map","kind":"page","entityType":"architecture","title":"Capability Reuse Map","route":"/architecture/capability-reuse-map","sourcePath":"portal/architecture/capability-reuse-map.md","slug":null,"frontmatter":{"title":"Capability Reuse Map","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"For every major capability: who provides it, who consumes it, what assets are shared, what","headings":[{"depth":2,"text":"Reuse table","id":"reuse-table"},{"depth":2,"text":"Provider → consumer graph","id":"provider-consumer-graph"},{"depth":2,"text":"Duplication-risk hotspots","id":"duplication-risk-hotspots"},{"depth":2,"text":"Findings & recommendations (recorded, not actioned)","id":"findings-recommendations-recorded-not-actioned"},{"depth":2,"text":"Phase-D ecosystem-review update (2026-07-05)","id":"phase-d-ecosystem-review-update-2026-07-05"},{"depth":3,"text":"Reusability verdict per capability","id":"reusability-verdict-per-capability"},{"depth":3,"text":"Capabilities that should move into the platform","id":"capabilities-that-should-move-into-the-platform"},{"depth":3,"text":"Capabilities trapped inside a venture / app","id":"capabilities-trapped-inside-a-venture-app"},{"depth":3,"text":"Under-utilised platform capabilities","id":"under-utilised-platform-capabilities"},{"depth":3,"text":"Opportunities to reduce future repositories","id":"opportunities-to-reduce-future-repositories"},{"depth":2,"text":"Related","id":"related"}],"diagrams":2,"links":["../capabilities/README.md","../capabilities/cap-reusable-ai-skills.md","../capabilities/cap-knowledge-intelligence.md","../capabilities/cap-intelligence-productization.md","../capabilities/cap-reproducible-evaluation.md","../capabilities/cap-website-assessment.md","../capabilities/cap-commercial-opportunity.md","../capabilities/cap-architecture-governance.md","recommendations.md","../decisions/0004-capability-architecture.md","architecture-review.md","../decisions/0005-platform-services-and-consolidation.md","architecture-review.md","architecture-risks.md","strategic-opportunities.md","architecture-evolution.md","../capabilities/README.md","system-of-systems.md","principles.md","architecture-review.md","architecture-risks.md","strategic-opportunities.md","architecture-evolution.md"],"body":"\n# Capability Reuse Map\n\nFor every major capability: who **provides** it, who **consumes** it, what **assets** are shared, what\n**intelligence** it depends on, where there are **reuse opportunities**, and where there are **duplication\nrisks**. This is the reuse-and-risk companion to the [Capability Registry](/capabilities).\nEvidence-based; honesty markers ✅ / 🔶 / ⏳ / 🧭.\n\n## Reuse table\n\n| Capability | Provider | Consumers | Shared assets | Intelligence dependencies | Reuse opportunities | Duplication risks |\n|-----------|----------|-----------|---------------|---------------------------|---------------------|-------------------|\n| [Reusable AI Skills](/capabilities/cap-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.) |\n| [Knowledge Intelligence](/capabilities/cap-knowledge-intelligence) | `personalops`/FIP | FIP, packs, agents | `knowledge_assets`, `search_assets()` | knowledge estate | One retrieval layer for proposal/outreach/assessment | — |\n| [Intelligence Productization](/capabilities/cap-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 |\n| [Reproducible Evaluation](/capabilities/cap-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 |\n| [Website Assessment](/capabilities/cap-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 |\n| [Commercial Opportunity & Outreach](/capabilities/cap-commercial-opportunity) | `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) |\n| [Architecture & Docs Governance](/capabilities/cap-architecture-governance) | `portfolio-portal` (+skills) | whole ecosystem | digests, diagrams, ADRs, `llms.txt` | Reusable AI Skills | Automate via orchestrator | — |\n\n## Provider → consumer graph\n\n```mermaid\ngraph TD\n SKILLS[[Reusable AI Skills]]:::prov\n KI[[Knowledge Intelligence]]:::prov\n IPZ[[Intelligence Productization]]:::prov\n EVAL[[Reproducible Evaluation]]:::prov\n WA[[Website Assessment]]:::prov\n CO[[Commercial Opportunity & Outreach]]:::prov\n GOV[[Architecture & Docs Governance]]:::prov\n\n SKILLS -.underpins.-> KI & IPZ & EVAL & WA & CO & GOV\n KI --> IPZ --> WA\n EVAL -.evaluates.-> WA\n WA --> CO\n CO --> INEXIS[Inexis Digital venture]\n IPZ -->|proposal pack| LEAD[leadplatform]\n WA -.declared.-> LEAD\n classDef prov fill:#e6f0ff,stroke:#356;\n```\n\n## Duplication-risk hotspots\n\n```mermaid\ngraph LR\n subgraph Risk1[\"⚠ Opportunity scoring in two places\"]\n PACKSCORE[\"intelproducts pack
domain-weighted 0–100 score\"]\n LEADSCORE[\"leadplatform
own 'Opportunity Intelligence' scoring
(distinct dimensions)\"]\n end\n subgraph Risk2[\"⚠ Recommendation logic layered in three places\"]\n ENGREC[\"inexisstudios engine
rule-based recommendations\"]\n PACKREC[\"intelproducts
recommendation-library REC-001…015\"]\n COPREC[\"outreachagent COP
recommendation.action enum\"]\n end\n PACKSCORE -.risk of divergence.- LEADSCORE\n ENGREC -.must stay aligned.- PACKREC -.must stay aligned.- COPREC\n```\n\n## Findings & recommendations (recorded, not actioned)\n1. **Two opportunity scores.** `intelproducts` pack scoring (website quality, 0–100) and `leadplatform`'s\n own \"Opportunity Intelligence\" scoring use *different dimensions* (`leadplatform/docs/specs/opportunity-scoring-spec.md`).\n Reuse opportunity: have leadplatform consume the assessment/COP rather than maintain a parallel score.\n **Risk:** two \"opportunity\" numbers that can disagree in front of a prospect.\n2. **Recommendation logic in three layers** (engine rules → pack library → COP action). This is a\n deliberate pipeline, but the three must stay aligned; a change to pack REC-* should be reflected in the\n engine and COP mapping. **Recommend:** treat the pack as the single source and pin versions everywhere.\n3. **Pack drift via vendoring.** Consumers vendor `intelproducts` as pinned submodules — good for stability,\n but stale pins mean consumers score against old intelligence. **Recommend:** track pinned pack versions in\n the registry.\n4. **Strong reuse win:** the engine is **domain-agnostic + pack-driven** — new verticals/ventures (cleaning,\n travel→Inbound Lanka) are new *packs*, not new code. This is the ecosystem's best demonstrated reuse and\n should be the template for future capabilities.\n\n> Promote any accepted item to an ADR; see [architecture recommendations](/architecture/recommendations) for the\n> running log and [ADR 0004](/decisions/0004-capability-architecture).\n\n---\n\n## Phase-D ecosystem-review update (2026-07-05)\n\nThe [Phase-D Architecture Review](/architecture/architecture-review) re-examined reuse across the whole ecosystem. Updated\nconclusions:\n\n### Reusability verdict per capability\n| Capability | Genuinely reusable? | Blocker to reuse | Action |\n|-----------|--------------------|------------------|--------|\n| Reusable AI Skills | ✅ Yes | Internal duplication only | Consolidate near-duplicates |\n| Knowledge Intelligence | 🔶 Partly | Retrieval API unbuilt (FIP Phases 1–5) | Build capture→retrieve; expose retrieval-as-a-service |\n| Intelligence Productization | ✅ Yes | Vendoring drift | Track pins in registry |\n| Reproducible Evaluation | 🔶 Under-utilised | Phase-1 seed; engine not yet run against it | Wire the engine's runs through the lab |\n| **Website Assessment** | ✅ Reusable *engine*, ❌ **trapped in a venture repo** | Lives inside `inexisstudios` | **Extract to a Platform Service** (R1) |\n| Commercial Opportunity | 🔶 Reusable *pattern*, trapped in `outreachagent` | COP logic in an app | Extract COP/opportunity evaluation to a service |\n| Architecture & Docs Governance | ✅ Yes | Manual upkeep | Build the orchestrator |\n\n### Capabilities that should move into the platform\n- **Assessment engine** (`inexisstudios` → Platform Services).\n- **Opportunity/COP evaluation** (`outreachagent` → Platform Services).\n- **Retrieval** (expose FIP `search_assets` as a service to replace pack vendoring).\n\n### Capabilities trapped inside a venture / app\n- Website Assessment (venture marketing site); Commercial Opportunity (outreach agent).\n\n### Under-utilised platform capabilities\n- Reproducible Evaluation (lab, Phase-1 seed); FIP retrieval; packs without consumer skills (cinnamon-stories, some domains).\n\n### Opportunities to reduce future repositories\n- Make **service + pack composition** the default launch pattern → *new venture = compose, not build* → fewer repos.\n\n> Direction change proposed in [ADR 0005](/decisions/0005-platform-services-and-consolidation) (status:\n> proposed). Full analysis: [Architecture Review](/architecture/architecture-review), [Risks](/architecture/architecture-risks),\n> [Opportunities](/architecture/strategic-opportunities), [Evolution](/architecture/architecture-evolution).\n\n## Related\n- [Capability Registry](/capabilities) · [System dependency map](/architecture/system-of-systems) · [Architecture Principles](/architecture/principles)\n- [Architecture Review](/architecture/architecture-review) · [Architecture Risks](/architecture/architecture-risks) · [Strategic Opportunities](/architecture/strategic-opportunities) · [Architecture Evolution](/architecture/architecture-evolution)\n"},{"id":"/architecture/intelligence-platform","kind":"page","entityType":"architecture","title":"Intelligence Platform — Architecture","route":"/architecture/intelligence-platform","sourcePath":"portal/architecture/intelligence-platform.md","slug":null,"frontmatter":{"title":"Intelligence Platform — Architecture","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The platform-level architectural description of layer 2 of the ecosystem: the systems that turn raw","headings":[{"depth":2,"text":"The systems that make up the layer","id":"the-systems-that-make-up-the-layer"},{"depth":2,"text":"Why the Intelligence Platform exists","id":"why-the-intelligence-platform-exists"},{"depth":2,"text":"Problems it solves","id":"problems-it-solves"},{"depth":2,"text":"Guiding architectural principles (as documented in source)","id":"guiding-architectural-principles-as-documented-in-source"},{"depth":2,"text":"1 · Executive overview (single-box capability)","id":"1-executive-overview-single-box-capability"},{"depth":2,"text":"2 · Container view","id":"2-container-view"},{"depth":2,"text":"3 · Component view (FIP internals + how the named subsystems relate)","id":"3-component-view-fip-internals-how-the-named-subsystems-relate"},{"depth":2,"text":"4 · Runtime information flow","id":"4-runtime-information-flow"},{"depth":2,"text":"Upstream inputs & downstream consumers","id":"upstream-inputs-downstream-consumers"},{"depth":2,"text":"Current maturity, roadmap, assumptions & known gaps","id":"current-maturity-roadmap-assumptions-known-gaps"},{"depth":2,"text":"Related","id":"related"}],"diagrams":5,"links":["../portfolio-overview.md","principles.md","principles.md","../repos/shared-skills.md","../repos/personalops.md","../repos/intelproducts.md","../repos/website-intelligence-lab.md","../ventures/intelligence-platform.md","../portfolio-overview.md","system-of-systems.md","principles.md","../decisions/0003-intelligence-platform-layer-model.md"],"body":"\n# Intelligence Platform — Architecture\n\nThe platform-level architectural description of **layer 2** of the ecosystem: the systems that turn raw\nknowledge and signals into structured, reusable intelligence. This page reads top-down — executive\noverview → container → component → runtime — and is designed to be understandable from executive level\ndown to implementation level. It governs how the [Portfolio Overview](/overview) presents\nlayer 2. See also the [Architecture Principles](/architecture/principles) it embodies.\n\n> **Scope & honesty (read first).** The \"Intelligence Platform\" is **not a single repository** — it is a\n> layer composed of sibling systems. Evidence was gathered directly from source repos. Throughout, this\n> page distinguishes **✅ implemented**, **🔶 planned/partial**, and **🧭 vision**, and marks anything\n> unverified as such. One term supplied in the request — **\"estate generation\"** — was **not found** as a\n> subsystem in any repository and is flagged accordingly below.\n\n---\n\n## The systems that make up the layer\n\n| System | Repo | Role | Maturity (evidence) |\n|--------|------|------|---------------------|\n| **Founder Intelligence Platform (FIP)** | `PersonalOps` | The knowledge intelligence platform + **Intelligence Dashboard**: extracts, stores, retrieves scoped intelligence from the founder's *knowledge estate*. **The producer.** | 🔶 Design v1.0 approved; Phase 0 foundation built (Supabase schema, seed, TS types, harvest scripts, dashboard rendering); Phases 1–5 not started |\n| **Intelligence Products** | `intelproducts` | Published, versioned, immutable **intelligence packs** — the machine-consumable output contract. | ✅ Operational as a data contract (packs published + consumed) — *belongs to layer 3, produced by this layer* |\n| **Website Intelligence Lab** | `website-intelligence-lab` | A distinct **experimentation & evaluation platform** for website engines (assessment/migration/…). | 🔶 Early-development; infra VPS-validated; core loop pending |\n\n> FIP and the Website Intelligence Lab are **sibling, non-dependent** platforms (no direct code\n> references between them). Their relationship is mediated conceptually: the lab treats external\n> knowledge (like the packs) as *referenced, never owned* (Principle 3).\n\n---\n\n## Why the Intelligence Platform exists\n\nA multi-venture founder accumulates intelligence continuously — client projects, market research,\noperational experiments, external research — but *\"without structure, that intelligence is locked inside\ndocuments that are hard to query, easy to forget, and inaccessible to AI assistants.\"* (`PersonalOps …/01-architecture.md`).\nThe platform exists to make that intelligence **queryable, structured, and AI-accessible** — *\"the layer\nbetween raw knowledge documents and the AI agents and workflows that use that knowledge to produce\noutput.\"*\n\n## Problems it solves\n- **Capture loss** — *\"most founder intelligence is lost… because it is never captured\"* (Principle 9: capture first).\n- **Un-queryable knowledge** — markdown is narrative, not retrievable structured data.\n- **Cross-venture reuse** — intelligence that applies across ventures is siloed by document/venture.\n- **Unmeasured capability** *(lab)* — engines cannot be improved without reproducible evaluation.\n- **Inconsistent outputs** — downstream apps need a stable, versioned intelligence contract, not ad-hoc copies.\n\n## Guiding architectural principles (as documented in source)\nFIP declares **11 principles** (`01-architecture.md`); the most load-bearing:\n1. **Intelligence over documents** — the canonical store is structured assets (Supabase `knowledge_assets`), not files.\n2. **Human approval is mandatory** — no asset becomes canonical without founder review (no auto-approve path).\n3. **Maturity as quality gate** — `working → ready → proven → archived`; only ready/proven go external.\n4. **One canonical intelligence store** — no duplication into secondary tables/caches.\n5. **Markdown as narrative authority** — documents remain authoritative context; assets are extractions, not replacements.\n6. **Scoped by multiple dimensions** — venture, industry, market, capability, use case (independent lookup tables).\n7. **Capture first** — prioritise low-friction capture over structuring complexity.\n\nThe Website Intelligence Lab adds: **reproducibility & complete provenance**, **definition vs derivation**,\n**knowledge referenced never owned** — now generalised in the ecosystem [Architecture Principles](/architecture/principles).\n\n---\n\n## 1 · Executive overview (single-box capability)\n\n```mermaid\ngraph LR\n IN[/\"Founder knowledge & signals
(docs, captures, research, website subjects)\"/] --> IP\n IP[[\"🧠 Intelligence Platform
Turn raw knowledge into structured, reusable, versioned intelligence\"]] --> OUT[/\"Queryable knowledge assets +
published intelligence packs +
evaluated capabilities\"/]\n OUT --> DOWN[\"Applications, Agents & Ventures
(leadplatform, outreachagent, OpenClaw, …)\"]\n```\n\n**In one sentence:** the Intelligence Platform converts a founder's scattered knowledge and market signals\ninto a **queryable asset library** and **versioned intelligence products** that downstream apps and agents\nconsume with confidence.\n\n---\n\n## 2 · Container view\n\nThe deployable/major pieces across the three systems.\n\n```mermaid\ngraph TD\n subgraph FIP[\"PersonalOps — Founder Intelligence Platform 🔶\"]\n UI[\"Presentation: TanStack Router UI
Intelligence Dashboard · /ka, /ka/capture, /ka/review, /ka/harvest, /ka/legacy\"]\n DB[(\"Data: Supabase PostgreSQL
knowledge_assets + 5 lookup + 5 join
+ staging queues + registry + search_assets() RPC\")]\n EST[[\"Knowledge Estate
Git markdown — 46 docs (~4,600 lines)\"]]\n HARV[\"Extraction / Harvest pipeline
scripts: harvest-os · extract-pdf · capability-harvest ✅\"]\n UI --> DB\n DB -->|read-only| EST\n HARV --> DB\n EST --> HARV\n end\n\n subgraph PROD[\"intelproducts — Intelligence Products ✅ (layer 3 output)\"]\n PACKS[(\"intelligence-packs/
proposal · website-assessment · cinnamon-stories · outreach-messaging
versioned · immutable\")]\n CSK[\"consumer skills/
proposal-generator, first-touch-email, …\"]\n end\n\n subgraph LAB[\"website-intelligence-lab — Evaluation Platform 🔶\"]\n INFRA[\"Infrastructure: Docker · Caddy · WP Multisite ✅\"]\n CORPUS[(\"corpus/ businesses + cases + benchmarks\")]\n RUNS[(\"runs/ immutable provenanced experiments\")]\n CORPUS --> RUNS\n INFRA --> RUNS\n end\n\n FIP -->|\"builder skills author packs\"| PROD\n SS[[\"Shared Skills (layer 1)\"]] -.->|builder & consumer skills| PROD\n SS -.->|engineering capability| FIP\n SS -.-> LAB\n```\n\n---\n\n## 3 · Component view (FIP internals + how the named subsystems relate)\n\nThis is where the request's named subsystems are placed **honestly** against evidence.\n\n```mermaid\ngraph TD\n SRC[\"Sources: manual capture · voice · articles · agent research · legacy KB\"] --> ING[/\"ingestion_queue / agent_research_queue / harvest_candidates\"/]\n EXT[\"Extraction pipeline ✅
(harvest scripts → candidates)\"] --> ING\n DOCS[[\"Knowledge Estate (markdown) ✅\"]] --> EXT\n ING --> REV{{\"Human review & approval ✅ (mandatory)\"}}\n REV -->|approved| KA[(\"knowledge_assets ✅
scoped × maturity-gated\")]\n KA --> SEARCH[\"search_assets() RPC ✅\"]\n SEARCH --> CONS[\"Consumers: proposal gen · marketing · agents · lead-qual · website-assessment\"]\n KA --> SYN[\"Synthesis → builder skills\"] --> PACKS[(\"Intelligence Packs ✅\")]\n\n HERMES[\"Hermes 🔶 learning loop
(reserved contract only — NOT built)\"] -. would re-weight .-> SCORE[\"scoring / recommendation weights\"]\n RECS[\"Recommendations: structured output ✅ in outreachagent COP;
rec-library in packs ✅; full Rec-Engine spec 🧭 in out-of-scope inexisstudios\"]\n PACKS --> RECS\n OPENCLAW[\"OpenClaw 🔶 (3rd-party AI assistant;
planned pack consumer — Phase 5, not started)\"]\n PACKS -.future.-> OPENCLAW\n ESTATEGEN[\"'estate generation' ❌ NOT FOUND
(closest: read-only estate-map index + estate publishing)\"]\n\n classDef missing fill:#fdd,stroke:#c00,stroke-dasharray:3 2;\n classDef planned fill:#fff3cd,stroke:#b8860b,stroke-dasharray:4 3;\n class HERMES,OPENCLAW planned;\n class ESTATEGEN missing;\n```\n\n**Named-subsystem reconciliation (evidence-based):**\n\n| Requested subsystem | Reality | Status |\n|---------------------|---------|--------|\n| **Intelligence products** | The `intelproducts` repo — versioned immutable packs (proposal, website-assessment, cinnamon-stories, outreach-messaging). | ✅ Implemented |\n| **Extraction pipelines** | PersonalOps harvest/extract scripts (`harvest-os.js`, `extract-pdf.js`, `capability-harvest/`) → knowledge-asset candidates. | ✅ Implemented |\n| **Knowledge assets** | PersonalOps `knowledge_assets` table + `ka_fragment` type; the corpus is the *\"knowledge estate.\"* | ✅ Implemented |\n| **Recommendations** | Structured `recommendation` field in outreachagent's COP contract ✅; `recommendation-library.md` in packs ✅; a full \"Recommendation Engine\" spec lives in the **out-of-scope** `inexisstudios` repo 🧭. No standalone engine in-layer. | 🔶 Partial |\n| **OpenClaw** | A **third-party** open-source self-hosted AI-assistant framework, documented/adopted; a **planned future** programmatic consumer of packs (FIP Phase 5 — not started). | 🔶 Planned |\n| **Hermes** | **Not a product** — a codename for a **future learning/feedback loop**. Only reserved contract surfaces exist; *\"no logic is implemented.\"* | 🔶 Planned (not built) |\n| **Estate generation** | **NOT FOUND.** The phrase does not exist in any repo. Closest distinct concepts: `estate-map.mjs` (read-only index of the knowledge estate) and estate *publishing/regeneration* — neither \"generates an estate.\" | ❌ Not found |\n\n---\n\n## 4 · Runtime information flow\n\nThe lifecycle of information through the platform (FIP path, with the lab's parallel evaluation path).\n\n```mermaid\ngraph TD\n A[\"① Capture
doc / voice / article / agent research / legacy\"] --> B[\"② Stage
ingestion / harvest_candidates queue\"]\n B --> C{\"③ Founder review & approval
(mandatory — no auto-approve)\"}\n C -->|reject| X[\"discarded / revised\"]\n C -->|approve| D[\"④ Structure
knowledge_assets: scope (venture·industry·market·capability·use-case) + maturity (working→ready→proven)\"]\n D --> E[\"⑤ Retrieve
search_assets() by type/maturity/scope/text\"]\n E --> F[\"⑥ Consume
proposal gen · marketing · strategy · agent context · lead-qual · website-assessment\"]\n D --> G[\"⑦ Synthesise & publish
builder skills → versioned intelligence packs\"]\n G --> H[\"⑧ Downstream apps pin a pack version
leadplatform · outreachagent (→ COP recommendations)\"]\n H --> I[\"⑨ Outcomes / usage signals\"]\n I -. future Hermes loop 🔶 .-> D\n\n subgraph LabPath[\"Website Intelligence Lab — parallel evaluation path 🔶\"]\n L1[\"Business + Observed assets\"] --> L2[\"Case → Capabilities + Reference target\"]\n L2 --> L3[\"External engine executes → immutable provenanced Run\"]\n L3 --> L4[\"Generated assets + Benchmark evaluation\"]\n end\n```\n\n**What enters:** unstructured markdown docs, ad-hoc captures (voice/text/articles), agent research, legacy\nKB tables; *(lab)* subject businesses + observed website assets + engine executions. **Builder/consumer\nskills** enter from [Shared Skills](/repos/shared-skills).\n\n**What transforms:** capture → stage → **human-approved** structuring into scoped, maturity-gated\nknowledge assets → synthesis into versioned intelligence packs; *(lab)* cases → immutable provenanced runs\n→ generated assets → benchmark evaluation.\n\n**What leaves:** queryable knowledge assets (via `search_assets()`), **published intelligence packs**\n(immutable, versioned), dashboard views, and — downstream — commercial-opportunity **recommendations**;\n*(lab)* evaluated engine/capability improvements.\n\n---\n\n## Upstream inputs & downstream consumers\n\n```mermaid\ngraph LR\n subgraph Up[Upstream inputs]\n KE[Knowledge estate
markdown + captures]\n SIG[Market signals / research]\n SK[Shared Skills — builder/consumer]\n end\n subgraph L2[Intelligence Platform · layer 2]\n FIP2[PersonalOps / FIP]\n LAB2[Website Intelligence Lab]\n end\n L3[intelproducts · layer 3
published packs]\n subgraph Down[Downstream consumers · layer 4–5]\n LEAD[leadplatform
vendors packs as pinned submodule]\n OA[outreachagent
uses outreach-messaging skills → COP]\n OC[OpenClaw 🔶 planned]\n VEN[Ventures: Inexis Digital · Inexis Consulting · Inbound Lanka · City Retreats]\n end\n KE --> FIP2\n SIG --> FIP2\n SK -.-> FIP2 & LAB2 & L3\n FIP2 --> L3\n L3 --> LEAD & OA\n L3 -.-> OC\n LEAD & OA --> VEN\n```\n\n- **Upstream:** the founder's knowledge estate (46 registered docs, ~4,600 lines) + captures + research;\n Shared Skills (builder skill `intelligence-pack-publisher`, consumer skills). *(Lab:* external engines +\n external knowledge pinned by version.)*\n- **Downstream (evidenced):** `leadplatform` (vendors `intelproducts` as a **pinned git submodule**,\n read-only contract) and `outreachagent` (consumes `outreach-messaging` skills; emits COP\n recommendations). `OpenClaw` is a **planned** consumer. Ventures served: **Inexis Digital (Victoria)**,\n **Inexis Consulting (Sri Lanka)**, **Inbound Lanka**, **City Retreats**, and cross-cutting.\n\n---\n\n## Current maturity, roadmap, assumptions & known gaps\n\n**Maturity (evidence-based):**\n- **FIP (PersonalOps):** 🔶 design v1.0 *approved*; **Phase 0 complete** (Supabase migration, seed, TS\n foundation, harvest scripts, dashboard markdown rendering); **Phases 1–5 not started** (asset library,\n capture, review queue, harvest UI, AI classification, legacy migration, OpenClaw integration).\n- **intelproducts:** ✅ operational as a data contract — multiple packs published and already consumed.\n- **Website Intelligence Lab:** 🔶 early-development — infra VPS-validated; adapters/runs/evaluation pending.\n\n**Roadmap themes:** build FIP Phases 1–5 (capture → harvest UI → AI classification → legacy → agent\ningestion + OpenClaw); stand up the lab's core loop (adapter → runs → evaluation); implement the **Hermes**\nlearning loop once outcome data exists; expand pack domains.\n\n**Assumptions / uncertainties (recorded):**\n- FIP design is dated *June 2026*; implementation status beyond Phase 0 is as documented, not independently re-verified here.\n- The full **Recommendation Engine** lives in `inexisstudios`, which was **out of scope** for this review — treated as 🧭 vision from this portal's perspective.\n- `intelproducts` and `website-intelligence-lab` have **no direct code coupling**; their relationship is conceptual (mediated by PersonalOps and the \"knowledge referenced, never owned\" principle).\n\n**Known gaps:**\n- No single source repo is literally named \"Intelligence Platform\"; the layer is an assembly (documented here).\n- \"Estate generation\" is **not a real subsystem** — do not build documentation around it.\n- Hermes and OpenClaw integration are **not implemented**; any capability attributed to them is future.\n\n## Related\n- Digests: [PersonalOps / FIP](/repos/personalops) · [intelproducts](/repos/intelproducts) · [website-intelligence-lab](/repos/website-intelligence-lab)\n- System digest: [Intelligence Platform layer](/ventures/intelligence-platform)\n- [Portfolio Overview](/overview) · [System-of-systems](/architecture/system-of-systems) · [Principles](/architecture/principles)\n- Portal decision: [ADR 0003](/decisions/0003-intelligence-platform-layer-model)\n"},{"id":"/architecture/principles","kind":"page","entityType":"architecture","title":"Architecture Principles","route":"/architecture/principles","sourcePath":"portal/architecture/principles.md","slug":null,"frontmatter":{"title":"Architecture Principles","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Ecosystem-wide principles that govern how systems in Azwaan's AI venture ecosystem are designed and","headings":[{"depth":2,"text":"1. Reproducibility & complete provenance","id":"1-reproducibility-complete-provenance"},{"depth":2,"text":"2. Definition vs. derivation (separate inputs from outputs)","id":"2-definition-vs-derivation-separate-inputs-from-outputs"},{"depth":2,"text":"3. Knowledge is referenced, never owned","id":"3-knowledge-is-referenced-never-owned"},{"depth":2,"text":"4. Stage is state, not location","id":"4-stage-is-state-not-location"},{"depth":2,"text":"5. Composable, opt-in services","id":"5-composable-opt-in-services"},{"depth":2,"text":"6. Measurement / evaluation is first-class","id":"6-measurement-evaluation-is-first-class"},{"depth":2,"text":"7. No speculative abstraction (the four-part test)","id":"7-no-speculative-abstraction-the-four-part-test"},{"depth":2,"text":"8. Honest realization labelling (implemented vs planned vs vision)","id":"8-honest-realization-labelling-implemented-vs-planned-vs-vision"},{"depth":2,"text":"9. Layered leverage (capability flows upward)","id":"9-layered-leverage-capability-flows-upward"},{"depth":2,"text":"10. Phase-gated, reviewable change","id":"10-phase-gated-reviewable-change"},{"depth":2,"text":"11. Deterministic rules decide; AI explains","id":"11-deterministic-rules-decide-ai-explains"},{"depth":2,"text":"12. Capabilities are first-class and repo-independent","id":"12-capabilities-are-first-class-and-repo-independent"},{"depth":2,"text":"How to use these principles","id":"how-to-use-these-principles"},{"depth":2,"text":"Referenced from","id":"referenced-from"}],"diagrams":0,"links":["../repos/website-intelligence-lab.md","../../CLAUDE.md","../decisions/0002-layered-ecosystem-and-digest-standard.md","../repos/shared-skills.md","../../skills/portfolio-portal-orchestrator/SPEC.md","../decisions/0002-layered-ecosystem-and-digest-standard.md","../portfolio-overview.md","../decisions/0004-capability-architecture.md","../capabilities/README.md","capability-reuse-map.md","../../CLAUDE.md","../portfolio-overview.md","system-of-systems.md","intelligence-platform.md","../repos/website-intelligence-lab.md"],"body":"\n# Architecture Principles\n\nEcosystem-wide principles that govern how systems in Azwaan's AI venture ecosystem are designed and\ndocumented. Each principle is **grounded in evidence** — it was either adopted from a real repository's\ndocumented design or from this portal's own conventions, cited below. New systems are expected to\nhonour these unless an ADR justifies an exception.\n\n> **Provenance note:** Principles 1–7 were first articulated and proven in the\n> [Website Intelligence Lab](/repos/website-intelligence-lab) (`docs/philosophy.md`, its ADRs) and\n> are generalised here to the ecosystem. Principles 8–10 come from the portal's own charter\n> ([CLAUDE.md](/CLAUDE), [ADR 0002](/decisions/0002-layered-ecosystem-and-digest-standard)).\n> Nothing here is asserted beyond what those sources support.\n\n---\n\n## 1. Reproducibility & complete provenance\nEvery significant execution should be reproducible and record **everything that shaped it** (versions,\ninputs, config), so any two executions can be diffed to explain why they differ.\n*Source: WIL ADR-0004 \"Runs are immutable and fully provenanced\"; WIL philosophy §6.*\n*Ecosystem application: engines, pipelines, and agents record engine/model/knowledge versions on every run.*\n\n## 2. Definition vs. derivation (separate inputs from outputs)\nAuthored inputs and machine-generated outputs never share a home. Definitions live apart from\nderivations, joined by stable IDs.\n*Source: WIL philosophy §2 (`corpus/` vs `runs/`).*\n*Ecosystem application: mirrors the portal's own split — source repos (definition) vs the portal's digests (derivation).*\n\n## 3. Knowledge is referenced, never owned\nExternal knowledge, skills, and shared resources are integrated by **pinned version** (immutable\nrefs/hashes), not copied in. Zero duplicated content.\n*Source: WIL ADR-0006; WIL philosophy §4.*\n*Ecosystem application: the portal digests link back to source repos rather than duplicating them; the\n[Shared Skills](/repos/shared-skills) layer is consumed, not forked.*\n\n## 4. Stage is state, not location\nA thing's lifecycle stage is a **field**, not a folder it moves through. Progression is evidenced by\naccumulating records, never by relocating files.\n*Source: WIL philosophy §3; CLAUDE.md rule 5.*\n*Ecosystem application: repo/venture lifecycle is a registry field; the portal never \"moves\" a repo to advance it.*\n\n## 5. Composable, opt-in services\nCapabilities are **composed**, not hard-wired. Core systems never depend on optional services; services\nadd capability additively.\n*Source: WIL philosophy §5 (`services/`).*\n*Ecosystem application: the future [orchestrator](/skills/portfolio-portal-orchestrator/SPEC) is assembled by composing existing skills; layers add capability without the base depending on them.*\n\n## 6. Measurement / evaluation is first-class\nDecisions are evidence-based. When a choice affects quality, **comparability wins over convenience** —\nbuild the instrument to measure it.\n*Source: WIL philosophy (the lab as a \"scientific instrument\").*\n*Ecosystem application: prefer benchmarks and provenanced comparison over anecdote when evolving engines and products.*\n\n## 7. No speculative abstraction (the four-part test)\nA new concept, abstraction, or domain ships only if it: (a) solves a **real, present** problem,\n(b) **reduces future coupling**, (c) has a **clear owner**, and (d) is **explainable in one paragraph**.\nAll four, or it waits.\n*Source: WIL philosophy \"test for any new concept\"; CLAUDE.md rule 6.*\n*Ecosystem application: applies to new portal pages, new skills, and new platform subsystems alike.*\n\n## 8. Honest realization labelling (implemented vs planned vs vision)\nDocumentation must distinguish what is **implemented**, what is **planned**, and what is **architectural\nvision**. Record uncertainty explicitly; never fabricate to fill a gap (`Unknown`/`TBD`).\n*Source: portal [ADR 0002](/decisions/0002-layered-ecosystem-and-digest-standard); CLAUDE.md rule 8.*\n\n## 9. Layered leverage (capability flows upward)\nThe ecosystem is layered so that foundational capability is consumed by higher layers. Improve something\nonce at the base and every dependent layer benefits.\n*Source: portal [Portfolio Overview](/overview); ADR 0002.*\n\n## 10. Phase-gated, reviewable change\nWork proceeds in small, independently reviewable phases; each ends with an architecture review and does\nnot continue until reviewed.\n*Source: WIL implementation philosophy; portal phased plan (A–D).*\n\n## 11. Deterministic rules decide; AI explains\nWhere a decision must be defensible and repeatable, a **deterministic rule engine** decides and scores; an\nLLM may **explain** the result but never forms the opinion. *\"Recommendations must not be based on AI\nopinion. AI may explain… after the rule-based recommendation has been selected.\"*\n*Source: `inexisstudios/…/assessment-engine-plan-v2.md §13` (Website Assessment engine).*\n*Ecosystem application: scoring, qualification, and recommendation engines are rule-first; AI is the narrator, plus a human-approval gate before anything external.*\n\n## 12. Capabilities are first-class and repo-independent\nA reusable capability is documented **independently of the repositories that implement it** — with explicit\nowners, consumers, inputs/outputs, and maturity — so cross-repo reuse and duplication are visible.\n*Source: portal [ADR 0004](/decisions/0004-capability-architecture); the Website Assessment capability spans four repos.*\n*Ecosystem application: every major capability has a page in the [Capability Registry](/capabilities) and appears in the [Reuse Map](/architecture/capability-reuse-map).*\n\n---\n\n## How to use these principles\n- **Cite them** when writing a digest, ADR, or platform doc (e.g. \"per Principle 3, knowledge is referenced\").\n- **Check against them** in review — a change that violates a principle needs an ADR that says why.\n- **Extend them** only via ADR. If a new principle emerges from processing a repository, add it here with\n its source citation and reference it from the affected pages.\n\n## Referenced from\n- [CLAUDE.md](/CLAUDE) · [Portfolio Overview](/overview) ·\n [System-of-systems architecture](/architecture/system-of-systems) ·\n [Intelligence Platform](/architecture/intelligence-platform) ·\n [Website Intelligence Lab digest](/repos/website-intelligence-lab)\n"},{"id":"/architecture/recommendations","kind":"page","entityType":"architecture","title":"Architecture Review — Recommendations","route":"/architecture/recommendations","sourcePath":"portal/architecture/recommendations.md","slug":null,"frontmatter":{"title":"Architecture Review — Recommendations","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Observations from processing repositories, recorded as recommendations only — no architecture is","headings":[{"depth":2,"text":"From: shared-skills (2026-07-05)","id":"from-shared-skills-2026-07-05"},{"depth":3,"text":"Reusable capabilities identified","id":"reusable-capabilities-identified"},{"depth":3,"text":"Missing documentation (in the source repo)","id":"missing-documentation-in-the-source-repo"},{"depth":3,"text":"Opportunities to simplify architecture","id":"opportunities-to-simplify-architecture"},{"depth":3,"text":"Dependencies that should be surfaced visually","id":"dependencies-that-should-be-surfaced-visually"},{"depth":3,"text":"Duplicated capabilities that may belong elsewhere","id":"duplicated-capabilities-that-may-belong-elsewhere"},{"depth":2,"text":"From: Website Assessment capability (2026-07-05)","id":"from-website-assessment-capability-2026-07-05"}],"diagrams":0,"links":["system-of-systems.md#4-system-dependency-map-cross-repo","../../docs/update-conventions.md","capability-reuse-map.md"],"body":"\n# Architecture Review — Recommendations\n\nObservations from processing repositories, recorded as **recommendations only** — no architecture is\nchanged here. Each entry is dated and sourced. Promote significant ones to ADRs when acted on.\n\n## From: shared-skills (2026-07-05)\n\n### Reusable capabilities identified\n| Capability | Where | Reuse opportunity |\n|------------|-------|-------------------|\n| Architecture diagram + dependency generation | `senior-architect` scripts | Core engine for the future orchestrator's diagram/dependency features |\n| Multi-language dependency & license audit | `dependency-auditor` | Orchestrator \"detect changed dependencies\" feature |\n| `llms.txt` generation | `create-llms` / `update-llms` | Keep the portal's machine index in sync automatically |\n| Doc/orphan/dead-link hygiene | `knowledge-ops` | Recurring portal consistency checks |\n| Repo summarization | `codebase-onboarding` | First pass at each new repo digest |\n| Design tokens / brand onboarding | `design-system`, `ui-design-system` | Phase C showcase consistency |\n\n**Recommendation:** the `portfolio-portal-orchestrator` should be assembled primarily by *composing\nthese existing skills* rather than re-implementing their logic.\n\n### Missing documentation (in the source repo)\n- No repo-level `README.md` or `CLAUDE.md` for the skills library itself.\n- No internal **skills index / taxonomy** — discoverability depends entirely on per-skill descriptions.\n- No `LICENSE` aggregation despite skills carrying MIT/Apache-2.0 individually.\n- **Recommendation:** if the library is promoted to a first-class repo, add root docs + a generated\n taxonomy file. (Recorded, not actioned.)\n\n### Opportunities to simplify architecture\n- **Consolidate near-duplicate skills** to reduce trigger-routing ambiguity (see duplication below).\n- Introduce a **cluster/taxonomy layer** so the 169 skills are navigable as ~10 groups.\n- **Recommendation:** a lightweight `INDEX.md`/registry inside the skills repo (the orchestrator could\n generate it) would materially improve maintainability.\n\n### Dependencies that should be surfaced visually\n- `portfolio-portal → shared-skills` (realized) — now drawn in the\n [System Dependency Map](/architecture/system-of-systems#4-system-dependency-map-cross-repo).\n- `portfolio-portal-orchestrator → {shared-skills, portfolio-portal}` (planned) — drawn dashed.\n- **Recommendation:** as layers 2–6 gain repos, each new upstream/downstream edge must be added to the\n dependency map in the same change (per [update conventions](/about/update-conventions)).\n\n### Duplicated capabilities that may belong elsewhere\n| Overlap | Skills | Note |\n|---------|--------|------|\n| RevOps | `revops` ⟷ `revenue-operations` | Likely merge candidates |\n| DB design | `database-designer` ⟷ `database-schema-designer` | Overlapping ERD/schema scope |\n| Senior engineering | `senior-backend/frontend/fullstack` + `senior-architect` | Shared surface; clarify boundaries |\n| Competitor analysis | `competitors`, `competitor-profiling`, `competitive-teardown`, `competitive-intel` | Four skills, adjacent intent |\n| LLMs index | `create-llms` ⟷ `update-llms` | Complementary, but could be one skill with modes |\n\n**Recommendation:** treat consolidation as an internal-tooling roadmap item; do not merge blindly —\nsome overlaps are intentional (different altitudes/audiences). Validate before acting.\n\n---\n\n## From: Website Assessment capability (2026-07-05)\n\nRecorded during Phase C (see the [Capability Reuse Map](/architecture/capability-reuse-map) for the full analysis):\n\n- **Duplicate opportunity scoring.** `intelproducts` pack scoring (website quality 0–100) and `leadplatform`'s\n own \"Opportunity Intelligence\" scoring use different dimensions. **Recommend:** have leadplatform consume the\n assessment/COP instead of maintaining a parallel score, to avoid two disagreeing \"opportunity\" numbers.\n- **Recommendation logic spans three layers** (engine rules → pack `recommendation-library` → COP `action`).\n **Recommend:** treat the pack as the single source of truth and pin versions across engine + COP.\n- **Pack drift via vendoring.** Consumers vendor `intelproducts` as pinned submodules; stale pins score against\n old intelligence. **Recommend:** track pinned pack versions in the registry.\n- **Inference-derived scoring weights** (not empirical). **Recommend:** prioritise the Hermes learning loop to\n replace review-gated defaults with outcome-derived weights.\n- **Strong reuse win (keep doing):** the engine is domain-agnostic + pack-driven — new verticals/ventures are\n new packs, not new code (cleaning, travel/Inbound Lanka proven). Use as the template for future capabilities.\n\n---\n\n> **How to use this page:** add a dated `## From: ` section each time a repository is processed.\n> When a recommendation is accepted and acted on, capture it as an ADR and link it here.\n"},{"id":"/architecture/strategic-opportunities","kind":"page","entityType":"architecture","title":"Strategic Opportunities","route":"/architecture/strategic-opportunities","sourcePath":"portal/architecture/strategic-opportunities.md","slug":null,"frontmatter":{"title":"Strategic Opportunities","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Opportunities identified by the Phase-D Architecture Review to evolve the ecosystem","headings":[{"depth":2,"text":"Opportunity map","id":"opportunity-map"},{"depth":2,"text":"1 · Platform simplification","id":"1-platform-simplification"},{"depth":2,"text":"2 · Increased automation","id":"2-increased-automation"},{"depth":2,"text":"3 · Improved reuse","id":"3-improved-reuse"},{"depth":2,"text":"4 · Better AI orchestration","id":"4-better-ai-orchestration"},{"depth":2,"text":"5 · Reduced maintenance","id":"5-reduced-maintenance"},{"depth":2,"text":"6 · Future commercialisation","id":"6-future-commercialisation"},{"depth":2,"text":"Sequencing (recommended)","id":"sequencing-recommended"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["architecture-review.md","principles.md","architecture-review.md","architecture-risks.md","architecture-evolution.md","../decisions/0005-platform-services-and-consolidation.md","../../skills/portfolio-portal-orchestrator/SPEC.md"],"body":"\n# Strategic Opportunities\n\nOpportunities identified by the [Phase-D Architecture Review](/architecture/architecture-review) to evolve the ecosystem\ninto a cleaner, more reusable, more scalable AI platform. Evidence-based; each opportunity ties to a documented\nfinding. These are **recommendations**, sequenced by leverage.\n\n## Opportunity map\n\n```mermaid\ngraph TD\n subgraph Now[\"Consolidate & extract (highest leverage)\"]\n O1[Platform Services layer
extract Assessment / COP / Retrieval / Evaluation]\n O2[Single source of truth
pack = rules + scoring]\n end\n subgraph Automate[\"Automate the ecosystem\"]\n O3[portfolio-portal-orchestrator]\n O4[Automated pack publication + pin-freshness]\n end\n subgraph Close[\"Close the loops\"]\n O5[FIP capture→retrieve loop]\n O6[Lab core loop + Hermes learning]\n end\n subgraph Commercial[\"Commercialise\"]\n O7[Assessment-as-a-SaaS]\n O8[Skills / packs as products]\n end\n O1 --> O3\n O2 --> O6\n O5 --> O6 --> O7\n```\n\n## 1 · Platform simplification\n- **Introduce a Platform Services layer** and extract reusable services (Assessment, Opportunity/COP, Retrieval,\n Evaluation) out of venture/app repos (addresses R1, §3, §5). *Result: thin ventures compose services; fewer\n bespoke stacks.*\n- **One opportunity-scoring model** — retire `leadplatform`'s parallel score in favour of the pack/COP\n (addresses R2). *Result: one defensible number, less code.*\n- **Consolidate near-duplicate skills** in `shared-skills` (revops/revenue-operations, database-designer/…, competitor cluster).\n\n## 2 · Increased automation\n- **Build the `portfolio-portal-orchestrator`** (already specified) to auto-generate digests, diagrams,\n registry rows, capability pages, and `llms.txt` from source — turning the portal's manual upkeep (R8) into a\n generated artefact.\n- **Automate pack publication** from FIP builder skills, and add **pin-freshness checks** so consumers can't\n silently drift (R5).\n\n## 3 · Improved reuse\n- Make **service + pack composition the default way to launch a venture** (the domain-agnostic engine already\n proves it: new vertical = new pack). *Result: fewer future repositories.*\n- **Reuse the COP contract** in `leadplatform` instead of a second scoring model.\n- **Expose FIP retrieval as a service** so consumers query intelligence instead of vendoring full pack trees.\n\n## 4 · Better AI orchestration\n- **Converge AI prompt surfaces** (engine narrative, pack report guidance, outreach skills) onto a **shared,\n fact-grounded claims/tone guardrail** (addresses R9) — enforcing \"AI explains from structured facts only\"\n ([Principle 11](/architecture/principles)) consistently, with stricter guardrails for regulated verticals.\n- Position **OpenClaw (when integrated)** as a *governed consumer* of the retrieval + assessment **services**,\n not a bespoke integration — one agent interface over reusable services.\n\n## 5 · Reduced maintenance\n- Orchestrator + automated packs + single scoring source + consolidated skills together cut the hand-maintained\n surface (the long intelligence transformation chain, §6).\n- **Rationalise data platforms** (Supabase vs D1) with a deliberate boundary (R10) to reduce operational load.\n- **Design Hermes as one-way feedback** (new pack version, never mutate) to avoid future coupling (R12).\n\n## 6 · Future commercialisation\nGrounded in what already exists, not speculation:\n- **Website Assessment as a SaaS** — it is already an **API + domain-agnostic pack model** across 10 verticals;\n the hardest parts (rules, scoring, report contract) are built. Multi-tenanting the extracted Assessment\n Service is a credible external product for agencies/verticals.\n- **Intelligence packs as licensable data products** — versioned, immutable, machine-consumable packs are\n natural B2B data products (e.g. industry assessment packs).\n- **Shared Skills as a distributable pack** — already multi-author, MIT/Apache-licensed, cross-tool.\n- **The portal + orchestrator as a methodology/product** — \"architecture-as-a-service\" for other multi-venture\n founders.\n\n> Commercialisation opportunities are **strategic options**, not commitments — each depends on the platform\n> extraction and loop-closing above landing first.\n\n## Sequencing (recommended)\n1. **Extract Assessment Service + single scoring source** (P1; unblocks reuse and commercialisation).\n2. **Build the orchestrator + automate packs** (P2; cuts maintenance, keeps the portal true).\n3. **Close FIP + lab + Hermes loops** (P1/P2; makes the platform self-improving).\n4. **Then** pursue commercialisation of the now-clean services and packs.\n\n## Related\n- [Architecture Review](/architecture/architecture-review) · [Architecture Risks](/architecture/architecture-risks) · [Architecture Evolution](/architecture/architecture-evolution)\n- Proposed [ADR 0005](/decisions/0005-platform-services-and-consolidation) · [Orchestrator spec](/skills/portfolio-portal-orchestrator/SPEC)\n"},{"id":"/architecture/system-of-systems","kind":"page","entityType":"architecture","title":"System-of-Systems Architecture","route":"/architecture/system-of-systems","sourcePath":"portal/architecture/system-of-systems.md","slug":null,"frontmatter":{"title":"System-of-Systems Architecture","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The whole-ecosystem view: how ventures, repos, and shared services relate. Diagrams are Mermaid, embedded so","headings":[{"depth":2,"text":"1. System context (layered)","id":"1-system-context-layered"},{"depth":2,"text":"2. Container / service map","id":"2-container-service-map"},{"depth":2,"text":"3. Layer / system map","id":"3-layer-system-map"},{"depth":2,"text":"4. System Dependency Map (cross-repo)","id":"4-system-dependency-map-cross-repo"},{"depth":2,"text":"Node → digest index","id":"node-digest-index"},{"depth":2,"text":"Related","id":"related"}],"diagrams":4,"links":["intelligence-platform.md","../portfolio-overview.md","principles.md","intelligence-platform.md","../repos/shared-skills.md","../repos/personalops.md","../repos/website-intelligence-lab.md","../repos/intelproducts.md","../capabilities/cap-website-assessment.md","../ventures/intelligence-platform.md","../ventures/shared-skills.md","../../README.md","../portfolio-overview.md","intelligence-platform.md","../capabilities/README.md","capability-reuse-map.md","principles.md","recommendations.md","../registry/repo-registry.md","../current-state/status-dashboard.md","../decisions/README.md"],"body":"\n# System-of-Systems Architecture\n\nThe whole-ecosystem view: how ventures, repos, and shared services relate. Diagrams are Mermaid, embedded so\nGitHub renders them. Individual repo/venture diagrams live in their digests; the deep platform view is in\n[Intelligence Platform architecture](/architecture/intelligence-platform); this page is the *system of systems*. For the\nexecutive framing see the [Portfolio Overview](/overview); for the rules governing it all see\n[Architecture Principles](/architecture/principles).\n\n**Framing (from `senior-architect`):** the ecosystem is described at four altitudes — layered/system context,\ncontainer/service, layer grouping, and cross-repo dependencies.\n\n> **Realization key:** ✅ operational · 🔶 partial/planned · 🧭 vision. Labels are evidence-based; nothing\n> un-evidenced is asserted (Principle 8).\n\n---\n\n## 1. System context (layered)\n\n```mermaid\ngraph TD\n Azwaan([Azwaan / Founder]) --> Eco\n SRC((Knowledge estate · captures · signals)) --> Eco\n subgraph Eco[\"Azwaan AI Venture Ecosystem\"]\n direction TB\n L6[6 · Customer-facing 🧭] --> Market\n L5[5 · Ventures 🧭
Inexis Digital · Consulting · Inbound Lanka · City Retreats] --> L6\n L4[4 · Applications & Agents 🔶
leadplatform · outreachagent] --> L5\n L3[3 · Intelligence Products 🔶
intelproducts] --> L4\n L2[2 · Intelligence Platform 🔶
PersonalOps/FIP · website-intelligence-lab] --> L3\n L1[1 · Shared Skills ✅
169 skills] --> L2\n end\n Eco --> Market((Customers / Market))\n Ext[External: Anthropic · Supabase · Cloudflare · WordPress] --- Eco\n classDef live fill:#1f7a1f,color:#fff;\n class L1 live;\n```\n\n---\n\n## 2. Container / service map\n\n```mermaid\ngraph TD\n subgraph L1[\"Shared Skills ✅\"]\n SS[169 skills]\n end\n subgraph L2[\"Intelligence Platform 🔶\"]\n FIP[\"PersonalOps/FIP
TanStack UI + Supabase + harvest\"]\n LAB[\"website-intelligence-lab
Docker · Caddy · WP Multisite + runs\"]\n end\n IPR[(\"intelproducts 🔶
versioned packs + consumer skills\")]\n subgraph L4[\"Applications & Agents 🔶\"]\n LEAD[\"leadplatform
Next.js + CF Worker/D1\"]\n OA[\"outreachagent
COP recommendations\"]\n end\n PORTAL[\"portfolio-portal
docs/governance\"]\n\n SS -->|built with| PORTAL\n SS -.-> FIP & LAB & IPR\n FIP --> IPR\n IPR -->|pinned submodule| LEAD\n IPR --> OA\n LEAD & OA --> VEN[Ventures 🧭]\n```\n\n---\n\n## 3. Layer / system map\n\n```mermaid\ngraph LR\n subgraph LYR1[L1 · Shared Skills]\n R1[shared-skills]\n end\n subgraph LYR2[L2 · Intelligence Platform]\n R2[personalops]\n R3[website-intelligence-lab]\n end\n subgraph LYR3[L3 · Intelligence Products]\n R4[intelproducts]\n end\n subgraph LYR4[L4 · Applications & Agents]\n R5[leadplatform]\n R6[outreachagent]\n end\n subgraph DOCS[Docs / Governance]\n RP[portfolio-portal]\n end\n R1 --> RP\n R1 -.-> R2 & R3 & R4\n R2 --> R4\n R4 --> R5 & R6\n R5 & R6 -.-> LYR5[L5 · Ventures 🧭]\n```\n\n---\n\n## 4. System Dependency Map (cross-repo)\n\nSolid = evidenced dependency; dashed = planned/future or lateral capability.\n\n```mermaid\ngraph TD\n HARNESS[AI Harness / Agent SDK] -->|routes to| SS[shared-skills]\n SS -->|skills used to build| PORTAL[portfolio-portal]\n SS -.capability.-> FIP[personalops/FIP]\n SS -.capability.-> LAB[website-intelligence-lab]\n SS -.builder+consumer skills.-> IPR[intelproducts]\n\n FIP -->|authors & publishes packs| IPR\n IPR -->|pinned git submodule| LEAD[leadplatform]\n IPR -->|consumer skills| OA[outreachagent]\n IPR -->|website-assessment pack = scoring truth| INX[inexisstudios
assessment engine]\n INX -->|/api/assessments → COP| OA\n INX -.evaluated against.-> LAB\n LAB -.references external knowledge by version.-> KNOW[(external knowledge)]\n\n PORTAL -.will be automated by.-> ORCH[[portfolio-portal-orchestrator]]\n ORCH -.reads.-> SS & FIP & LAB & IPR\n\n classDef future fill:#eee,stroke-dasharray:4 3;\n class ORCH future;\n```\n\n**Evidenced dependencies**\n- `portfolio-portal` **depends on** `shared-skills` (built with its skills).\n- `personalops/FIP` **produces** `intelproducts` (authors packs via builder skills).\n- `inexisstudios` (assessment engine) **depends on** the `intelproducts` website-assessment pack (scoring truth).\n- `outreachagent` **depends on** `inexisstudios` (`/api/assessments` → COP) and `intelproducts` (`outreach-messaging` skills).\n- `leadplatform` **depends on** `intelproducts` (**pinned git submodule**, read-only contract).\n- `inexisstudios` is **evaluated against** `website-intelligence-lab` (harness/runs — Phase-1 seed).\n- `personalops`, `website-intelligence-lab`, `intelproducts` **consume** `shared-skills` capability.\n\n**Sibling, non-dependent (recorded):** `personalops/FIP` and `website-intelligence-lab` have **no direct code\ncoupling** — related only conceptually (knowledge referenced, never owned; Principle 3).\n\n**Planned / not-built:** the `portfolio-portal-orchestrator` (spec only); external website **engines** (run\nagainst the lab); the **Hermes** learning loop; **OpenClaw** pack consumption. *\"Estate generation\"* is **not\na real subsystem** (see [Intelligence Platform](/architecture/intelligence-platform)).\n\n---\n\n## Node → digest index\n\n| Node ID | Kind | Digest |\n|---------|------|--------|\n| `shared-skills` | repo (L1) | [repos/shared-skills](/repos/shared-skills) |\n| `personalops` | repo (L2) | [repos/personalops](/repos/personalops) |\n| `website-intelligence-lab` | repo (L2) | [repos/website-intelligence-lab](/repos/website-intelligence-lab) |\n| `intelproducts` | repo (L3) | [repos/intelproducts](/repos/intelproducts) |\n| `inexisstudios` | repo (L4) — assessment engine | [capability: Website Assessment](/capabilities/cap-website-assessment) |\n| `leadplatform` | repo (L4) | *not yet processed* (registry row) |\n| `outreachagent` | repo (L4) | *not yet processed* (registry row) |\n| `intelligence-platform` | system | [ventures/intelligence-platform](/ventures/intelligence-platform) |\n| `shared-skills` (layer) | system | [ventures/shared-skills](/ventures/shared-skills) |\n| `portfolio-portal` | repo (this repo) | [README](/readme) |\n\n## Related\n- [Portfolio Overview](/overview) · [Intelligence Platform architecture](/architecture/intelligence-platform)\n- [Capability Registry](/capabilities) · [Capability Reuse Map](/architecture/capability-reuse-map)\n- [Architecture Principles](/architecture/principles) · [Recommendations](/architecture/recommendations)\n- [Repo registry](/registry/repo-registry) · [Current state](/current-state/status-dashboard) · [Decisions](/decisions)\n"},{"id":"/capabilities","kind":"page","entityType":"registry","title":"Capability Registry","route":"/capabilities","sourcePath":"portal/capabilities/README.md","slug":null,"frontmatter":{"title":"Capability Registry","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The capability-architecture view of the ecosystem: the reusable business and technical capabilities","headings":[{"depth":2,"text":"Registry","id":"registry"},{"depth":2,"text":"Column contract","id":"column-contract"},{"depth":2,"text":"How capabilities relate","id":"how-capabilities-relate"},{"depth":2,"text":"See also","id":"see-also"},{"depth":2,"text":"Adding a capability","id":"adding-a-capability"}],"diagrams":1,"links":["../registry/repo-registry.md","../../templates/capability.template.md","cap-reusable-ai-skills.md","cap-knowledge-intelligence.md","cap-intelligence-productization.md","cap-reproducible-evaluation.md","cap-website-assessment.md","cap-commercial-opportunity.md","cap-architecture-governance.md","../architecture/capability-reuse-map.md","../registry/repo-registry.md","../portfolio-overview.md","../architecture/principles.md","../../templates/capability.template.md","../architecture/capability-reuse-map.md"],"body":"\n# Capability Registry\n\nThe **capability-architecture** view of the ecosystem: the reusable business and technical **capabilities**\nthat exist, who owns them, who consumes them, and how they work together — documented **independently from\nrepositories**. Where the [Repo Registry](/registry/repo-registry) answers *\"which repos exist\"*, this\nanswers *\"which capabilities exist and how they are reused.\"*\n\nThis registry is a primary navigation entry point. Every capability has a page following\n[`templates/capability.template.md`](../../templates/capability.template.md). Maturity is evidence-based and\nhonestly labelled (✅ operational · 🔶 partial/under-development · ⏳ planned · 🧭 vision).\n\n## Registry\n\n\n| Capability | Purpose (short) | Owning repo(s) | Consumers | Maturity | Page |\n|------------|-----------------|----------------|-----------|----------|------|\n| **Reusable AI Skills** | Standardized, invocable AI competence as infrastructure | `shared-skills` | all layers | ✅ operational | [page](/capabilities/cap-reusable-ai-skills) |\n| **Knowledge Intelligence** | Capture → structure → retrieve founder intelligence | `personalops` (FIP) | FIP dashboard, agents, ventures | 🔶 early-development | [page](/capabilities/cap-knowledge-intelligence) |\n| **Intelligence Productization** | Publish versioned, immutable intelligence packs | `intelproducts` (+ FIP builders) | `leadplatform`, `outreachagent` | ✅ operational (contract) | [page](/capabilities/cap-intelligence-productization) |\n| **Reproducible Evaluation** | Immutable, provenanced experiment & benchmark harness | `website-intelligence-lab` | external engines | 🔶 early-development | [page](/capabilities/cap-reproducible-evaluation) |\n| **Website Assessment** | Assess a website → findings → scored gap analysis → recommendations | `inexisstudios`, `intelproducts` (pack), `website-intelligence-lab` | `outreachagent`, `leadplatform`, Inexis Digital | 🔶 mixed | [page](/capabilities/cap-website-assessment) |\n| **Commercial Opportunity & Outreach** | Turn assessment findings into COPs + outreach messaging | `outreachagent` (+ `intelproducts` skills) | Inexis Digital sales | 🔶 operational (per Phase-B evidence) | [page](/capabilities/cap-commercial-opportunity) |\n| **Architecture & Docs Governance** | Document the system of systems; govern architecture | `portfolio-portal` (+ `shared-skills` doc skills) | whole ecosystem | ✅ operational | [page](/capabilities/cap-architecture-governance) |\n\n## Column contract\n| Column | Meaning | Allowed values |\n|--------|---------|----------------|\n| Capability | Human name | — |\n| Owning repo(s) | Provider(s) | must match `portal/repos/*` or a registered repo |\n| Consumers | Consuming repos/ventures | — |\n| Maturity | Assessment | concept / early-development / active-development / operational / production (+ honesty marker) |\n| Page | Capability page | `cap-.md` |\n\n## How capabilities relate\n\n```mermaid\ngraph TD\n SKILLS[[Reusable AI Skills]] -.underpins.-> KI[[Knowledge Intelligence]]\n SKILLS -.underpins.-> IPZ[[Intelligence Productization]]\n SKILLS -.underpins.-> EVAL[[Reproducible Evaluation]]\n SKILLS -.underpins.-> WA[[Website Assessment]]\n SKILLS -.underpins.-> GOV[[Architecture & Docs Governance]]\n\n KI --> IPZ\n IPZ -->|packs feed| WA\n EVAL -->|evaluates engines for| WA\n WA -->|findings feed| CO[[Commercial Opportunity & Outreach]]\n IPZ -->|messaging packs| CO\n```\n\n## See also\n- [Capability Reuse Map](/architecture/capability-reuse-map) — providers, consumers, shared assets, duplication risks.\n- [Repo Registry](/registry/repo-registry) · [Portfolio Overview](/overview) · [Architecture Principles](/architecture/principles)\n\n## Adding a capability\nCopy [`templates/capability.template.md`](../../templates/capability.template.md) → `cap-.md`, add a\nregistry row, and link it from the relevant repo digests and the [Reuse Map](/architecture/capability-reuse-map).\n"},{"id":"/capabilities/cap-architecture-governance","kind":"page","entityType":"capability","title":"Architecture & Docs Governance","route":"/capabilities/cap-architecture-governance","sourcePath":"portal/capabilities/cap-architecture-governance.md","slug":"cap-architecture-governance","frontmatter":{"title":"Architecture & Docs Governance","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"cap-architecture-governance","maturity":"operational","providers":["portfolio-portal","shared-skills"],"consumers":["portfolio-portal"]},"excerpt":"Document the system of systems and govern its architecture: repository digests, capability architecture,","headings":[{"depth":2,"text":"Purpose","id":"purpose"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Business value","id":"business-value"},{"depth":2,"text":"Technical responsibilities","id":"technical-responsibilities"},{"depth":2,"text":"Owning repository or repositories","id":"owning-repository-or-repositories"},{"depth":2,"text":"Consuming repositories / consumers","id":"consuming-repositories-consumers"},{"depth":2,"text":"Consuming ventures","id":"consuming-ventures"},{"depth":2,"text":"Inputs","id":"inputs"},{"depth":2,"text":"Outputs","id":"outputs"},{"depth":2,"text":"Dependencies","id":"dependencies"},{"depth":2,"text":"Capability relationships","id":"capability-relationships"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Planned evolution","id":"planned-evolution"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../../README.md","../repos/shared-skills.md","../../README.md","../repos/shared-skills.md","cap-reusable-ai-skills.md","../../README.md","../portfolio-overview.md","../../skills/portfolio-portal-orchestrator/SPEC.md","README.md","../architecture/capability-reuse-map.md"],"body":"\n# Architecture & Docs Governance — Capability\n\n\n## Purpose\nDocument the **system of systems** and govern its architecture: repository digests, capability architecture,\nlayered model, ADRs, principles, and diagrams — the portal you are reading. It turns a scattered set of repos\ninto an architectural source of truth.\n\n\n## At a glance\n| Field | Value |\n|-------|-------|\n| Slug | `cap-architecture-governance` |\n| Maturity | ✅ operational |\n| Owning repo(s) | [`portfolio-portal`](/readme) + [`shared-skills`](/repos/shared-skills) (doc skills) |\n| Layer(s) | Docs / Governance |\n| Last reviewed | 2026-07-05 |\n\n## Business value\nA single onboarding guide, AI-context source, and architectural reference — and, later, a public showcase of\nthe ecosystem's scale and sophistication.\n\n## Technical responsibilities\n- Maintain digests, capability registry, layered architecture, ADRs, principles, current-state, and `llms.txt`.\n- Enforce evidence-first, honestly-labelled documentation (Principle 8).\n- Not responsible for building the systems it documents.\n\n## Owning repository or repositories\n| Repo | Role |\n|------|------|\n| [`portfolio-portal`](/readme) | The portal itself |\n| [`shared-skills`](/repos/shared-skills) | `documentation-writer`, `senior-architect`, `site-architecture`, `create-llms`, `knowledge-ops` |\n\n## Consuming repositories / consumers\n- Every repo & venture is a *subject*; humans and AI agents (Claude, ChatGPT) are the consumers of the docs.\n\n## Consuming ventures\n- All — as onboarding and architectural reference.\n\n## Inputs\n- Source repos' docs (CLAUDE.md, READMEs, ADRs), evidence hunts, and architectural decisions.\n\n## Outputs\n- Repo/venture/capability digests, architecture diagrams, ADRs, principles, `llms.txt`, the future showcase.\n\n## Dependencies\n- [Reusable AI Skills](/capabilities/cap-reusable-ai-skills) (documentation & architecture skills).\n\n## Capability relationships\n\n```mermaid\ngraph LR\n PORTAL[portfolio-portal] -->|provides| CAP[[Architecture & Docs Governance]]\n SS[Reusable AI Skills] -.underpins.-> CAP\n CAP -.documents.-> ALL[All capabilities & repos]\n CAP -.will be automated by.-> ORCH[[portfolio-portal-orchestrator]]\n```\n\n## Current maturity\n✅ **Operational.** The portal actively documents 4 systems across 4 layers with capability architecture,\ndiagrams, principles, and ADRs. Automation (`portfolio-portal-orchestrator`) is spec-only.\n\n## Planned evolution\nImplement the orchestrator (Phase D) to auto-generate digests/diagrams; build the public showcase (Phase C).\n\n## Related\n- Repo: [`portfolio-portal`](/readme) · Overview: [Portfolio Overview](/overview)\n- Orchestrator spec: [SPEC](/skills/portfolio-portal-orchestrator/SPEC)\n- Registry: [Capability Registry](/capabilities) · [Reuse Map](/architecture/capability-reuse-map)\n"},{"id":"/capabilities/cap-commercial-opportunity","kind":"page","entityType":"capability","title":"Commercial Opportunity & Outreach","route":"/capabilities/cap-commercial-opportunity","sourcePath":"portal/capabilities/cap-commercial-opportunity.md","slug":"cap-commercial-opportunity","frontmatter":{"title":"Commercial Opportunity & Outreach","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"cap-commercial-opportunity","maturity":"operational","providers":["outreachagent","intelproducts"],"consumers":["outreachagent"]},"excerpt":"Turn a website assessment into a Commercial Opportunity Profile (COP) — a structured decision on whether a","headings":[{"depth":2,"text":"Purpose","id":"purpose"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Business value","id":"business-value"},{"depth":2,"text":"Technical responsibilities","id":"technical-responsibilities"},{"depth":2,"text":"Owning repository or repositories","id":"owning-repository-or-repositories"},{"depth":2,"text":"Consuming repositories / ventures","id":"consuming-repositories-ventures"},{"depth":2,"text":"Inputs","id":"inputs"},{"depth":2,"text":"Outputs","id":"outputs"},{"depth":2,"text":"Dependencies","id":"dependencies"},{"depth":2,"text":"Capability relationships","id":"capability-relationships"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Planned evolution","id":"planned-evolution"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../repos/intelproducts.md","cap-website-assessment.md","../repos/intelproducts.md","cap-website-assessment.md","cap-intelligence-productization.md","cap-reusable-ai-skills.md","cap-website-assessment.md","cap-intelligence-productization.md","README.md","../architecture/capability-reuse-map.md"],"body":"\n# Commercial Opportunity & Outreach — Capability\n\n\n## Purpose\nTurn a website assessment into a **Commercial Opportunity Profile (COP)** — a structured decision on whether a\nbusiness should get a new industry-informed website — and render it into outreach (email, proposal) and CRM\nstaging. Provided by `outreachagent` using `intelproducts` outreach-messaging skills.\n\n\n## At a glance\n| Field | Value |\n|-------|-------|\n| Slug | `cap-commercial-opportunity` |\n| Maturity | 🔶 operational (built; **mock assessment default**, live wired) |\n| Owning repo(s) | `outreachagent` (+ [`intelproducts`](/repos/intelproducts) `outreach-messaging` skills) |\n| Layer(s) | 4 · Applications & Agents |\n| Last reviewed | 2026-07-05 |\n\n## Business value\nConverts diagnostic output into **qualified, prioritised sales action** for Inexis Digital — automatically\nstaging prospects while enforcing *\"nothing is ever auto-sent.\"*\n\n## Technical responsibilities\n- Produce the **COP** (schema v2, **frozen**): `evidence → diagnosis → recommendation → solution_blueprint → summary`.\n- Decide `recommendation.action ∈ {replace_website, monitor, manual_review, no_opportunity}` and stage the prospect in CRM.\n- Render email/proposal from the COP. Not responsible for producing the assessment (that's [Website Assessment](/capabilities/cap-website-assessment)).\n\n## Owning repository or repositories\n| Repo | Role |\n|------|------|\n| `outreachagent` | COP production, CRM staging, message rendering *(not yet fully digested)* |\n| [`intelproducts`](/repos/intelproducts) | `outreach-messaging` consumer skills (first-touch-email, follow-up-email, website-replacement-proposal, findings-translator, commercial-opportunity) |\n\n## Consuming repositories / ventures\n- **Inexis Digital** sales/outreach — the primary consumer of COPs and messages.\n\n## Inputs\n- A completed **website assessment** (via `evaluateCommercialOpportunity({business_context, website_url, industry})`), prospect/business context.\n\n## Outputs\n- A **COP** (`cop_ref`), a `recommendation.action`, CRM stage (`qualified / do_not_contact / assessed`), and rendered email/proposal drafts.\n\n## Dependencies\n- [Website Assessment](/capabilities/cap-website-assessment) (the upstream assessment/score); [Intelligence Productization](/capabilities/cap-intelligence-productization) (outreach-messaging pack/skills); [Reusable AI Skills](/capabilities/cap-reusable-ai-skills).\n\n## Capability relationships\n\n```mermaid\ngraph LR\n WA[[Website Assessment]] -->|assessment/score| CAP[[Commercial Opportunity & Outreach]]\n IPZ[[Intelligence Productization]] -->|outreach-messaging skills| CAP\n CAP -->|COP + email/proposal| CRM[CRM staging]\n CRM --> VEN[Inexis Digital sales]\n```\n\n## Current maturity\n🔶 **Operational, with a caveat.** The COP schema is frozen (v2) and the assessment→COP→CRM pipeline is built;\nper the Phase-B evidence hunt an end-to-end run completed, but the **assessment runs in mock mode by default**\nand a **live assessment + real send is an open checklist item**. *(Source: outreachagent `CLAUDE.md`, `README.md`,\n`.env.example`.)*\n\n## Planned evolution\nOperational live-send validation; richer solution blueprints; feed outcomes back via the future **Hermes** loop.\n\n## Related\n- Capabilities: [Website Assessment](/capabilities/cap-website-assessment) · [Intelligence Productization](/capabilities/cap-intelligence-productization)\n- Repo digest for `outreachagent`: ⏳ not yet processed (registered downstream consumer)\n- Registry: [Capability Registry](/capabilities) · [Reuse Map](/architecture/capability-reuse-map)\n"},{"id":"/capabilities/cap-intelligence-productization","kind":"page","entityType":"capability","title":"Intelligence Productization","route":"/capabilities/cap-intelligence-productization","sourcePath":"portal/capabilities/cap-intelligence-productization.md","slug":"cap-intelligence-productization","frontmatter":{"title":"Intelligence Productization","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"cap-intelligence-productization","maturity":"operational","providers":["intelproducts","personalops"],"consumers":["leadplatform","outreachagent"]},"excerpt":"Package the platform's intelligence into versioned, immutable, machine-consumable packs that downstream","headings":[{"depth":2,"text":"Purpose","id":"purpose"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Business value","id":"business-value"},{"depth":2,"text":"Technical responsibilities","id":"technical-responsibilities"},{"depth":2,"text":"Owning repository or repositories","id":"owning-repository-or-repositories"},{"depth":2,"text":"Consuming repositories","id":"consuming-repositories"},{"depth":2,"text":"Consuming ventures","id":"consuming-ventures"},{"depth":2,"text":"Inputs","id":"inputs"},{"depth":2,"text":"Outputs","id":"outputs"},{"depth":2,"text":"Dependencies","id":"dependencies"},{"depth":2,"text":"Capability relationships","id":"capability-relationships"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Planned evolution","id":"planned-evolution"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../repos/intelproducts.md","../repos/personalops.md","../architecture/principles.md","../repos/intelproducts.md","../repos/personalops.md","cap-knowledge-intelligence.md","cap-knowledge-intelligence.md","cap-reusable-ai-skills.md","../repos/intelproducts.md","../repos/intelproducts.md","../architecture/intelligence-platform.md","README.md","../architecture/capability-reuse-map.md"],"body":"\n# Intelligence Productization — Capability\n\n\n## Purpose\nPackage the platform's intelligence into **versioned, immutable, machine-consumable packs** that downstream\napps pin and consume — intelligence as a stable dependency, not ad-hoc copies.\n\n\n## At a glance\n| Field | Value |\n|-------|-------|\n| Slug | `cap-intelligence-productization` |\n| Maturity | ✅ operational (as a contract) |\n| Owning repo(s) | [`intelproducts`](/repos/intelproducts) (data) + [`personalops`](/repos/personalops) (builder skills) |\n| Layer(s) | 3 · Intelligence Products (produced by layer 2) |\n| Last reviewed | 2026-07-05 |\n\n## Business value\nLets multiple ventures/apps reuse the same governed intelligence with version stability — the concrete\nembodiment of \"knowledge referenced, never owned\" ([Principle 3](/architecture/principles)).\n\n## Technical responsibilities\n- Hold immutable, versioned packs grouped by domain; provide consumer skills to act on them.\n- Preserve the Stage-1 → Stage-3 pack contract; enforce versioning (additive → in place; structural → new version dir).\n- Not responsible for producing intelligence (Knowledge Intelligence) or consuming it (downstream apps).\n\n## Owning repository or repositories\n| Repo | Role |\n|------|------|\n| [`intelproducts`](/repos/intelproducts) | Published packs + consumer skills |\n| [`personalops`](/repos/personalops) | Builder skills that author packs |\n\n## Consuming repositories\n| Repo | How it consumes |\n|------|-----------------|\n| `leadplatform` | Vendors `intelproducts` as a **pinned git submodule**; uses `proposal-generator` |\n| `outreachagent` | Uses `outreach-messaging` consumer skills |\n\n## Consuming ventures\n- Inexis Digital (proposals, outreach); domain packs for cleaning & travel industries; Inbound Lanka (cinnamon-stories pack).\n\n## Inputs\n- Approved knowledge assets from [Knowledge Intelligence](/capabilities/cap-knowledge-intelligence); builder skills.\n\n## Outputs\n- Versioned packs: `proposal`, `website-assessment`, `cinnamon-stories`, `outreach-messaging`; consumer skills.\n\n## Dependencies\n- [Knowledge Intelligence](/capabilities/cap-knowledge-intelligence); [Reusable AI Skills](/capabilities/cap-reusable-ai-skills).\n\n## Capability relationships\n\n```mermaid\ngraph LR\n FIP[Knowledge Intelligence] --> CAP[[Intelligence Productization]]\n SS[Reusable AI Skills] -.underpins.-> CAP\n CAP -->|proposal pack| LEAD[leadplatform]\n CAP -->|outreach pack| OA[outreachagent]\n CAP -->|website-assessment pack| WA[[Website Assessment]]\n```\n\n## Current maturity\n✅ **Operational as a data contract.** Multiple packs published across 4 domains, already consumed by\n`leadplatform` (pinned submodule) and `outreachagent`. *(Source: [intelproducts digest](/repos/intelproducts).)*\n\n## Planned evolution\nNew pack domains as the estate grows; MCP-server access for agent consumers; the **Hermes** loop to feed\nconsumption outcomes back into pack quality.\n\n## Related\n- Repo: [`intelproducts`](/repos/intelproducts) · Platform: [Intelligence Platform](/architecture/intelligence-platform)\n- Registry: [Capability Registry](/capabilities) · [Reuse Map](/architecture/capability-reuse-map)\n"},{"id":"/capabilities/cap-knowledge-intelligence","kind":"page","entityType":"capability","title":"Knowledge Intelligence","route":"/capabilities/cap-knowledge-intelligence","sourcePath":"portal/capabilities/cap-knowledge-intelligence.md","slug":"cap-knowledge-intelligence","frontmatter":{"title":"Knowledge Intelligence","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"cap-knowledge-intelligence","maturity":"early-development","providers":["personalops"],"consumers":["personalops","intelproducts","outreachagent","leadplatform"]},"excerpt":"Turn a multi-venture founder's scattered knowledge into a queryable, AI-accessible, scoped asset library:","headings":[{"depth":2,"text":"Purpose","id":"purpose"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Business value","id":"business-value"},{"depth":2,"text":"Technical responsibilities","id":"technical-responsibilities"},{"depth":2,"text":"Owning repository or repositories","id":"owning-repository-or-repositories"},{"depth":2,"text":"Consuming repositories","id":"consuming-repositories"},{"depth":2,"text":"Consuming ventures","id":"consuming-ventures"},{"depth":2,"text":"Inputs","id":"inputs"},{"depth":2,"text":"Outputs","id":"outputs"},{"depth":2,"text":"Dependencies","id":"dependencies"},{"depth":2,"text":"Capability relationships","id":"capability-relationships"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Planned evolution","id":"planned-evolution"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../repos/personalops.md","../repos/personalops.md","../repos/personalops.md","../repos/intelproducts.md","cap-reusable-ai-skills.md","../repos/personalops.md","../repos/personalops.md","../architecture/intelligence-platform.md","README.md","../architecture/capability-reuse-map.md"],"body":"\n# Knowledge Intelligence — Capability\n\n\n## Purpose\nTurn a multi-venture founder's scattered knowledge into a **queryable, AI-accessible, scoped asset library**:\ncapture → human-approve → structure → retrieve. Provided by the Founder Intelligence Platform (FIP).\n\n\n## At a glance\n| Field | Value |\n|-------|-------|\n| Slug | `cap-knowledge-intelligence` |\n| Maturity | 🔶 early-development |\n| Owning repo(s) | [`personalops`](/repos/personalops) (FIP) |\n| Layer(s) | 2 · Intelligence Platform |\n| Last reviewed | 2026-07-05 |\n\n## Business value\nStops intelligence loss (\"capture first\"), makes cross-venture knowledge reusable, and feeds every downstream\noutput (proposals, outreach, strategy) with retrievable, maturity-gated intelligence.\n\n## Technical responsibilities\n- Own the canonical intelligence store (`knowledge_assets`) — one place, no duplication.\n- Run capture → stage → **mandatory human approval** → structure workflows.\n- Provide scoped retrieval (`search_assets()` RPC) across 5 scope dimensions and 4 maturity states.\n- Render the Intelligence Dashboard. Not responsible for publishing the packs (that's Productization).\n\n## Owning repository or repositories\n| Repo | Role |\n|------|------|\n| [`personalops`](/repos/personalops) | FIP: extraction, knowledge_assets, retrieval, dashboard |\n\n## Consuming repositories\n| Repo | How it consumes |\n|------|-----------------|\n| [`personalops`](/repos/personalops) | The dashboard + agents query assets |\n| [`intelproducts`](/repos/intelproducts) | Packs are synthesised from approved assets |\n| `outreachagent`, `leadplatform` | Consume the *products* derived from this intelligence |\n\n## Consuming ventures\n- Inexis Digital, Inexis Consulting, Inbound Lanka, City Retreats, Cross-Cutting (5 scope dimensions).\n\n## Inputs\n- Knowledge estate (46 markdown docs, ~4,600 lines), manual/voice captures, agent research, legacy KB tables.\n\n## Outputs\n- Scoped, maturity-gated **knowledge assets**; retrieval results via `search_assets()`; dashboard views;\n approved intelligence for pack synthesis.\n\n## Dependencies\n- [Reusable AI Skills](/capabilities/cap-reusable-ai-skills) (builder skills); Supabase (PostgreSQL).\n\n## Capability relationships\n\n```mermaid\ngraph LR\n FIP[personalops/FIP] -->|provides| CAP[[Knowledge Intelligence]]\n SS[Reusable AI Skills] -.underpins.-> CAP\n CAP -->|feeds| IPZ[[Intelligence Productization]]\n EST[Knowledge estate] --> CAP\n```\n\n## Current maturity\n🔶 **Early-development.** Design v1.0 approved; **Phase 0 built** (Supabase schema, seed, TS, harvest scripts,\ndashboard rendering); Phases 1–5 (capture, review, harvest UI, classification, migration, agent ingestion)\n**not started**. *(Source: [personalops digest](/repos/personalops).)*\n\n## Planned evolution\nBuild the capture→retrieve loop; add the **Hermes** learning loop; semantic search + asset relationship graph at scale.\n\n## Related\n- Repo: [`personalops`](/repos/personalops) · Platform: [Intelligence Platform](/architecture/intelligence-platform)\n- Registry: [Capability Registry](/capabilities) · [Reuse Map](/architecture/capability-reuse-map)\n"},{"id":"/capabilities/cap-reproducible-evaluation","kind":"page","entityType":"capability","title":"Reproducible Evaluation","route":"/capabilities/cap-reproducible-evaluation","sourcePath":"portal/capabilities/cap-reproducible-evaluation.md","slug":"cap-reproducible-evaluation","frontmatter":{"title":"Reproducible Evaluation","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"cap-reproducible-evaluation","maturity":"early-development","providers":["website-intelligence-lab"],"consumers":["inexisstudios"]},"excerpt":"Provide an immutable, fully-provenanced experiment & benchmark harness so engines (assessment, migration,","headings":[{"depth":2,"text":"Purpose","id":"purpose"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Business value","id":"business-value"},{"depth":2,"text":"Technical responsibilities","id":"technical-responsibilities"},{"depth":2,"text":"Owning repository or repositories","id":"owning-repository-or-repositories"},{"depth":2,"text":"Consuming repositories","id":"consuming-repositories"},{"depth":2,"text":"Consuming ventures","id":"consuming-ventures"},{"depth":2,"text":"Inputs","id":"inputs"},{"depth":2,"text":"Outputs","id":"outputs"},{"depth":2,"text":"Dependencies","id":"dependencies"},{"depth":2,"text":"Capability relationships","id":"capability-relationships"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Planned evolution","id":"planned-evolution"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../repos/website-intelligence-lab.md","../repos/website-intelligence-lab.md","cap-reusable-ai-skills.md","../repos/website-intelligence-lab.md","../repos/website-intelligence-lab.md","../architecture/intelligence-platform.md","../architecture/principles.md","README.md","../architecture/capability-reuse-map.md"],"body":"\n# Reproducible Evaluation — Capability\n\n\n## Purpose\nProvide an **immutable, fully-provenanced experiment & benchmark harness** so engines (assessment, migration,\n…) can be objectively evaluated and compared across versions — *\"a scientific instrument\"* for capability\nimprovement.\n\n\n## At a glance\n| Field | Value |\n|-------|-------|\n| Slug | `cap-reproducible-evaluation` |\n| Maturity | 🔶 early-development |\n| Owning repo(s) | [`website-intelligence-lab`](/repos/website-intelligence-lab) |\n| Layer(s) | 2 · Intelligence Platform |\n| Last reviewed | 2026-07-05 |\n\n## Business value\nYou cannot improve what you cannot reproduce and compare. This capability makes engine/capability improvement\n**measurable**, protecting quality as the ecosystem scales.\n\n## Technical responsibilities\n- Immutable, provenanced **runs**; quality-tiered **benchmarks**; a **reference catalog** of best-practice targets.\n- A corpus of real/synthetic subject businesses; a technology-agnostic **platform adapter contract**.\n- Not responsible for the engines themselves (external repos) or production hosting.\n\n## Owning repository or repositories\n| Repo | Role |\n|------|------|\n| [`website-intelligence-lab`](/repos/website-intelligence-lab) | The evaluation harness (infra, corpus, runs) |\n\n## Consuming repositories\n| Repo | How it consumes |\n|------|-----------------|\n| `inexisstudios` (Website Assessment Engine) | Engines run *against* the lab, writing immutable runs *(planned — external engines)* |\n\n## Consuming ventures\n- Inexis Digital (indirectly — better-evaluated engines → better client outcomes).\n\n## Inputs\n- Subject businesses + observed website assets; external engine executions; external knowledge (pinned by version).\n\n## Outputs\n- Immutable provenanced runs (Generated assets); benchmark evaluations; run-to-run diffs.\n\n## Dependencies\n- [Reusable AI Skills](/capabilities/cap-reusable-ai-skills); Docker/Caddy/WordPress/Cloudflare infra.\n\n## Capability relationships\n\n```mermaid\ngraph LR\n LAB[website-intelligence-lab] -->|provides| CAP[[Reproducible Evaluation]]\n SS[Reusable AI Skills] -.underpins.-> CAP\n ENG[[Website Assessment engines]] -.evaluated by.-> CAP\n CAP -->|measured improvement| WA[[Website Assessment]]\n```\n\n## Current maturity\n🔶 **Early-development.** Phase 1–2 complete & VPS-validated (infra); Phase 2.5 in progress; core loop\n(adapter, runs, evaluation) pending; crawler not built (observed assets `capture_pending`).\n*(Source: [website-intelligence-lab digest](/repos/website-intelligence-lab).)*\n\n## Planned evolution\nAdapter → runs/provenance → evaluation loop; the Experiments domain; additional platform adapters and engines.\n\n## Related\n- Repo: [`website-intelligence-lab`](/repos/website-intelligence-lab) · Platform: [Intelligence Platform](/architecture/intelligence-platform)\n- Principles: reproducibility & provenance ([Principle 1](/architecture/principles))\n- Registry: [Capability Registry](/capabilities) · [Reuse Map](/architecture/capability-reuse-map)\n"},{"id":"/capabilities/cap-reusable-ai-skills","kind":"page","entityType":"capability","title":"Reusable AI Skills","route":"/capabilities/cap-reusable-ai-skills","sourcePath":"portal/capabilities/cap-reusable-ai-skills.md","slug":"cap-reusable-ai-skills","frontmatter":{"title":"Reusable AI Skills","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"cap-reusable-ai-skills","maturity":"operational","providers":["shared-skills"],"consumers":["portfolio-portal","personalops","website-intelligence-lab","intelproducts","leadplatform","outreachagent"]},"excerpt":"Package domain expertise into modular, invocable Agent Skills so competence is built once and reused","headings":[{"depth":2,"text":"Purpose","id":"purpose"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Business value","id":"business-value"},{"depth":2,"text":"Technical responsibilities","id":"technical-responsibilities"},{"depth":2,"text":"Owning repository or repositories","id":"owning-repository-or-repositories"},{"depth":2,"text":"Consuming repositories","id":"consuming-repositories"},{"depth":2,"text":"Consuming ventures","id":"consuming-ventures"},{"depth":2,"text":"Inputs","id":"inputs"},{"depth":2,"text":"Outputs","id":"outputs"},{"depth":2,"text":"Dependencies","id":"dependencies"},{"depth":2,"text":"Capability relationships","id":"capability-relationships"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Planned evolution","id":"planned-evolution"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../repos/shared-skills.md","../repos/shared-skills.md","../../README.md","../repos/personalops.md","../repos/intelproducts.md","../repos/website-intelligence-lab.md","../repos/shared-skills.md","../repos/shared-skills.md","../ventures/shared-skills.md","README.md","../architecture/capability-reuse-map.md"],"body":"\n# Reusable AI Skills — Capability\n\n\n## Purpose\nPackage domain expertise into modular, invocable **Agent Skills** so competence is built once and reused\neverywhere. This is the ecosystem's foundational capability — *reusable AI competence as infrastructure*.\n\n\n## At a glance\n| Field | Value |\n|-------|-------|\n| Slug | `cap-reusable-ai-skills` |\n| Maturity | ✅ operational |\n| Owning repo(s) | [`shared-skills`](/repos/shared-skills) |\n| Layer(s) | 1 · Shared Skills |\n| Last reviewed | 2026-07-05 |\n\n## Business value\nTurns \"we need someone who knows X\" into \"we have a skill for X.\" Improving one skill upgrades every\ndependent layer — the ecosystem's primary point of **compounding leverage**.\n\n## Technical responsibilities\n- Package expertise as self-contained `SKILL.md` units with progressive disclosure (`references/`, `scripts/`, `assets/`).\n- Route by intent (description-matched), not by name.\n- Provide deterministic tooling (scripts) where prose would be unreliable.\n- Not responsible for: agent runtime/orchestration, hosting, or data storage (higher layers).\n\n## Owning repository or repositories\n| Repo | Role |\n|------|------|\n| [`shared-skills`](/repos/shared-skills) | The 169-skill library across 10 domain clusters |\n\n## Consuming repositories\n| Repo | How it consumes |\n|------|-----------------|\n| [`portfolio-portal`](/readme) | Built with `site-architecture`, `documentation-writer`, `senior-architect` |\n| [`personalops`](/repos/personalops) | Builder skill `intelligence-pack-publisher`, engineering skills |\n| [`intelproducts`](/repos/intelproducts) | Consumer-skill format + builder skills |\n| [`website-intelligence-lab`](/repos/website-intelligence-lab) | Engineering & documentation capability |\n| `leadplatform`, `outreachagent` | Consumer skills (e.g. proposal/outreach generators) |\n\n## Consuming ventures\n- All ventures indirectly — skills underpin every higher layer that serves Inexis Digital, Consulting, Inbound Lanka, City Retreats.\n\n## Inputs\n- User/agent intent; the AI harness that routes to skills.\n\n## Outputs\n- Invoked capability: instructions, deterministic script outputs, templates, `llms.txt`, diagrams, etc.\n\n## Dependencies\n- Anthropic Agent Skills format + Claude Code / Agent SDK harness (platform).\n\n## Capability relationships\n\n```mermaid\ngraph LR\n SS[shared-skills] -->|provides| CAP[[Reusable AI Skills]]\n CAP -.underpins.-> KI[[Knowledge Intelligence]]\n CAP -.underpins.-> IPZ[[Intelligence Productization]]\n CAP -.underpins.-> EVAL[[Reproducible Evaluation]]\n CAP -.underpins.-> WA[[Website Assessment]]\n CAP -.underpins.-> GOV[[Architecture & Docs Governance]]\n```\n\n## Current maturity\n✅ **Operational.** 169 versioned, licensed, multi-author skills in active use (built this portal). Not\n\"production\" (no CI/SLA). *(Source: [shared-skills digest](/repos/shared-skills).)*\n\n## Planned evolution\nSkills taxonomy/index; consolidate duplicated skills; eval/test harness; packaging as a distributable pack.\n\n## Related\n- Repo: [`shared-skills`](/repos/shared-skills) · System: [Shared Skills Layer](/ventures/shared-skills)\n- Registry: [Capability Registry](/capabilities) · [Reuse Map](/architecture/capability-reuse-map)\n"},{"id":"/capabilities/cap-website-assessment","kind":"page","entityType":"capability","title":"Website Assessment Platform","route":"/capabilities/cap-website-assessment","sourcePath":"portal/capabilities/cap-website-assessment.md","slug":"cap-website-assessment","frontmatter":{"title":"Website Assessment Platform","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"cap-website-assessment","maturity":"mixed","providers":["inexisstudios","intelproducts","personalops","website-intelligence-lab"],"consumers":["outreachagent","leadplatform"]},"excerpt":"Assess a service business's website — crawl it, score it against an industry intelligence pack, and","headings":[{"depth":2,"text":"Purpose","id":"purpose"},{"depth":2,"text":"Why this capability exists","id":"why-this-capability-exists"},{"depth":2,"text":"Business problems it solves","id":"business-problems-it-solves"},{"depth":2,"text":"Architectural principles (from source)","id":"architectural-principles-from-source"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"1 · Executive capability overview","id":"1-executive-capability-overview"},{"depth":2,"text":"2 · Container architecture","id":"2-container-architecture"},{"depth":2,"text":"3 · Component architecture (engine internals + rule flow)","id":"3-component-architecture-engine-internals-rule-flow"},{"depth":2,"text":"4 · Runtime information flow (end-to-end, cross-repo)","id":"4-runtime-information-flow-end-to-end-cross-repo"},{"depth":2,"text":"Owning repositories (providers)","id":"owning-repositories-providers"},{"depth":2,"text":"Consuming repositories & ventures","id":"consuming-repositories-ventures"},{"depth":2,"text":"Intelligence products & shared skills that support it","id":"intelligence-products-shared-skills-that-support-it"},{"depth":2,"text":"Inputs / Outputs / Dependencies (summary)","id":"inputs-outputs-dependencies-summary"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Planned evolution","id":"planned-evolution"},{"depth":2,"text":"Known limitations (stated in source)","id":"known-limitations-stated-in-source"},{"depth":2,"text":"Relationship to the wider AI ecosystem","id":"relationship-to-the-wider-ai-ecosystem"},{"depth":2,"text":"Related","id":"related"}],"diagrams":4,"links":["../architecture/principles.md","../repos/intelproducts.md","../repos/personalops.md","../repos/website-intelligence-lab.md","../repos/intelproducts.md","../repos/personalops.md","../repos/website-intelligence-lab.md","cap-intelligence-productization.md","cap-reusable-ai-skills.md","cap-knowledge-intelligence.md","cap-intelligence-productization.md","cap-reproducible-evaluation.md","cap-commercial-opportunity.md","../architecture/capability-reuse-map.md","../portfolio-overview.md","../repos/intelproducts.md","../repos/personalops.md","../repos/website-intelligence-lab.md","cap-intelligence-productization.md","cap-commercial-opportunity.md","cap-reproducible-evaluation.md","../architecture/intelligence-platform.md","../architecture/capability-reuse-map.md","../decisions/0004-capability-architecture.md"],"body":"\n# Website Assessment Platform — Capability\n\n> The **reference capability page.** The Website Assessment Platform is a **cross-repo capability**, not a\n> single repo: intelligence authored in FIP → published as a pack in `intelproducts` → executed by the\n> engine in `inexisstudios` → evaluated against the `website-intelligence-lab` harness → consumed by\n> `outreachagent`/`leadplatform`. This page documents it from executive to implementation level, evidence-first.\n\n\n## Purpose\nAssess a service business's website — crawl it, score it against an **industry intelligence pack**, and\nproduce ranked findings, structured recommendations, and a plain-English report — so Inexis Digital can\ndiagnose gaps and position an *industry-informed website replacement*. Positioning (per `inexisstudios/CLAUDE.md`):\n*\"Preserve what has value. Improve what does not.\"* It is a **sales/diagnostic wedge, not a generic SEO grader.**\n\n## Why this capability exists\nInexis Digital's lead-generation model depends on showing a prospect exactly where their website\nunder-performs for their industry, then offering a replacement. Doing that **consistently and defensibly**\nrequires (a) codified industry intelligence, (b) a deterministic scoring engine, and (c) explanations that\nare grounded in facts, not AI opinion. The capability packages all three so any assessor produces the same\nresult and the output can feed automated outreach.\n\n\n## Business problems it solves\n- **Inconsistent diagnosis** — deterministic rules + scoring mean \"the same site scores the same regardless of assessor\" (`pack-manifest.md`).\n- **Weak sales wedge** — turns a free diagnostic into a positioned offer (website replacement), not a patch.\n- **Manual, unscalable audits** — an async crawl+score API replaces hand audits across 10 verticals.\n- **Cross-venture reuse** — the engine is *domain-agnostic and pack-driven*, so new industries (cleaning, travel) are new packs, not new code.\n\n## Architectural principles (from source)\n- **Rule-based scoring; AI explains only.** *\"Recommendations must not be based on AI opinion. AI may explain… after the rule-based recommendation has been selected\"* (`assessment-engine-plan-v2.md §13`).\n- **Nothing is ever auto-sent** — admin review/approve gate before external sharing (`ready_for_review → approved`).\n- **WordPress is upgrade context, never a quality penalty** (`inexisstudios/CLAUDE.md`).\n- **Domain-agnostic engine + pack-driven** — a generic engine loads a runtime pack; travel/cleaning prove it.\n- **Idempotent + async** — assessments are idempotent by canonical slug; `202 pending` then poll.\n- Embodies ecosystem [Principle 3 (knowledge referenced, never owned)](/architecture/principles) — the engine pins a pack version, never copies it.\n\n## At a glance\n| Field | Value |\n|-------|-------|\n| Slug | `cap-website-assessment` |\n| Maturity | 🔶 mixed — strong spec + working single-repo engine + mostly-mock cross-repo consumption |\n| Owning repo(s) | `inexisstudios` (engine), [`intelproducts`](/repos/intelproducts) (pack), [`personalops`](/repos/personalops) (intelligence author), [`website-intelligence-lab`](/repos/website-intelligence-lab) (harness) |\n| Consuming repo(s) | `outreachagent` ✅, `leadplatform` ⏳ declared |\n| Ventures | Inexis Digital (primary); cleaning & travel (Inbound Lanka) expansion packs |\n| Last reviewed | 2026-07-05 |\n\n---\n\n## 1 · Executive capability overview\n\n```mermaid\ngraph LR\n IN[/\"A website URL
(+ industry vertical)\"/] --> CAP\n CAP[[\"🔎 Website Assessment Platform
Crawl → score against industry pack → findings + recommendations + report\"]] --> OUT[/\"0–100 score · maturity level ·
findings · recommendations · plain-English report\"/]\n OUT --> WEDGE[\"Commercial Opportunity Profile →
outreach · proposal · CRM (Inexis Digital)\"]\n```\n\n**In one sentence:** point it at a service business's website and it returns a defensible, industry-scored\ngap analysis that becomes the wedge to sell a new website.\n\n---\n\n## 2 · Container architecture\n\nThe deployable pieces across the contributing repos.\n\n```mermaid\ngraph TD\n subgraph FIP[\"PersonalOps / FIP ✅ (author)\"]\n SRC[\"Per-vertical conversion intelligence,
scoring priorities, rules (markdown)\"]\n end\n subgraph IPR[\"intelproducts ✅ (contract)\"]\n PACK[(\"website-assessment-pack-v1
15 rules · 6 domains · scoring model · REC-001…015 · maturity 1–5\")]\n RP[(\"rule-packs / runtime-packs
travel · cleaning industry packs\")]\n end\n subgraph ENG[\"inexisstudios ✅ core (the engine)\"]\n API[\"Cloudflare Pages Functions API
POST/GET /api/assessments\"]\n CRAWL[\"crawler-service
Node + Playwright (separate deploy)\"]\n SCORE[\"Scoring engine
src/lib/assessment* · D1 + R2\"]\n REPORT[\"Report UI / contract\"]\n API --> CRAWL --> SCORE --> REPORT\n end\n subgraph LAB[\"website-intelligence-lab 🔶 (harness)\"]\n RUNS[(\"Immutable provenanced Runs / benchmarks\")]\n end\n subgraph CONS[\"Consumers\"]\n OA[\"outreachagent → COP ✅ (mock default)\"]\n LEAD[\"leadplatform ⏳ declared\"]\n end\n\n SRC -->|authored + published| PACK\n PACK -->|pinned pack = scoring truth| SCORE\n RP -.domain packs.-> SCORE\n REPORT -->|/api/assessments/:slug| OA\n PACK -.vendored submodule.-> LEAD\n SCORE -.evaluated against.-> RUNS\n```\n\n---\n\n## 3 · Component architecture (engine internals + rule flow)\n\n```mermaid\ngraph TD\n REQ[\"POST /api/assessments {url, industry?}
idempotent by canonical slug\"] --> SEL[\"Select framework/template for industry\"]\n SEL --> CR[\"Crawler (Playwright): titles, meta, H1s, CTAs, phone,
forms, testimonials, gallery, schema, local/trust,
WordPress detection, screenshots, PageSpeed\"]\n CR -->|raw artifacts + callback| NORM[\"Normalise extracted facts\"]\n NORM --> RULES[\"Rule-based scoring vs pack
15 rules · 6 domains\"]\n RULES --> DOM[\"Domain scores → weighted 0–100
trust 25 · conversion 22 · proof 15 · clarity 15 · mobile 13 · local-seo 10\"]\n DOM --> BAND[\"Score band + Maturity level 1–5\"]\n RULES --> FIND[\"Findings (with evidence)\"]\n FIND --> REC[\"Structured recommendations REC-001…015
(rule-based; recommended offer)\"]\n REC --> AI[\"Optional AI narrative — explains only, no opinion\"]\n AI --> REV{\"Admin review & approve
(nothing auto-sent)\"}\n REV --> RPT[\"Report @ /api/assessments/:slug
(trimmed contract; ?full=1 = PackAssessment)\"]\n\n classDef opt fill:#fff3cd,stroke:#b8860b;\n class AI opt;\n```\n\n**Job status sequence** (`assessment-engine-plan-v2.md §8`): `queued → crawling → scoring →\nrecommendation_draft → ai_draft → ready_for_review → approved → sent`.\n\n---\n\n## 4 · Runtime information flow (end-to-end, cross-repo)\n\n```mermaid\ngraph TD\n A[\"① Prospect/URL enters
(admin UI, or outreachagent enrich)\"] --> B[\"② evaluateCommercialOpportunity() / POST /api/assessments
→ 202 pending, cop_ref/slug\"]\n B --> C[\"③ Async crawl (Playwright) → raw artifacts\"]\n C --> D[\"④ Score against pinned industry pack → domain scores, band, maturity\"]\n D --> E[\"⑤ Findings → structured recommendations → optional AI narrative\"]\n E --> F[\"⑥ Admin review & approve\"]\n F --> G[\"⑦ Report ready — poll GET returns stable contract\"]\n G --> H[\"⑧ outreachagent enriches COP:
evidence → diagnosis → recommendation(action) → solution_blueprint\"]\n H --> I[\"⑨ recommendation.action ∈ replace_website / monitor / manual_review / no_opportunity
→ stage in CRM (nothing auto-sent)\"]\n I --> J[\"⑩ Outcomes / usage signals\"]\n J -. future Hermes learning loop 🔶 .-> D\n```\n\n**What enters:** a website **URL** + optional **industry** vertical (10 AU verticals: plumber, electrician,\nbuilder, carpenter, landscaping, cleaning, physiotherapist, dentist, accountant, mortgage-broker; others fall\nback to \"all industries\" rules). **What leaves:** overall 0–100 score + band + maturity level (1–5),\nper-domain scores, evidence-backed findings, ranked recommendations (recommended offer), a plain-English\n**report**, and downstream a **Commercial Opportunity Profile**.\n\n---\n\n## Owning repositories (providers)\n| Repo | Role | Status |\n|------|------|--------|\n| `inexisstudios` | **The engine** — crawler-service (Node+Playwright) + scoring engine (`src/lib/assessment*`) + Cloudflare Pages Functions API + report UI | ✅ core built (self-tests 40/40; external API shipped); some v2 schema/competitor/public-form ⏳ |\n| [`intelproducts`](/repos/intelproducts) | **The pack** — `website-assessment-pack-v1` (rules, scoring model, recommendation library, maturity model) + travel/cleaning rule/runtime packs | ✅ v1.0 published; feedback/effectiveness loops ⏳ (Hermes) |\n| [`personalops`](/repos/personalops) | **Authors** the source assessment intelligence (per-vertical conversion intelligence, scoring priorities) and publishes packs | ✅ |\n| [`website-intelligence-lab`](/repos/website-intelligence-lab) | **Harness** — declares the `website-assessment` capability; provides Runs/provenance/benchmarks the engine is evaluated against | 🔶 Phase-1 seed; engine external |\n\n## Consuming repositories & ventures\n| Consumer | How it consumes | Status |\n|----------|-----------------|--------|\n| `outreachagent` | `evaluateCommercialOpportunity()` / `/api/assessments` → COP → email/proposal/CRM | ✅ built; **mock default**, live wired but not operationally validated |\n| `leadplatform` | Vendors the pack as a pinned submodule; declared to \"qualify/segment by maturity + opportunity\" | ⏳ declared; no wired assessment consumer skill (proposal pack is live) |\n| **Future** | Proposal Generator, Website Prototype Generator, CRM Automation, OpenClaw/Hermes/MCP | ⏳ planned (per `pack-manifest.md`) |\n\n**Ventures:** **Inexis Digital** (primary — the lead-gen wedge). Expansion packs exist for **cleaning** (WP-53)\nand **travel / Cinnamon Stories — Sri Lanka inbound** (WP-48B; supports the **Inbound Lanka** venture and\nproves the engine is domain-agnostic).\n\n## Intelligence products & shared skills that support it\n- **Intelligence products:** `website-assessment-pack-v1`, travel `rule-packs`/`runtime-packs`, cleaning pack — see [Intelligence Productization](/capabilities/cap-intelligence-productization).\n- **Shared skills:** authored/consumed via [Reusable AI Skills](/capabilities/cap-reusable-ai-skills); `intelproducts/skills` consumer skills (e.g. `commercial-opportunity`, `findings-translator`).\n- **Underpinning capabilities:** [Knowledge Intelligence](/capabilities/cap-knowledge-intelligence) (authoring), [Intelligence Productization](/capabilities/cap-intelligence-productization) (the pack), [Reproducible Evaluation](/capabilities/cap-reproducible-evaluation) (the lab harness), feeding [Commercial Opportunity & Outreach](/capabilities/cap-commercial-opportunity).\n\n## Inputs / Outputs / Dependencies (summary)\n- **Inputs:** website URL + optional industry vertical.\n- **Outputs:** score (0–100) + band + maturity (1–5), domain scores, findings, recommendations, report, COP.\n- **Dependencies:** the pinned pack (scoring truth), Cloudflare (Pages/D1/R2), Playwright crawler, the platform capability interface (`resolveAssessmentPack`, `evaluateCommercialOpportunity`, `getCommercialOpportunity`), COP schema v2 (frozen).\n\n## Current maturity\n🔶 **Mixed (evidence-based):** the **spec is mature** (plan v2 + published immutable pack); the **engine core is\nbuilt and passing self-tests** in `inexisstudios` (40/40; async crawl→score→report live; external API shipped);\n**cross-repo consumption** (`outreachagent`→COP) is built with a frozen schema but **runs in mock mode by\ndefault** and a live end-to-end run is an open checklist item; `leadplatform` assessment consumption is\n**declared but not wired**; the lab is a **Phase-1 seed** harness.\n\n## Planned evolution\nDurable crawler queueing (Phase 3d); competitor benchmarking (plan §11); public assessment form (§7); full\nframework-versioning DB schema (§17; only `assessments` + `crawl_jobs` migrated today); the **Hermes** learning\nloop to replace inference-derived weights with evidence-derived ones; wiring `leadplatform` assessment\nconsumption; operational live-send validation in `outreachagent`.\n\n## Known limitations (stated in source)\n- **Scoring weights are inference-derived, not empirical** — *\"review-gated defaults, not empirical coefficients\"* (`scoring-model.md`).\n- **Learning loops unimplemented** — `assessment-feedback.md`/`recommendation-performance.md`/`rule-effectiveness.md`: *\"v1: documented, not implemented.\"*\n- **Crawler not durable** (in-memory; Phase 3d planned); no synchronous scoring path (poll `202`).\n- **Pack v1 covers 10 AU verticals**; others fall back to generic rules. Health verticals route aggressive claims to human review.\n- **outreachagent live assessment run not operationally validated** (mock default).\n\n## Relationship to the wider AI ecosystem\nThe Website Assessment Platform is the ecosystem's clearest example of **capability composition across\nlayers**: Shared Skills (L1) → Knowledge Intelligence (L2, FIP authors) → Intelligence Productization (L3,\nthe pack) → an engine app (L4, inexisstudios) → Commercial Opportunity (L4, outreachagent) → the Inexis\nDigital venture (L5). It is evaluated by the Reproducible Evaluation harness (L2). See the\n[Capability Reuse Map](/architecture/capability-reuse-map) and [Portfolio Overview](/overview).\n\n## Related\n- Repos: `inexisstudios` *(not yet fully digested)* · [intelproducts](/repos/intelproducts) · [personalops](/repos/personalops) · [website-intelligence-lab](/repos/website-intelligence-lab)\n- Capabilities: [Intelligence Productization](/capabilities/cap-intelligence-productization) · [Commercial Opportunity & Outreach](/capabilities/cap-commercial-opportunity) · [Reproducible Evaluation](/capabilities/cap-reproducible-evaluation)\n- Architecture: [Intelligence Platform](/architecture/intelligence-platform) · [Reuse Map](/architecture/capability-reuse-map) · ADR [0004](/decisions/0004-capability-architecture)\n"},{"id":"/current-state/changelog","kind":"page","entityType":"current-state","title":"Changelog","route":"/current-state/changelog","sourcePath":"portal/current-state/changelog.md","slug":null,"frontmatter":{"title":"Changelog","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Append-only log of notable changes to the portal and the ecosystem it maps. Newest first. Each","headings":[{"depth":2,"text":"2026-07-05 — Phase G1: Portfolio Graph + website foundation (implementation)","id":"2026-07-05-phase-g1-portfolio-graph-website-foundation-implementation"},{"depth":2,"text":"2026-07-05 — Phase F: Architecture Governance & Decision Framework","id":"2026-07-05-phase-f-architecture-governance-decision-framework"},{"depth":2,"text":"2026-07-05 — Phase E: Operating Model & Knowledge Architecture","id":"2026-07-05-phase-e-operating-model-knowledge-architecture"},{"depth":2,"text":"2026-07-05 — Phase D: Ecosystem Architecture Review","id":"2026-07-05-phase-d-ecosystem-architecture-review"},{"depth":2,"text":"2026-07-05 — Phase C: Capability Architecture + Website Assessment","id":"2026-07-05-phase-c-capability-architecture-website-assessment"},{"depth":2,"text":"2026-07-05 — Phase B: Intelligence Platform layer","id":"2026-07-05-phase-b-intelligence-platform-layer"},{"depth":2,"text":"2026-07-05 — Phase B: first real repository","id":"2026-07-05-phase-b-first-real-repository"},{"depth":2,"text":"2026-07-05 — Phase A: initialization","id":"2026-07-05-phase-a-initialization"}],"diagrams":0,"links":["../decisions/0007-portfolio-graph-and-custom-astro.md","../governance/README.md","../governance/capability-decision-framework.md","../governance/capability-decision-matrix.md","../governance/repository-lifecycle.md","../governance/documentation-governance.md","../governance/ai-governance.md","../governance/architecture-review-lifecycle.md","../decisions/0006-architecture-governance-framework.md","../operating-model/README.md","../operating-model/knowledge-asset-lifecycle.md","../operating-model/concept-ownership.md","../operating-model/glossary.md","../operating-model/context-architecture.md","../operating-model/operating-principles.md","../operating-model/ai-collaboration-model.md","../architecture/architecture-review.md","../architecture/architecture-risks.md","../architecture/strategic-opportunities.md","../architecture/architecture-evolution.md","../architecture/capability-reuse-map.md","../decisions/0005-platform-services-and-consolidation.md","../capabilities/README.md","../../templates/capability.template.md","../capabilities/cap-website-assessment.md","../architecture/capability-reuse-map.md","../decisions/0004-capability-architecture.md","../architecture/intelligence-platform.md","../repos/personalops.md","../repos/website-intelligence-lab.md","../repos/intelproducts.md","../ventures/intelligence-platform.md","../architecture/principles.md","../decisions/0003-intelligence-platform-layer-model.md","../repos/shared-skills.md","../ventures/shared-skills.md","../portfolio-overview.md","../decisions/0002-layered-ecosystem-and-digest-standard.md","../architecture/recommendations.md","../decisions/0001-record-architecture-decisions.md"],"body":"\n# Changelog\n\nAppend-only log of notable changes to the portal and the ecosystem it maps. Newest first. Each\nmaterial change (new repo, new venture, new diagram edge, new ADR) gets one line.\n\nFormat: `YYYY-MM-DD — ()`\n\n## 2026-07-05 — Phase G1: Portfolio Graph + website foundation (implementation)\n- Built the **Portfolio Graph** — a build-time, typed runtime model generated from the markdown\n (150 nodes · 739 typed edges: implements/consumes/belongsToLayer/inSystem/usesTechnology/relatesTo/…).\n Zero-dependency generator at `site/scripts/build-graph.mjs`; schema at `site/GRAPH-SCHEMA.md`; exposed at\n `GET /api/graph.json`. Data flow: **Markdown → Portfolio Graph → Website → (future) Intelligence/APIs**.\n- Built the initial **custom Astro** website (`site/`) consuming the graph: layouts, routing (70 pages, each\n generated from the graph), header/sidebar navigation, dark/light theme, client-side theme-aware **Mermaid**,\n **relationship-aware navigation** (typed relationship panels), **entity-aware search**, a platform homepage\n (hero · scale strip · interactive layers · capability & technology summaries · entry points), and Cloudflare\n Pages config. Build validated (`npm run build` → 70 pages, 0 leftover `.md` links).\n- **[ADR 0007](/decisions/0007-portfolio-graph-and-custom-astro)** — Portfolio Graph as canonical runtime\n model; custom Astro (not Starlight).\n- Additive only: all markdown stays in place; `site/` is fully regenerable; generated graph + build artefacts\n are git-ignored. Markdown remains the single source of truth.\n\n## 2026-07-05 — Phase F: Architecture Governance & Decision Framework\n- Established the **[Architecture Governance](/governance)** section (synthesis of existing\n discipline; no new repos): objectives, decision process, ownership, review, approval workflow, quality gates,\n and change-management principles.\n- New pages: **[Capability Decision Framework](/governance/capability-decision-framework)** (decision trees),\n **[Capability Decision Matrix](/governance/capability-decision-matrix)** (question → destination standard),\n **[Repository Lifecycle](/governance/repository-lifecycle)** (proposal → archival),\n **[Documentation Governance](/governance/documentation-governance)** (source of truth per artefact),\n **[AI Governance](/governance/ai-governance)** (authority boundaries + required human approvals), and the\n **[Architecture Review Lifecycle](/governance/architecture-review-lifecycle)** (triggers + checklist).\n- **[ADR 0006](/decisions/0006-architecture-governance-framework)** — adopt the governance framework (a\n portal-governance decision; no ecosystem architecture changed).\n- Distinguished implemented governance (ADRs, phase-gated review, Definition of Done, human approval gates) from\n recommended future governance (annual review cadence, automated pre-review checks, orchestrator sync).\n\n## 2026-07-05 — Phase E: Operating Model & Knowledge Architecture\n- Established the **[Operating Model](/operating-model)** section (synthesis of existing evidence;\n no new repos): the end-to-end **work lifecycle** with human / AI-assisted / automated / future-autonomous\n activity distinctions.\n- New pages: **[Knowledge Asset Lifecycle](/operating-model/knowledge-asset-lifecycle)**,\n **[Concept Ownership Registry](/operating-model/concept-ownership)** (ambiguous ownership flagged),\n authoritative **[Portfolio Glossary](/operating-model/glossary)**,\n **[Context Architecture](/operating-model/context-architecture)**,\n **[Operating Principles](/operating-model/operating-principles)** (split from architecture principles),\n and the **[AI Collaboration Model](/operating-model/ai-collaboration-model)**.\n- **Honest labelling:** flagged concepts with ambiguous ownership (Recommendations, Opportunity Scores, Website\n Assessments, Maturity levels); recorded **\"Domain Briefs\" and \"Review Packages\" as not-evidenced** rather\n than inventing owners. Future autonomy (OpenClaw, Hermes, orchestrator) kept clearly separate from implemented.\n- Documentation only — no architecture modified. Committed Phases A–D as portal v1 (`feat: establish portfolio architecture portal v1`).\n\n## 2026-07-05 — Phase D: Ecosystem Architecture Review\n- Performed a holistic, evidence-first EA review of the ecosystem (no new repos processed). New pages:\n **[Architecture Review](/architecture/architecture-review)** (ownership, duplication, layer boundaries,\n dependency health, reuse, information flow), **[Architecture Risks](/architecture/architecture-risks)**\n (12-item register), **[Strategic Opportunities](/architecture/strategic-opportunities)**, and\n **[Recommended Architecture Evolution](/architecture/architecture-evolution)** (current → recommended → vision).\n- Updated the [Capability Reuse Map](/architecture/capability-reuse-map) with a Phase-D reusability verdict.\n- **[ADR 0005 (proposed)](/decisions/0005-platform-services-and-consolidation)** — introduce a Platform\n Services layer + consolidate reusable services (single scoring source; extract the Assessment Service out of\n the venture repo). Left **proposed** — recommendations only, no architecture modified.\n- Headline findings: reusable capabilities trapped in venture repos (assessment engine in `inexisstudios`);\n duplicated opportunity scoring; unbuilt foundational loops; mostly-mock cross-repo consumption.\n\n## 2026-07-05 — Phase C: Capability Architecture + Website Assessment\n- Introduced **Capability Architecture** — new top-level [`portal/capabilities/`](/capabilities)\n section with a **Capability Registry** (primary nav entry point), a\n [capability template](../../templates/capability.template.md), and **7 capability pages**.\n- Processed the **[Website Assessment Platform](/capabilities/cap-website-assessment)** as the first\n cross-repo platform capability, with 4 architecture views (executive, container, component, runtime).\n Evidence gathered directly from `inexisstudios`, the `intelproducts` pack, `outreachagent`, the lab, and FIP.\n- New **[Capability Reuse Map](/architecture/capability-reuse-map)** (providers, consumers, shared assets,\n intelligence dependencies, reuse opportunities, duplication risks — table + Mermaid).\n- **[ADR 0004](/decisions/0004-capability-architecture)** — introduce Capability Architecture. Added\n **Architecture Principles 11–12** (deterministic rules decide / AI explains; capabilities are first-class).\n- Registered `inexisstudios` (the assessment engine, documented at capability level). Updated Portfolio\n Overview, registry, system dependency map, tech landscape (Playwright, TanStack Start, D1/R2), status\n dashboard, IA/nav, and `llms.txt`.\n- **Honest labelling:** engine core built (self-tests pass) but cross-repo consumption **mostly mock**;\n scoring weights are inference-derived; Hermes learning loops unimplemented; leadplatform assessment\n consumption declared-not-wired; flagged **two parallel opportunity-scoring models** as a duplication risk.\n\n## 2026-07-05 — Phase B: Intelligence Platform layer\n- Processed the **Intelligence Platform** as a *platform*, not a single repo. Evidence gathered directly\n from source repos (with a read-only cross-repo evidence hunt).\n- New platform doc **[Intelligence Platform architecture](/architecture/intelligence-platform)** with\n four views: executive overview, container, component, and runtime information flow.\n- New digests: **[PersonalOps/FIP](/repos/personalops)** (producer + Intelligence Dashboard, layer 2),\n **[website-intelligence-lab](/repos/website-intelligence-lab)** (engine evaluation, layer 2),\n **[intelproducts](/repos/intelproducts)** (published packs, layer 3). New system digest\n **[Intelligence Platform layer](/ventures/intelligence-platform)**.\n- New ecosystem-wide **[Architecture Principles](/architecture/principles)** page (10 principles),\n referenced across the portal.\n- **[ADR 0003](/decisions/0003-intelligence-platform-layer-model)** — model the Intelligence Platform as\n a multi-system layer with a producer/consumer product contract.\n- Registered downstream consumers `leadplatform` + `outreachagent` (layer 4, not yet fully processed).\n- Updated Portfolio Overview (honest maturity, five ventures, evidenced tech landscape), system-of-systems\n diagrams + dependency map, status dashboard, IA/nav, and `llms.txt`.\n- **Honest labelling:** OpenClaw & Hermes recorded as planned/not-built; **\"estate generation\" recorded as\n NOT FOUND** (not a real subsystem); the recommendation engine noted as out-of-scope (`inexisstudios`).\n\n## 2026-07-05 — Phase B: first real repository\n- Processed the **Shared Skills** repository (169 skills) as the first real repo; created the\n reference digest [`repos/shared-skills.md`](/repos/shared-skills) and the\n [`ventures/shared-skills.md`](/ventures/shared-skills) system/layer digest. (Skills Layer doc)\n- **Upgraded the repo-digest template** to the richer standard the flagship digest establishes.\n- Added the top-level **[Portfolio Overview](/overview)** executive briefing (vision,\n layered architecture, information flow, portfolio map, maturity, tech landscape, strategic roadmap).\n- Adopted the **six-layer ecosystem model** and honest realization labelling.\n (see [ADR 0002](/decisions/0002-layered-ecosystem-and-digest-standard))\n- Populated architecture pages with layered diagrams and a **System Dependency Map**; added\n [architecture review recommendations](/architecture/recommendations) (5 duplication flags,\n reusable-capability and missing-doc findings).\n- Updated registry, status dashboard, indexes, IA/navigation, and `llms.txt`.\n- Removed the Phase A `_example-repo` / `_example-venture` placeholders now that real data has landed.\n\n## 2026-07-05 — Phase A: initialization\n- Portal initialized — Phase A scaffold: information architecture, documentation model, templates,\n portal layer (registry, repos, ventures, architecture, current-state, decisions), AI handoff\n files, and the orchestrator skill spec. (see [ADR 0001](/decisions/0001-record-architecture-decisions))\n\n\n"},{"id":"/current-state/roadmap","kind":"page","entityType":"current-state","title":"Roadmap","route":"/current-state/roadmap","sourcePath":"portal/current-state/roadmap.md","slug":null,"frontmatter":{"title":"Roadmap","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Where the portal itself is going. This is about building and maintaining the portal, mapped to the","headings":[{"depth":2,"text":"Phase A — Information architecture & scaffolding ✅ (current)","id":"phase-a-information-architecture-scaffolding-current"},{"depth":2,"text":"Phase B — Populate the map (in progress)","id":"phase-b-populate-the-map-in-progress"},{"depth":2,"text":"Phase C — Public showcase","id":"phase-c-public-showcase"},{"depth":2,"text":"Phase D — Automation & upkeep","id":"phase-d-automation-upkeep"}],"diagrams":0,"links":["../repos/shared-skills.md","../ventures/shared-skills.md","../portfolio-overview.md","../decisions/0002-layered-ecosystem-and-digest-standard.md","../architecture/system-of-systems.md","../architecture/recommendations.md"],"body":"\n# Roadmap\n\nWhere the portal itself is going. This is about building and maintaining the portal, mapped to the\nphased plan (A → D). Venture/product roadmaps live in their own venture digests.\n\n## Phase A — Information architecture & scaffolding ✅ (current)\n- [x] Folder structure, navigation model, IA\n- [x] Documentation model (Diátaxis) + update conventions\n- [x] Page templates (page, repo digest, venture digest, ADR, current-state, diagram)\n- [x] Portal layer: registry, repos, ventures, architecture (Mermaid placeholders), current-state, decisions\n- [x] AI handoff files (Claude & ChatGPT) + CLAUDE.md\n- [x] `portfolio-portal-orchestrator` skill spec (spec only)\n\n## Phase B — Populate the map (in progress)\n- [x] Register first real repo — [Shared Skills](/repos/shared-skills) (digest + registry row)\n- [x] Define first system/layer — [Shared Skills Layer](/ventures/shared-skills)\n- [x] Establish the layered ecosystem model + [Portfolio Overview](/overview) ([ADR 0002](/decisions/0002-layered-ecosystem-and-digest-standard))\n- [x] Fill architecture diagrams with real nodes/edges + [System Dependency Map](/architecture/system-of-systems)\n- [x] First pass at cross-repo duplication flags ([recommendations](/architecture/recommendations))\n- [x] Sync `llms.txt` with the registry\n- [ ] Register repositories for layers 2–6 as they emerge\n- [ ] Stand up the Intelligence Platform layer\n\n## Phase C — Public showcase\n- [ ] Design system / brand tokens finalized (`design/`)\n- [ ] Build the showcase site (target skill: `landing-page-generator` / `premium-frontend-ui`)\n- [ ] Curate showcase narrative from the portal (scale & sophistication story)\n\n## Phase D — Automation & upkeep\n- [ ] Implement the `portfolio-portal-orchestrator` skill per its spec\n- [ ] Automated registry/digest/diagram regeneration and dependency-change detection\n- [ ] Recurring hygiene (orphans, stale `last_reviewed`, dead links) via `knowledge-ops`\n\n> **TODO:** Add target dates once Phase B scope is confirmed.\n"},{"id":"/current-state/status-dashboard","kind":"page","entityType":"current-state","title":"Status Dashboard","route":"/current-state/status-dashboard","sourcePath":"portal/current-state/status-dashboard.md","slug":null,"frontmatter":{"title":"Status Dashboard","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"A dated snapshot of the ecosystem's current state. Keep it terse; move history to the","headings":[{"depth":2,"text":"Snapshot — as of 2026-07-05","id":"snapshot-as-of-2026-07-05"},{"depth":2,"text":"Layer status","id":"layer-status"},{"depth":2,"text":"Repo status","id":"repo-status"},{"depth":2,"text":"Capability status","id":"capability-status"},{"depth":2,"text":"Notes","id":"notes"}],"diagrams":0,"links":["changelog.md","roadmap.md","../governance/README.md","../governance/capability-decision-framework.md","../governance/capability-decision-matrix.md","../governance/repository-lifecycle.md","../governance/documentation-governance.md","../governance/ai-governance.md","../governance/architecture-review-lifecycle.md","../decisions/0006-architecture-governance-framework.md","../operating-model/knowledge-asset-lifecycle.md","../operating-model/concept-ownership.md","../operating-model/glossary.md","../operating-model/context-architecture.md","../operating-model/operating-principles.md","../operating-model/ai-collaboration-model.md","../architecture/architecture-review.md","../architecture/architecture-risks.md","../architecture/strategic-opportunities.md","../architecture/architecture-evolution.md","../decisions/0005-platform-services-and-consolidation.md","../decisions/0004-capability-architecture.md","../architecture/principles.md"],"body":"\n# Status Dashboard\n\nA dated snapshot of the ecosystem's current state. Keep it terse; move history to the\n[changelog](/current-state/changelog) and future plans to the [roadmap](/current-state/roadmap).\n\n## Snapshot — as of 2026-07-05\n\n| Metric | Value |\n|--------|-------|\n| Architecture layers defined | 6 (+ Docs/Governance) |\n| Layers with registered repos | 4 (Shared Skills, Intelligence Platform, Intelligence Products, Applications & Agents) |\n| Systems tracked | 2 (`shared-skills`, `intelligence-platform`) |\n| **Capabilities registered** | **7** (in the Capability Registry) |\n| Repos registered | 7 (4 fully digested + `inexisstudios` at capability level + 2 downstream) |\n| Repos with full digests | 4 (`shared-skills`, `personalops`, `website-intelligence-lab`, `intelproducts`) |\n| Open ADRs (proposed) | 1 (ADR 0005 — Platform Services layer) |\n| Accepted ADRs | 5 |\n| Architecture principles | 12 (ecosystem-wide) |\n| Ecosystem review risks logged | 12 (3 × P1) |\n| Named subsystems flagged not-found | 1 (\"estate generation\") |\n| Concepts flagged ambiguous/unresolved | 4 ambiguous + 2 unresolved (\"Domain Briefs\", \"Review Packages\") |\n| Portal phase | F — architecture governance |\n\n## Layer status\n\n\n| Layer | Systems / repos | Maturity | Notes |\n|-------|-----------------|----------|-------|\n| 1 · Shared Skills | shared-skills | operational | 169 skills; built this portal |\n| 2 · Intelligence Platform | personalops (FIP), website-intelligence-lab | early-development | FIP Phase 0 + design; lab infra VPS-validated |\n| 3 · Intelligence Products | intelproducts | operational (contract) | packs published & consumed |\n| 4 · Applications & Agents | leadplatform, outreachagent | partial | outreachagent operational; leadplatform in-progress; **not yet fully processed** |\n| 5 · Ventures | Inexis Digital · Consulting · Inbound Lanka · City Retreats | vision (in portal) | real businesses; not yet repo-registered |\n| 6 · Customer-facing Solutions | — | vision | — |\n| Docs · Portfolio Portal | portfolio-portal | active-development | Phase B |\n\n\n## Repo status\n\n\n| Repo | System | Layer | Lifecycle | Maturity | Digest | Last reviewed |\n|------|--------|-------|-----------|----------|--------|---------------|\n| shared-skills | shared-skills | Shared Skills | active | operational | ✅ | 2026-07-05 |\n| personalops | intelligence-platform | Intelligence Platform | active | early-development | ✅ | 2026-07-05 |\n| website-intelligence-lab | intelligence-platform | Intelligence Platform | active | early-development | ✅ | 2026-07-05 |\n| intelproducts | intelligence-platform | Intelligence Products | active | operational | ✅ | 2026-07-05 |\n| leadplatform | intelligence consumers | Applications & Agents | active | in-progress | ⏳ not yet processed | 2026-07-05 |\n| outreachagent | intelligence consumers | Applications & Agents | active | operational | ⏳ not yet processed | 2026-07-05 |\n\n\n## Capability status\n\n\n| Capability | Provider(s) | Maturity |\n|------------|-------------|----------|\n| Reusable AI Skills | shared-skills | ✅ operational |\n| Knowledge Intelligence | personalops/FIP | 🔶 early-development |\n| Intelligence Productization | intelproducts | ✅ operational (contract) |\n| Reproducible Evaluation | website-intelligence-lab | 🔶 early-development |\n| Website Assessment | inexisstudios + intelproducts + FIP + lab | 🔶 mixed |\n| Commercial Opportunity & Outreach | outreachagent | 🔶 operational (mock default) |\n| Architecture & Docs Governance | portfolio-portal | ✅ operational |\n\n\n## Notes\n- Phase F milestone: **Architecture Governance** section established — [governance](/governance),\n [decision framework](/governance/capability-decision-framework) + [matrix](/governance/capability-decision-matrix),\n [repository lifecycle](/governance/repository-lifecycle), [documentation governance](/governance/documentation-governance),\n [AI governance](/governance/ai-governance), [review lifecycle](/governance/architecture-review-lifecycle);\n [ADR 0006](/decisions/0006-architecture-governance-framework). Documentation only.\n- Phase E milestone: **Operating Model** section established — work lifecycle, [Knowledge Asset Lifecycle](/operating-model/knowledge-asset-lifecycle),\n [Concept Ownership](/operating-model/concept-ownership), authoritative [Portfolio Glossary](/operating-model/glossary),\n [Context Architecture](/operating-model/context-architecture), [Operating Principles](/operating-model/operating-principles),\n [AI Collaboration Model](/operating-model/ai-collaboration-model). Documentation only.\n- Phase D milestone: **Ecosystem Architecture Review** completed — [review](/architecture/architecture-review),\n [risks](/architecture/architecture-risks), [opportunities](/architecture/strategic-opportunities),\n [evolution](/architecture/architecture-evolution); direction change proposed in\n [ADR 0005](/decisions/0005-platform-services-and-consolidation) (Platform Services layer). No architecture modified.\n- Phase C milestone: **Capability Architecture** introduced (registry + reuse map + 7 capabilities);\n **Website Assessment Platform** processed as the first cross-repo platform capability with 4 architecture\n views ([ADR 0004](/decisions/0004-capability-architecture)).\n- Ecosystem-wide [Architecture Principles](/architecture/principles) now number **12** (added: deterministic\n rules decide / AI explains; capabilities are first-class & repo-independent).\n- Honest labelling: Hermes/OpenClaw = planned; \"estate generation\" = not found; assessment cross-repo\n consumption is **mostly mock**; two parallel opportunity-scoring models flagged in the reuse map.\n- Next: full digests for `inexisstudios`, `leadplatform`, `outreachagent`; resolve the duplicate-scoring reuse risk.\n"},{"id":"/decisions/0001-record-architecture-decisions","kind":"page","entityType":"adr","title":"0001. Record architecture decisions & adopt the markdown-first portal","route":"/decisions/0001-record-architecture-decisions","sourcePath":"portal/decisions/0001-record-architecture-decisions.md","slug":null,"frontmatter":{"title":"0001. Record architecture decisions & adopt the markdown-first portal","type":"reference","status":"accepted","last_reviewed":"2026-07-05","owner":"Azwaan","adr_number":"0001","supersedes":"none","superseded_by":"none"},"excerpt":"Azwaan operates a growing ecosystem of AI ventures and repositories. Repo-level docs explain each","headings":[{"depth":2,"text":"Context","id":"context"},{"depth":2,"text":"Decision","id":"decision"},{"depth":2,"text":"Options considered","id":"options-considered"},{"depth":2,"text":"Consequences","id":"consequences"},{"depth":2,"text":"Compliance / review","id":"compliance-review"}],"diagrams":0,"links":["../../CLAUDE.md","../../docs/update-conventions.md"],"body":"\n# ADR 0001: Record architecture decisions & adopt the markdown-first portal\n\n- **Status:** accepted\n- **Date:** 2026-07-05\n- **Deciders:** Azwaan\n- **Tags:** structure, tooling, cross-repo\n\n## Context\nAzwaan operates a growing ecosystem of AI ventures and repositories. Repo-level docs explain each\nrepo in isolation, but nothing explains the **system of systems** — how repos and ventures combine —\nor communicates the ecosystem's scale to an external audience. Decisions about that structure need a\ndurable, reviewable record from day one.\n\n## Decision\nWe will:\n1. Maintain a dedicated **markdown-first** Portfolio Architecture Portal as the system-of-systems\n layer, structured per the three-layer design principle (repo docs → portal → public showcase).\n2. Record significant structural and cross-repo decisions as **ADRs** in `portal/decisions/`, using\n the Michael Nygard ADR style captured in the ADR template.\n3. Drive all content through canonical **templates** and a **Diátaxis** documentation model, so the\n portal is consistent and later machine-maintainable by the `portfolio-portal-orchestrator` skill.\n\n## Options considered\n| Option | Pros | Cons |\n|--------|------|------|\n| **A (chosen): markdown-first portal + ADRs** | Renders on GitHub; diffable; automation-friendly; low overhead | Manual upkeep until automation exists |\n| B: Build the public website first | Immediate showcase | Premature; no stable content model; hard to maintain |\n| C: Keep only per-repo docs | No new repo to maintain | No system-of-systems view; no showcase path |\n\n## Consequences\n- **Positive:** A single source of truth for the ecosystem map; a clean target for future\n automation; ADRs give decision provenance.\n- **Negative / trade-offs:** Requires discipline to keep digests, registry, and diagrams in sync\n until the orchestrator is built.\n- **Follow-ups / affected pages:** All Phase A scaffolding (this initialization); future ADRs will\n cover naming conventions, venture boundaries, and the orchestrator's generated-region contract.\n\n## Compliance / review\nAdherence is checked via the Definition of Done in [`CLAUDE.md`](/CLAUDE) and the invariants\nin [update conventions](/about/update-conventions). Revisit if the portal outgrows a\nmarkdown-first model.\n"},{"id":"/decisions/0002-layered-ecosystem-and-digest-standard","kind":"page","entityType":"adr","title":"0002. Adopt the layered ecosystem model and the repo-digest standard","route":"/decisions/0002-layered-ecosystem-and-digest-standard","sourcePath":"portal/decisions/0002-layered-ecosystem-and-digest-standard.md","slug":null,"frontmatter":{"title":"0002. Adopt the layered ecosystem model and the repo-digest standard","type":"reference","status":"accepted","last_reviewed":"2026-07-05","owner":"Azwaan","adr_number":"0002","supersedes":"none","superseded_by":"none"},"excerpt":"Phase B processed the first real repository (Shared Skills). Two things","headings":[{"depth":2,"text":"Context","id":"context"},{"depth":2,"text":"Decision","id":"decision"},{"depth":2,"text":"Options considered","id":"options-considered"},{"depth":2,"text":"Consequences","id":"consequences"},{"depth":2,"text":"Compliance / review","id":"compliance-review"}],"diagrams":0,"links":["../repos/shared-skills.md","../portfolio-overview.md","../architecture/system-of-systems.md","../repos/shared-skills.md","../../templates/repo-digest.template.md","../portfolio-overview.md","../architecture/system-of-systems.md","../../templates/repo-digest.template.md","../registry/repo-registry.md","../../docs/information-architecture.md","../../CLAUDE.md","../../docs/update-conventions.md"],"body":"\n# ADR 0002: Adopt the layered ecosystem model and the repo-digest standard\n\n- **Status:** accepted\n- **Date:** 2026-07-05\n- **Deciders:** Azwaan\n- **Tags:** structure, standards, cross-repo\n\n## Context\nPhase B processed the first real repository ([Shared Skills](/repos/shared-skills)). Two things\nneeded to be settled while doing so: (1) how the ecosystem is organized at the top level, and (2) the\ndepth and shape every repository digest must follow. Getting these right now — on the first repo —\nsets the pattern for all future repos and keeps the portal consistent and automatable.\n\n## Decision\nWe will:\n1. **Model the ecosystem as a six-layer architecture** — Shared Skills → Intelligence Platform →\n Intelligence Products → Applications & Agents → Ventures → Customer-facing Solutions — with Shared\n Skills as the foundational, laterally-consumed layer. This model is documented in the\n [Portfolio Overview](/overview) and the [architecture pages](/architecture/system-of-systems).\n2. **Adopt an expanded repo-digest standard** that captures purpose, why-it-exists, business\n capability, technical responsibilities, core concepts, workflows, technologies, modules,\n upstream/downstream dependencies, interfaces, reusable assets, decisions, maturity, roadmap,\n limitations, opportunities, and ecosystem relationship. The\n [Shared Skills digest](/repos/shared-skills) is the reference instance and\n [`templates/repo-digest.template.md`](../../templates/repo-digest.template.md) encodes it.\n3. **Require honest realization labelling** — planned layers/systems are marked Planned/Concept and\n never asserted as built; assumptions and uncertainties are recorded explicitly.\n\n## Options considered\n| Option | Pros | Cons |\n|--------|------|------|\n| **A (chosen): layered model + rich digest standard** | Clear north-star; consistent, automatable digests; honest about maturity | More authoring effort per repo |\n| B: flat repo list, minimal digests | Fast | No system-of-systems story; weak onboarding/showcase value |\n| C: model only realized repos, no layers | Purely factual | Loses the architectural vision the ecosystem is organized around |\n\n## Consequences\n- **Positive:** every future repo digest is comparable and complete; the overview gives new\n engineers/investors the whole picture fast; the structure is a clean target for the orchestrator.\n- **Negative / trade-offs:** richer digests take more effort; the layered model includes planned\n layers that must be kept clearly labelled to avoid over-claiming.\n- **Follow-ups / affected pages:** [portfolio-overview](/overview),\n [architecture](/architecture/system-of-systems), [repo-digest template](../../templates/repo-digest.template.md),\n [registry](/registry/repo-registry), [IA](/about/information-architecture).\n\n## Compliance / review\nEnforced via the Definition of Done in [`CLAUDE.md`](/CLAUDE) and the invariants in\n[update conventions](/about/update-conventions). Revisit if the layer model changes or the\ndigest standard proves too heavy in practice.\n"},{"id":"/decisions/0003-intelligence-platform-layer-model","kind":"page","entityType":"adr","title":"0003. Model the Intelligence Platform as a multi-system layer with a producer/consumer product contract","route":"/decisions/0003-intelligence-platform-layer-model","sourcePath":"portal/decisions/0003-intelligence-platform-layer-model.md","slug":null,"frontmatter":{"title":"0003. Model the Intelligence Platform as a multi-system layer with a producer/consumer product contract","type":"reference","status":"accepted","last_reviewed":"2026-07-05","owner":"Azwaan","adr_number":"0003","supersedes":"none","superseded_by":"none"},"excerpt":"Processing the \"Intelligence Platform\" revealed it is not a single repository. Evidence across the","headings":[{"depth":2,"text":"Context","id":"context"},{"depth":2,"text":"Decision","id":"decision"},{"depth":2,"text":"Options considered","id":"options-considered"},{"depth":2,"text":"Consequences","id":"consequences"},{"depth":2,"text":"Compliance / review","id":"compliance-review"}],"diagrams":0,"links":["../architecture/intelligence-platform.md","../portfolio-overview.md","../architecture/system-of-systems.md","../registry/repo-registry.md","../current-state/status-dashboard.md","../architecture/principles.md","../../CLAUDE.md","../architecture/principles.md"],"body":"\n# ADR 0003: Model the Intelligence Platform as a multi-system layer\n\n- **Status:** accepted\n- **Date:** 2026-07-05\n- **Deciders:** Azwaan\n- **Tags:** structure, layering, intelligence-platform\n\n## Context\nProcessing the \"Intelligence Platform\" revealed it is **not a single repository**. Evidence across the\nsource repos shows three distinct systems and a clear producer/consumer split:\n- **PersonalOps / Founder Intelligence Platform (FIP)** — the knowledge intelligence platform + Intelligence\n Dashboard that *produces* intelligence.\n- **intelproducts** — the *published* intelligence packs, *\"kept separate from the platform that produces\n them.\"*\n- **website-intelligence-lab** — a *sibling, non-dependent* website-engine evaluation platform.\n\nSeveral subsystem names supplied in the request did not map cleanly to reality: **Hermes** and **OpenClaw**\nare planned/not-built, **recommendations** are split (output in `outreachagent`; full engine spec in the\nout-of-scope `inexisstudios`), and **\"estate generation\" does not exist** as a subsystem. A modelling\ndecision was needed to represent this honestly in the portal.\n\n## Decision\nWe will:\n1. Model the **Intelligence Platform as layer 2**, an assembly of sibling systems (`personalops`,\n `website-intelligence-lab`), documented as a *platform* at\n [architecture/intelligence-platform.md](/architecture/intelligence-platform) with four architecture\n views (executive, container, component, runtime).\n2. Model **Intelligence Products (`intelproducts`) as layer 3** — the versioned, immutable output contract\n produced by layer 2 and consumed downstream (**producer/consumer split**).\n3. Record every named subsystem with an explicit **implemented / planned / not-found** status, and never\n document a capability (e.g. \"estate generation\", Hermes) as if it exists.\n4. Register the real **downstream consumers** (`leadplatform`, `outreachagent`) as layer-4 systems, marked\n *not yet fully processed*.\n\n## Options considered\n| Option | Pros | Cons |\n|--------|------|------|\n| **A (chosen): multi-system layer + product contract, honest status** | Matches evidence; separates producer from product; safe for automation | More pages/relationships to maintain |\n| B: one \"Intelligence Platform\" repo digest | Simple | False — conflates three systems; misrepresents architecture |\n| C: document the requested subsystems as-described | Fast | Would fabricate Hermes/OpenClaw/estate-generation as real |\n\n## Consequences\n- **Positive:** the portal reflects the real architecture; downstream consumers and the producer/consumer\n contract are explicit; honest maturity supports planning.\n- **Negative / trade-offs:** more systems and cross-links to keep consistent; layer 2/3 boundary\n (intelproducts) needs a clear note wherever it appears.\n- **Follow-ups / affected pages:** [portfolio-overview](/overview),\n [system-of-systems](/architecture/system-of-systems), [registry](/registry/repo-registry),\n [status dashboard](/current-state/status-dashboard), [Architecture Principles](/architecture/principles),\n and full digests for `leadplatform` / `outreachagent` when they are processed.\n\n## Compliance / review\nEnforced by the Definition of Done in [`CLAUDE.md`](/CLAUDE) and Principle 8 (honest realization\nlabelling) in the [Architecture Principles](/architecture/principles). Revisit if the systems merge or\nthe layer boundaries change.\n"},{"id":"/decisions/0004-capability-architecture","kind":"page","entityType":"adr","title":"0004. Introduce Capability Architecture as a first-class portal dimension","route":"/decisions/0004-capability-architecture","sourcePath":"portal/decisions/0004-capability-architecture.md","slug":null,"frontmatter":{"title":"0004. Introduce Capability Architecture as a first-class portal dimension","type":"reference","status":"accepted","last_reviewed":"2026-07-05","owner":"Azwaan","adr_number":"0004","supersedes":"none","superseded_by":"none"},"excerpt":"The portal documented repositories, systems, and layers — but the ecosystem's real reuse happens at the","headings":[{"depth":2,"text":"Context","id":"context"},{"depth":2,"text":"Decision","id":"decision"},{"depth":2,"text":"Options considered","id":"options-considered"},{"depth":2,"text":"Consequences","id":"consequences"},{"depth":2,"text":"Compliance / review","id":"compliance-review"}],"diagrams":0,"links":["../../templates/capability.template.md","../architecture/capability-reuse-map.md","../capabilities/README.md","../architecture/capability-reuse-map.md","../portfolio-overview.md","../architecture/principles.md","../../CLAUDE.md"],"body":"\n# ADR 0004: Introduce Capability Architecture\n\n- **Status:** accepted\n- **Date:** 2026-07-05\n- **Deciders:** Azwaan\n- **Tags:** structure, capability-architecture\n\n## Context\nThe portal documented repositories, systems, and layers — but the ecosystem's real reuse happens at the\nlevel of **capabilities** that span multiple repositories. The Website Assessment Platform made this obvious:\nit is one capability provided by four repos (`inexisstudios` engine, `intelproducts` pack, `personalops`\nauthoring, `website-intelligence-lab` harness) and consumed by others. Documenting only repos hid both the\ncapability and its reuse/duplication characteristics (e.g. two parallel opportunity-scoring models).\n\n## Decision\nWe will:\n1. Add a first-class **Capability Architecture** section (`portal/capabilities/`) with a **Capability\n Registry** as a primary navigation entry point, and a per-capability page standard\n ([`templates/capability.template.md`](../../templates/capability.template.md)) recording purpose, business\n value, technical responsibilities, owners, consumers, ventures, inputs/outputs, dependencies, maturity, and\n planned evolution — **independent of any single repository**.\n2. Add a **[Capability Reuse Map](/architecture/capability-reuse-map)** documenting providers, consumers,\n shared assets, intelligence dependencies, reuse opportunities, and duplication risks.\n3. Document the **Website Assessment Platform** as a cross-repo capability with four architecture views\n (executive, container, component, runtime), evidence-first, with honest implemented/planned/vision labels.\n4. Keep capabilities and repos cross-linked: capability pages link to repo digests, ventures, architecture,\n and ADRs, and vice versa.\n\n## Options considered\n| Option | Pros | Cons |\n|--------|------|------|\n| **A (chosen): first-class capability architecture + registry + reuse map** | Surfaces reuse & duplication; matches how the ecosystem actually composes | More pages to keep consistent |\n| B: document capabilities inside repo digests only | Less structure | Cross-repo capabilities have no home; reuse invisible |\n| C: capabilities as tags on repos | Cheap | No owner/consumer/lifecycle modelling; no reuse analysis |\n\n## Consequences\n- **Positive:** the portal now answers \"which capabilities exist, who owns/consumes them, and where is reuse\n or duplication\" — shifting it from a repo catalogue to an architectural source of truth.\n- **Negative / trade-offs:** capability ↔ repo ↔ venture links multiply and must stay consistent (the\n orchestrator will eventually reconcile them).\n- **Follow-ups / affected pages:** [Capability Registry](/capabilities),\n [Reuse Map](/architecture/capability-reuse-map), [Portfolio Overview](/overview),\n [Architecture Principles](/architecture/principles) (new principles 11–12), registry, dashboard, IA.\n\n## Compliance / review\nEnforced by the Definition of Done in [`CLAUDE.md`](/CLAUDE) and Principle 8 (honest labelling).\nRevisit when the orchestrator can auto-derive capabilities from source.\n"},{"id":"/decisions/0005-platform-services-and-consolidation","kind":"page","entityType":"adr","title":"0005. Introduce a Platform Services layer and consolidate reusable services (PROPOSED)","route":"/decisions/0005-platform-services-and-consolidation","sourcePath":"portal/decisions/0005-platform-services-and-consolidation.md","slug":null,"frontmatter":{"title":"0005. Introduce a Platform Services layer and consolidate reusable services (PROPOSED)","type":"reference","status":"proposed","last_reviewed":"2026-07-05","owner":"Azwaan","adr_number":"0005","supersedes":"none","superseded_by":"none"},"excerpt":"The review found that the ecosystem's reusable capabilities are architecturally sound but mis-placed:","headings":[{"depth":2,"text":"Context","id":"context"},{"depth":2,"text":"Decision (proposed)","id":"decision-proposed"},{"depth":2,"text":"Options considered","id":"options-considered"},{"depth":2,"text":"Consequences (if adopted)","id":"consequences-if-adopted"},{"depth":2,"text":"Compliance / review","id":"compliance-review"},{"depth":2,"text":"Related","id":"related"}],"diagrams":0,"links":["../architecture/architecture-review.md","0002-layered-ecosystem-and-digest-standard.md","0003-intelligence-platform-layer-model.md","../portfolio-overview.md","../architecture/system-of-systems.md","../capabilities/README.md","../architecture/architecture-review.md","../architecture/architecture-risks.md","../architecture/strategic-opportunities.md","../architecture/architecture-evolution.md"],"body":"\n# ADR 0005: Introduce a Platform Services layer and consolidate reusable services\n\n- **Status:** **proposed** (recommendation from the Phase-D review; not yet adopted — no architecture changed)\n- **Date:** 2026-07-05\n- **Deciders:** Azwaan (pending)\n- **Tags:** structure, layering, consolidation, direction-change\n\n> This ADR records a **recommended architectural direction change** surfaced by the\n> [Phase-D Architecture Review](/architecture/architecture-review). It is intentionally left **proposed**\n> so existing architecture is unchanged. Adopt (or reject) deliberately; if adopted, it refines the layer model\n> established in [ADR 0002](/decisions/0002-layered-ecosystem-and-digest-standard) / [ADR 0003](/decisions/0003-intelligence-platform-layer-model).\n\n## Context\nThe review found that the ecosystem's reusable capabilities are architecturally sound but **mis-placed**:\n- The domain-agnostic **Website Assessment engine lives inside `inexisstudios`** (a venture marketing site), so\n consumers (`outreachagent`) depend on a venture repo for a platform capability (Risk R1).\n- **Opportunity scoring is duplicated** (pack score vs `leadplatform`'s own), and **recommendation logic spans\n three layers** (engine → pack → COP), creating consolidation debt and prospect-facing inconsistency risk (R2).\n- The **Intelligence Platform layer conflates** the knowledge platform (FIP) with the evaluation harness (lab),\n which behaves like a platform service.\n- There is **no home for platform services**, so reusable services are trapped in apps.\n\n## Decision (proposed)\n1. **Introduce a `Platform Services` layer** between Intelligence Products and Ventures/Apps, housing reusable\n services: **Assessment**, **Opportunity/COP evaluation**, **Retrieval**, and **Evaluation (the lab)**.\n2. **Extract the Assessment Service** out of `inexisstudios` so consumers depend on a platform-service contract,\n not a venture repo.\n3. **Establish the intelligence pack as the single source of truth** for rules and scoring; retire\n `leadplatform`'s parallel opportunity score in favour of consuming the assessment/COP; pin the\n engine/COP recommendation mapping to the pack version.\n4. **Tighten the Intelligence Platform layer** to mean knowledge intelligence (FIP); reclassify the lab as a\n Platform Service (evaluation).\n5. **Design the future Hermes feedback as one-way** — publishing a *new immutable pack version*, never mutating\n a consumed pack — to prevent a producer/consumer cycle.\n\n## Options considered\n| Option | Pros | Cons |\n|--------|------|------|\n| **A (recommended): Platform Services layer + single source of truth** | Frees reuse; clean dependency directions; enables commercialisation; fewer future repos | Requires extraction work; touches multiple repos |\n| B: Keep services in apps, document coupling | No refactor | Reuse stays blocked; coupling & duplication compound |\n| C: Merge everything into one platform repo | Simplicity | Loses immutability/contract boundaries; couples ventures |\n\n## Consequences (if adopted)\n- **Positive:** reusable services get a home; consumers depend on contracts not ventures; one defensible score;\n ventures become thin compositions (service + pack); a clean base for automation and commercialisation.\n- **Negative / trade-offs:** extraction and migration effort; the layer model gains a layer (7); consumers must\n be re-pointed from venture APIs to platform-service contracts.\n- **Affected pages (on adoption):** [Portfolio Overview](/overview) layer model,\n [system-of-systems](/architecture/system-of-systems), the [Capability Registry](/capabilities)\n owners, and `inexisstudios`/`outreachagent`/`leadplatform` digests.\n\n## Compliance / review\nAdopt incrementally, one extraction at a time, each with its own follow-up ADR, preserving the evidence-first\nphilosophy (Principle 8). Until adopted, this ADR remains **proposed** and the current architecture stands.\n\n## Related\n- [Architecture Review](/architecture/architecture-review) · [Risks](/architecture/architecture-risks) · [Opportunities](/architecture/strategic-opportunities) · [Evolution](/architecture/architecture-evolution)\n"},{"id":"/decisions/0006-architecture-governance-framework","kind":"page","entityType":"adr","title":"0006. Adopt an Architecture Governance framework","route":"/decisions/0006-architecture-governance-framework","sourcePath":"portal/decisions/0006-architecture-governance-framework.md","slug":null,"frontmatter":{"title":"0006. Adopt an Architecture Governance framework","type":"reference","status":"accepted","last_reviewed":"2026-07-05","owner":"Azwaan","adr_number":"0006","supersedes":"none","superseded_by":"none"},"excerpt":"Through Phases A–E the portal came to describe repositories, capabilities, architecture, the operating model,","headings":[{"depth":2,"text":"Context","id":"context"},{"depth":2,"text":"Decision","id":"decision"},{"depth":2,"text":"Options considered","id":"options-considered"},{"depth":2,"text":"Consequences","id":"consequences"},{"depth":2,"text":"Compliance / review","id":"compliance-review"},{"depth":2,"text":"Related","id":"related"}],"diagrams":0,"links":["0001-record-architecture-decisions.md","0004-capability-architecture.md","../governance/README.md","../governance/capability-decision-framework.md","../governance/capability-decision-matrix.md","../governance/repository-lifecycle.md","../governance/documentation-governance.md","../governance/ai-governance.md","../governance/architecture-review-lifecycle.md","../portfolio-overview.md","../operating-model/README.md","0005-platform-services-and-consolidation.md","../governance/README.md","../operating-model/operating-principles.md","../architecture/principles.md"],"body":"\n# ADR 0006: Adopt an Architecture Governance framework\n\n- **Status:** accepted\n- **Date:** 2026-07-05\n- **Deciders:** Azwaan\n- **Tags:** governance, process, meta\n\n> This ADR governs **how the portal and ecosystem evolve** (process), not the ecosystem's implementation. Like\n> [ADR 0001](/decisions/0001-record-architecture-decisions) and [ADR 0004](/decisions/0004-capability-architecture), it is a\n> portal-governance decision and changes no existing architecture.\n\n## Context\nThrough Phases A–E the portal came to describe repositories, capabilities, architecture, the operating model,\nand an enterprise review. What was missing was an explicit, evidence-based account of **how future work is\ndesigned, reviewed, approved, and incorporated** — so decisions stay consistent as the ecosystem and its AI\nautonomy grow. Governance discipline already existed implicitly (ADRs, the four-part test, phase-gated review,\nthe Definition of Done, human approval gates) but was not consolidated.\n\n## Decision\nAdopt an **Architecture Governance** section (`portal/governance/`) that consolidates and formalises existing\ndiscipline into:\n1. **Governance objectives, decision process, ownership, review, approval, quality gates, and change\n management** ([Architecture Governance](/governance)).\n2. A **[Capability Decision Framework](/governance/capability-decision-framework)** and\n **[Decision Matrix](/governance/capability-decision-matrix)** — the standard reference for *where a\n proposed thing belongs* (including the proposed Platform Services layer).\n3. A **[Repository Lifecycle](/governance/repository-lifecycle)** with governance expectations per stage.\n4. **[Documentation Governance](/governance/documentation-governance)** defining the source of truth for\n every artefact.\n5. **[AI Governance](/governance/ai-governance)** defining AI responsibilities, authority boundaries, and\n required human approvals.\n6. An **[Architecture Review Lifecycle](/governance/architecture-review-lifecycle)** — review triggers and\n a standard checklist.\n\nThe governing rule is unchanged and now explicit: **AI proposes and drafts; humans decide and approve; nothing\ncustomer-facing is auto-sent; deterministic rules decide and AI explains.**\n\n## Options considered\n| Option | Pros | Cons |\n|--------|------|------|\n| **A (chosen): explicit governance section** | Consistent, teachable, scales with AI autonomy; consolidates existing discipline | Another section to keep current |\n| B: leave governance implicit (ADRs + CLAUDE.md only) | No new pages | Ambiguous as autonomy grows; placement decisions ad-hoc |\n| C: heavyweight board/process | Rigorous | Overkill for a single-founder ecosystem; slows delivery |\n\n## Consequences\n- **Positive:** future placement/creation/retirement decisions have a standard; AI participation has explicit\n limits; reviews have triggers and a checklist; the portal governs, not just describes.\n- **Negative / trade-offs:** governance pages must be kept current (a Documentation-Governance responsibility).\n- **Follow-ups / affected pages:** navigation, [Portfolio Overview](/overview), and the\n [Operating Model](/operating-model) gain governance links; the proposed\n [ADR 0005](/decisions/0005-platform-services-and-consolidation) Platform Services layer is referenced by the\n decision framework as a (proposed) destination.\n\n## Compliance / review\nThis framework governs itself: changes to governance follow the same ADR + review process it defines. Revisit at\nthe annual strategic review.\n\n## Related\n- [Architecture Governance](/governance) · [Operating Principles](/operating-model/operating-principles) · [Architecture Principles](/architecture/principles)\n"},{"id":"/decisions/0007-portfolio-graph-and-custom-astro","kind":"page","entityType":"adr","title":"0007. Portfolio Graph as canonical runtime model; custom Astro website","route":"/decisions/0007-portfolio-graph-and-custom-astro","sourcePath":"portal/decisions/0007-portfolio-graph-and-custom-astro.md","slug":null,"frontmatter":{"title":"0007. Portfolio Graph as canonical runtime model; custom Astro website","type":"reference","status":"accepted","last_reviewed":"2026-07-05","owner":"Azwaan","adr_number":"0007","supersedes":"none","superseded_by":"none"},"excerpt":"Phase G1 began implementation: turn the markdown knowledge base into a navigable platform without making the","headings":[{"depth":2,"text":"Context","id":"context"},{"depth":2,"text":"Decision","id":"decision"},{"depth":2,"text":"Options considered","id":"options-considered"},{"depth":2,"text":"Consequences","id":"consequences"},{"depth":2,"text":"Compliance / review","id":"compliance-review"},{"depth":2,"text":"Related","id":"related"}],"diagrams":0,"links":["../../docs/website-implementation-plan.md","../../docs/website-strategy-validation.md","../../site/GRAPH-SCHEMA.md","../../docs/website-implementation-plan.md","../../docs/website-strategy-validation.md","../../site/GRAPH-SCHEMA.md"],"body":"\n# ADR 0007: Portfolio Graph as the canonical runtime model; custom Astro website\n\n- **Status:** accepted\n- **Date:** 2026-07-05\n- **Deciders:** Azwaan\n- **Tags:** implementation, website, portfolio-graph\n\n> Records the Phase G1 implementation decisions. Builds on the approved\n> [website implementation plan](/about/website-implementation-plan) and its\n> [strategy validation](/about/website-strategy-validation).\n\n## Context\nPhase G1 began implementation: turn the markdown knowledge base into a navigable platform without making the\nwebsite a second source of truth. The strategy validation established that the portal is an *architecture\nplatform* (explorer, showcase, working environment), not a documentation site, and recommended a build-time\ncontent graph as the backbone for the site and all future Portfolio Intelligence.\n\n## Decision\n1. **Introduce the Portfolio Graph** — a build-time, typed graph (`nodes` + typed `edges` + `stats`) generated\n from the markdown by a zero-dependency Node script ([`site/scripts/build-graph.mjs`](../../site/scripts/build-graph.mjs);\n schema in [`site/GRAPH-SCHEMA.md`](../../site/GRAPH-SCHEMA.md)). The data flow is strictly\n **Markdown → Portfolio Graph → Website → (future) Intelligence/APIs/Automation**. The website consumes the\n graph, never the markdown filesystem directly. The graph is exposed at `GET /api/graph.json`.\n2. **Build the website in custom Astro (not Starlight)** — per the validated objectives; Astro's primitives\n (content, Pagefind-class search, MDX, islands) are kept while its layout ceiling is removed.\n3. **Entity-aware search over the graph** — a graph-derived search index that understands entities\n (repository, capability, venture, technology, principle, ADR, glossary term), refining Phase G's Pagefind\n default to match the \"search understands entities\" requirement.\n4. **Additive only** — the site lives in `site/`; all markdown stays in place; nothing was moved, renamed, or\n rewritten. Generated graph artefacts are git-ignored (derived, never a source of truth).\n\n## Options considered\n| Option | Pros | Cons |\n|--------|------|------|\n| **A (chosen): Portfolio Graph + custom Astro** | One canonical model for all consumers; platform-grade flexibility; intelligence-ready | Rebuild doc chrome; a build step |\n| B: Astro Starlight reading files | Fast chrome | Website couples to files; constrains explorer/dashboards; two-source-of-truth risk |\n| C: Render markdown directly in the site, no graph | Simplest | No relationship model; no path to search-as-entities or Portfolio Intelligence |\n\n## Consequences\n- **Positive:** relationship-aware navigation, entity search, and a stable `/api/graph.json` contract fall out\n of one model; future intelligence (drift, staleness, health, Hermes) consumes the same graph without\n refactoring; markdown remains authoritative.\n- **Negative / trade-offs:** a build-time generation step; doc chrome is hand-built; the graph must stay in\n sync with content conventions (mitigated: it derives purely from frontmatter + links + diagram node IDs).\n- **Follow-ups:** later phases add the global `/explore` graph, clickable diagram nodes, filterable registries,\n dashboards, and the additive intelligence metadata (`id`, `implementation_status`, `confidence`,\n `review_frequency`, `related`, `source_repos`).\n\n## Compliance / review\nThe invariant — *no architectural knowledge exists only in the website; everything originates in the markdown\nand the generated graph* — is enforced by the data flow and reviewed at each phase gate.\n\n## Related\n- [Website implementation plan](/about/website-implementation-plan) · [Strategy validation](/about/website-strategy-validation) · [Graph schema](../../site/GRAPH-SCHEMA.md)\n"},{"id":"/decisions","kind":"page","entityType":"doc","title":"Decision Log (ADRs)","route":"/decisions","sourcePath":"portal/decisions/README.md","slug":null,"frontmatter":{"title":"Decision Log (ADRs)","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Significant, cross-cutting decisions about the portal and the ecosystem are recorded here as","headings":[{"depth":2,"text":"What warrants an ADR","id":"what-warrants-an-adr"},{"depth":2,"text":"Index","id":"index"}],"diagrams":0,"links":["../../templates/adr.template.md","../../docs/update-conventions.md#recipe-record-a-decision","0001-record-architecture-decisions.md","0002-layered-ecosystem-and-digest-standard.md","0003-intelligence-platform-layer-model.md","0004-capability-architecture.md","0005-platform-services-and-consolidation.md","0006-architecture-governance-framework.md","0007-portfolio-graph-and-custom-astro.md"],"body":"\n# Decision Log — Architecture Decision Records\n\nSignificant, cross-cutting decisions about the portal and the ecosystem are recorded here as\n**ADRs**. ADRs are append-only and immutable once accepted — to change course, add a new ADR that\nsupersedes the old one.\n\n- **Template:** [`templates/adr.template.md`](../../templates/adr.template.md)\n- **How to add one:** [update conventions → record a decision](/about/update-conventions#recipe-record-a-decision)\n- **Numbering:** `NNNN-kebab-title.md`, zero-padded 4-digit, never reused.\n\n## What warrants an ADR\n\n- Portal structure / IA / navigation changes\n- Naming or slug conventions\n- Adding, merging, splitting, or sunsetting a venture\n- Cross-repo standards (shared auth, shared data, shared capability ownership)\n- Tooling and automation decisions (including the orchestrator)\n\n## Index\n\n| # | Title | Status | Date |\n|---|-------|--------|------|\n| [0001](/decisions/0001-record-architecture-decisions) | Record architecture decisions & adopt the markdown-first portal | Accepted | 2026-07-05 |\n| [0002](/decisions/0002-layered-ecosystem-and-digest-standard) | Adopt the layered ecosystem model and the repo-digest standard | Accepted | 2026-07-05 |\n| [0003](/decisions/0003-intelligence-platform-layer-model) | Model the Intelligence Platform as a multi-system layer | Accepted | 2026-07-05 |\n| [0004](/decisions/0004-capability-architecture) | Introduce Capability Architecture as a first-class portal dimension | Accepted | 2026-07-05 |\n| [0005](/decisions/0005-platform-services-and-consolidation) | Introduce a Platform Services layer and consolidate reusable services | **Proposed** | 2026-07-05 |\n| [0006](/decisions/0006-architecture-governance-framework) | Adopt an Architecture Governance framework | Accepted | 2026-07-05 |\n| [0007](/decisions/0007-portfolio-graph-and-custom-astro) | Portfolio Graph as canonical runtime model; custom Astro website | Accepted | 2026-07-05 |\n\n\n"},{"id":"/governance","kind":"page","entityType":"governance","title":"Architecture Governance","route":"/governance","sourcePath":"portal/governance/README.md","slug":null,"frontmatter":{"title":"Architecture Governance","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"How the ecosystem evolves — how future work is designed, reviewed, approved, and incorporated. Where the","headings":[{"depth":2,"text":"1 · Governance objectives","id":"1-governance-objectives"},{"depth":2,"text":"2 · Architectural decision-making process","id":"2-architectural-decision-making-process"},{"depth":2,"text":"3 · Ownership responsibilities","id":"3-ownership-responsibilities"},{"depth":2,"text":"4 · Review process","id":"4-review-process"},{"depth":2,"text":"5 · Approval workflow","id":"5-approval-workflow"},{"depth":2,"text":"6 · Architectural quality gates","id":"6-architectural-quality-gates"},{"depth":2,"text":"7 · Change management principles","id":"7-change-management-principles"},{"depth":2,"text":"Implemented vs recommended governance","id":"implemented-vs-recommended-governance"},{"depth":2,"text":"Related","id":"related"}],"diagrams":2,"links":["../operating-model/README.md","capability-decision-framework.md","capability-decision-matrix.md","repository-lifecycle.md","documentation-governance.md","ai-governance.md","architecture-review-lifecycle.md","../decisions/README.md","../architecture/principles.md","../architecture/capability-reuse-map.md","../operating-model/operating-principles.md","../decisions/0001-record-architecture-decisions.md","../architecture/principles.md","../operating-model/operating-principles.md","../operating-model/concept-ownership.md","../capabilities/cap-architecture-governance.md","architecture-review-lifecycle.md","../architecture/principles.md","../operating-model/operating-principles.md","../architecture/principles.md","capability-decision-matrix.md","../architecture/principles.md","../../CLAUDE.md","../../docs/update-conventions.md","../decisions/0001-record-architecture-decisions.md","../../CLAUDE.md","../decisions/README.md","../operating-model/operating-principles.md","../decisions/0005-platform-services-and-consolidation.md","../architecture/principles.md","../operating-model/operating-principles.md","../decisions/README.md","../decisions/0006-architecture-governance-framework.md"],"body":"\n# Architecture Governance\n\nHow the ecosystem **evolves** — how future work is designed, reviewed, approved, and incorporated. Where the\n[Operating Model](/operating-model) describes *how work flows today*, this section describes *how\nchange is governed*. Evidence-first; implemented governance is separated from recommended future governance.\n\nThis is the **Architecture Governance** section. Its pages:\n\n| Page | What it covers |\n|------|----------------|\n| **This page** | Governance objectives, decision-making, ownership, review, approval, quality gates, change management |\n| [Capability Decision Framework](/governance/capability-decision-framework) | Where a proposed thing belongs (decision trees) |\n| [Capability Decision Matrix](/governance/capability-decision-matrix) | Question → destination reference table |\n| [Repository Lifecycle](/governance/repository-lifecycle) | Proposal → archival, with governance per stage |\n| [Documentation Governance](/governance/documentation-governance) | Source of truth for every architectural artefact |\n| [AI Governance](/governance/ai-governance) | AI responsibilities, authority boundaries, required approvals |\n| [Architecture Review Lifecycle](/governance/architecture-review-lifecycle) | When reviews happen + a standard checklist |\n\n---\n\n## 1 · Governance objectives\n\n1. **Keep the ecosystem coherent** as it grows — one layered model, one capability registry, one glossary.\n2. **Make change deliberate and reversible-on-paper** — every significant decision is an [ADR](/decisions).\n3. **Preserve the evidence-first philosophy** — decisions cite documented evidence; uncertainty is recorded, not invented ([Principle 8](/architecture/principles)).\n4. **Protect reuse** — prevent capabilities being trapped in venture repos and prevent duplication ([Capability Reuse Map](/architecture/capability-reuse-map)).\n5. **Keep humans accountable** — capture, review, approval, and architectural governance stay human ([Operating Principles O1–O2](/operating-model/operating-principles)).\n6. **Keep the portal true** — documentation stays synchronised with reality (today manual; future automated).\n\n## 2 · Architectural decision-making process\n\nGrounded in the ADR practice already in use ([ADR 0001](/decisions/0001-record-architecture-decisions)):\n\n```mermaid\ngraph LR\n P[\"Proposal
(problem + options)\"] --> G{\"Four-part test
(Principle 7)\"}\n G -->|fails| WAIT[Wait / reject — record why]\n G -->|passes| DEC[\"Draft ADR
(status: proposed)\"]\n DEC --> REV[\"Architecture review
(checklist)\"]\n REV -->|not ready| DEC\n REV -->|accepted| ACC[\"ADR accepted
+ update affected pages\"]\n ACC --> INC[\"Incorporated
(digests, diagrams, registries, changelog)\"]\n ACC -.superseded later.-> NEW[New ADR supersedes]\n```\n\n**The four-part test (a hard gate — [Principle 7](/architecture/principles)):** a new concept, service, or\nrepository ships only if it (a) solves a **real, present** problem, (b) **reduces future coupling**, (c) has a\n**clear owner**, and (d) is **explainable in one paragraph**. All four, or it waits.\n\n## 3 · Ownership responsibilities\n\n| Responsibility | Owner | Notes |\n|----------------|-------|-------|\n| Architectural direction & final approval | **Founder (Azwaan)** | Human governance is non-delegable ([O1](/operating-model/operating-principles)) |\n| Recording decisions (ADRs) | Founder + AI assistant (drafts) | AI may draft; human accepts |\n| Capability ownership | Named in the [Concept Ownership Registry](/operating-model/concept-ownership) | Ambiguous ownership is a governance defect to resolve |\n| Repository working rules | Each repo's `CLAUDE.md` | Repo-level source of truth |\n| Portal accuracy | `portfolio-portal` (this repo) | [Architecture & Docs Governance](/capabilities/cap-architecture-governance) capability |\n\n## 4 · Review process\n\nSignificant changes pass an **architecture review** before acceptance (see the full\n[Architecture Review Lifecycle](/governance/architecture-review-lifecycle)). This mirrors the ecosystem's existing\n**phase-gated, reviewable change** discipline ([Principle 10](/architecture/principles); WIL \"each phase\nends with an architecture review and does not continue until reviewed\").\n\n## 5 · Approval workflow\n\n```mermaid\ngraph TD\n A[Change proposed] --> B{Significant?
structural / cross-repo / new repo / new capability}\n B -->|no| C[Normal change — follow update conventions + Definition of Done]\n B -->|yes| D[ADR proposed]\n D --> E[Architecture review vs checklist]\n E --> F{Founder approves?}\n F -->|no| D\n F -->|yes| G[ADR accepted → incorporate → changelog]\n C --> H[Consistency check — no orphans / dead links]\n G --> H\n```\n\n**Non-negotiable approvals (evidenced):** nothing customer-facing is auto-sent ([O2](/operating-model/operating-principles));\nno knowledge asset becomes canonical without founder approval; no ADR is \"accepted\" without human sign-off.\n\n## 6 · Architectural quality gates\n\nA change must pass **all** applicable gates:\n\n| Gate | Requirement | Source |\n|------|-------------|--------|\n| **Four-part test** | Real problem · reduces coupling · clear owner · one-paragraph | [Principle 7](/architecture/principles) |\n| **Correct destination** | Placed in the right layer per the [Decision Matrix](/governance/capability-decision-matrix) | Phase F |\n| **Evidence & honesty** | Claims cite evidence; unknowns labelled | [Principle 8](/architecture/principles) |\n| **Template compliance** | Uses the canonical template; frontmatter correct | [CLAUDE.md](/CLAUDE) |\n| **Consistency** | Registry ⇄ digests ⇄ diagrams agree; no orphans/dead links | [update-conventions](/about/update-conventions) |\n| **Decision recorded** | Significant decisions have an ADR | [ADR 0001](/decisions/0001-record-architecture-decisions) |\n| **Current-state updated** | Changelog + dashboard reflect the change | [CLAUDE.md Definition of Done](/CLAUDE) |\n\n## 7 · Change management principles\n- **Deliberate over fast** — the four-part test and review gate apply to structure.\n- **Immutable decisions** — accepted ADRs are superseded, never edited ([ADR practice](/decisions)).\n- **One-way, versioned change** — evolve by publishing new versions, not mutating consumed artefacts ([O9](/operating-model/operating-principles)).\n- **Reversible on paper** — every direction change is an ADR that a later ADR can supersede.\n- **Preserve the human boundary** — automation may expand within gates; approval stays human.\n\n## Implemented vs recommended governance\n\n| Aspect | Implemented today | Recommended future |\n|--------|-------------------|--------------------|\n| ADR practice | ✅ ADRs 0001–0005; index + template | Auto-linked ADR ↔ affected pages |\n| Phase-gated review | ✅ Portal phases A–F; WIL phase gates | A lightweight standing review board cadence (annual + triggered) |\n| Quality gates | ✅ Definition of Done, update-conventions | Automated checks (link/orphan/pin-freshness) via the orchestrator |\n| Ownership registry | ✅ Concept Ownership Registry | Resolve the flagged ambiguous owners |\n| Portal synchronisation | 🔶 **Manual** | ⏳ `portfolio-portal-orchestrator` auto-sync |\n| Decision framework | ✅ (this phase) | Adopt the Platform Services layer ([ADR 0005, proposed](/decisions/0005-platform-services-and-consolidation)) |\n\n## Related\n- [Architecture Principles](/architecture/principles) · [Operating Principles](/operating-model/operating-principles) · [Decisions (ADRs)](/decisions)\n- Governance decision: [ADR 0006](/decisions/0006-architecture-governance-framework)\n"},{"id":"/governance/ai-governance","kind":"page","entityType":"governance","title":"AI Governance","route":"/governance/ai-governance","sourcePath":"portal/governance/ai-governance.md","slug":null,"frontmatter":{"title":"AI Governance","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"How AI assistants and agents participate in architectural evolution — their responsibilities, authority","headings":[{"depth":2,"text":"Authority model","id":"authority-model"},{"depth":2,"text":"Per-actor governance","id":"per-actor-governance"},{"depth":2,"text":"Approval gates AI cannot bypass (evidenced)","id":"approval-gates-ai-cannot-bypass-evidenced"},{"depth":2,"text":"As autonomy increases","id":"as-autonomy-increases"},{"depth":2,"text":"Governance checklist for introducing a new AI capability","id":"governance-checklist-for-introducing-a-new-ai-capability"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../operating-model/ai-collaboration-model.md","../operating-model/operating-principles.md","../../ai/chatgpt.handoff.md","../operating-model/operating-principles.md","../architecture/principles.md","../architecture/principles.md","README.md#2--architectural-decision-making-process","../decisions/0005-platform-services-and-consolidation.md","../operating-model/ai-collaboration-model.md","../operating-model/operating-principles.md","README.md","../../ai/AI-HANDOFF.md"],"body":"\n# AI Governance\n\nHow AI assistants and agents participate in architectural evolution — their **responsibilities**, **authority\nboundaries**, and the **human approvals** they require. This is the governance counterpart to the\n[AI Collaboration Model](/operating-model/ai-collaboration-model): that page describes *how* AI collaborates;\nthis page sets the *limits*. Implemented behaviour is separated from future vision; the governing rule is\n**AI proposes and drafts; humans decide and approve** ([Operating Principles O1–O3](/operating-model/operating-principles)).\n\n## Authority model\n\n```mermaid\ngraph TD\n subgraph MayDo[\"AI MAY (without approval)\"]\n M1[Draft ADRs / digests / capability pages]\n M2[Generate diagrams & analysis]\n M3[Invoke skills; run deterministic tools]\n M4[Explain findings from structured facts]\n M5[Propose placements via the Decision Matrix]\n end\n subgraph NeedsHuman[\"AI MUST get human approval\"]\n H1[Accept an ADR / change architecture]\n H2[Create / retire / archive a repo]\n H3[Publish a pack version]\n H4[Send anything customer-facing]\n H5[Promote a knowledge asset to canonical]\n H6[Resolve ambiguous capability ownership]\n end\n subgraph Never[\"AI MUST NOT\"]\n N1[Auto-send external communications]\n N2[Mutate a consumed/immutable artefact]\n N3[Fabricate facts to fill gaps]\n N4[Overwrite HUMAN-marked regions]\n end\n```\n\n## Per-actor governance\n\n| Actor | Responsibilities | Authority boundary | Required human approval | Status |\n|-------|------------------|--------------------|-------------------------|--------|\n| **Claude Code** | Build/document repos & portal; draft ADRs; run skills & checks | May draft & generate; may not accept ADRs or change architecture unilaterally | ADR acceptance; repo create/retire; anything external | ✅ Implemented |\n| **ChatGPT** | Draft content that drops into templates; advise | Same as Claude Code; chat-window outputs are proposals | Same | ✅ Implemented (working rules in [chatgpt.handoff](/ai/chatgpt.handoff)) |\n| **Shared Skills** | Provide deterministic tools + method the assistants invoke | Skills execute within an assistant's session; no standing authority | Inherit the invoking assistant's approvals | ✅ Implemented |\n| **In-product AI (assessment narrative)** | Explain rule-based findings/recs from structured facts | **Explain only — never decides**; stricter for regulated verticals | Admin approves the report before sharing | ✅ Implemented |\n| **OpenClaw** | (Future) governed agent consuming services | Must consume via **service contracts**, under one claims/tone guardrail | Human approval for any external action; scoped tool access | ⏳ Planned |\n| **Hermes** | (Future) learning loop re-weighting intelligence | One-way: publishes a **new pack version**; never mutates | Human review before a re-weighted pack is adopted | ⏳ Planned |\n| **portfolio-portal-orchestrator** | (Future) regenerate derived docs | Writes only `` regions; preserves `` | Human review of structural diffs; can't accept ADRs | ⏳ Spec only |\n\n## Approval gates AI cannot bypass (evidenced)\n- **Nothing auto-sent** — external communications require human approval ([O2](/operating-model/operating-principles); outreachagent \"golden rule\").\n- **Human owns canonical intelligence** — no asset becomes canonical without founder approval (FIP \"human approval mandatory\").\n- **Deterministic decides, AI explains** — customer-facing recommendations are rule-based, not AI opinion ([Principle 11](/architecture/principles)).\n- **Evidence-first** — AI records uncertainty; it does not invent to fill gaps ([Principle 8](/architecture/principles)).\n- **Immutable regions & artefacts** — AI preserves `` regions and never mutates an immutable pack/run.\n\n## As autonomy increases\nThe **human approval boundary is preserved** as automation grows: future agents (OpenClaw, Hermes,\norchestrator) expand *within* gates — consuming services, drafting, regenerating — but **capture, review,\napproval, and architectural governance remain human**. New autonomous behaviour is introduced only via an ADR\nthat defines its authority boundary explicitly.\n\n## Governance checklist for introducing a new AI capability\n- [ ] Passes the [four-part test](/governance#2--architectural-decision-making-process)\n- [ ] Consumes **service contracts**, not venture repos ([ADR 0005, proposed](/decisions/0005-platform-services-and-consolidation))\n- [ ] Its authority boundary is written down (may / must-approve / must-not)\n- [ ] Required human approvals are defined and enforced\n- [ ] Outputs are evidence-grounded; uncertainty is surfaced\n- [ ] An ADR records the decision\n\n## Related\n- [AI Collaboration Model](/operating-model/ai-collaboration-model) · [Operating Principles](/operating-model/operating-principles) · [Architecture Governance](/governance)\n- [AI handoff files](/ai/AI-HANDOFF)\n"},{"id":"/governance/architecture-review-lifecycle","kind":"page","entityType":"governance","title":"Architecture Review Lifecycle","route":"/governance/architecture-review-lifecycle","sourcePath":"portal/governance/architecture-review-lifecycle.md","slug":null,"frontmatter":{"title":"Architecture Review Lifecycle","type":"how-to","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"ecosystem's existing \"phase-gated, reviewable change\" discipline (Principle 10;","headings":[{"depth":2,"text":"Review triggers","id":"review-triggers"},{"depth":2,"text":"Review depth","id":"review-depth"},{"depth":2,"text":"Standard review checklist","id":"standard-review-checklist"},{"depth":2,"text":"Cadence","id":"cadence"},{"depth":2,"text":"Implemented vs recommended","id":"implemented-vs-recommended"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../architecture/principles.md","../decisions/0005-platform-services-and-consolidation.md","ai-governance.md","../architecture/architecture-review.md","README.md#2--architectural-decision-making-process","capability-decision-matrix.md","../operating-model/concept-ownership.md","../architecture/system-of-systems.md","../architecture/principles.md","ai-governance.md","../architecture/capability-reuse-map.md","../architecture/architecture-risks.md","../architecture/architecture-review.md","../architecture/architecture-risks.md","../architecture/strategic-opportunities.md","../architecture/architecture-evolution.md","README.md","capability-decision-matrix.md","repository-lifecycle.md","../architecture/architecture-review.md","../../CLAUDE.md"],"body":"\n# Architecture Review Lifecycle\n\n**When** architectural reviews should occur, and a **standard checklist** to run each time. This formalises the\necosystem's existing \"phase-gated, reviewable change\" discipline ([Principle 10](/architecture/principles);\nWIL \"each phase ends with an architecture review and does not continue until reviewed\"). Evidence-first.\n\n## Review triggers\n\n| Trigger | Why review | Depth | Output |\n|---------|-----------|-------|--------|\n| **New repository** | Confirm it's needed & correctly placed (not a pack/skill/feature) | Light–standard | Placement decision + ADR + registry row |\n| **Major capability** | Ownership, reuse, duplication, layer placement | Standard | Capability page + Reuse Map update |\n| **Platform restructuring** | Layer boundaries, dependency directions | Deep | ADR (e.g. [0005](/decisions/0005-platform-services-and-consolidation)) + updated diagrams |\n| **Cross-venture reuse** | Prevent trapped/duplicated capabilities | Standard | Extraction decision; Reuse Map update |\n| **Commercialisation** | External exposure, multi-tenancy, guardrails | Deep | Risk review + ADR |\n| **New/changed AI autonomy** | Authority boundary + approvals | Standard | [AI Governance](/governance/ai-governance) entry + ADR |\n| **Annual strategic review** | Whole-ecosystem health, drift, roadmap | Deep | Refreshed [Architecture Review](/architecture/architecture-review) + risks |\n| **Phase boundary** (portal) | Gate before the next phase | Standard | Phase changelog + review notes |\n\n## Review depth\n\n```mermaid\ngraph LR\n T[Trigger] --> D{Structural or cross-repo?}\n D -->|no| L[Light review
Definition of Done + consistency]\n D -->|yes| S{Changes layer model / dependencies / autonomy?}\n S -->|no| ST[Standard review
checklist + ADR]\n S -->|yes| DP[Deep review
full checklist + risks + evolution impact]\n```\n\n## Standard review checklist\n\nRun this checklist at every review; deep reviews add the starred (★) items.\n\n**Placement & necessity**\n- [ ] Passes the [four-part test](/governance#2--architectural-decision-making-process) (real problem · reduces coupling · clear owner · one-paragraph)\n- [ ] Correct destination per the [Decision Matrix](/governance/capability-decision-matrix)\n- [ ] Not a reusable capability being trapped in a venture repo\n- [ ] Not duplicating an existing concept ([Concept Ownership Registry](/operating-model/concept-ownership))\n\n**Ownership & dependencies**\n- [ ] Single, clear owner named (no diffuse ownership)\n- [ ] Dependencies point at **contracts**, not venture repos; no new circular/hidden dependency\n- [ ] ★ Impact on the [system dependency map](/architecture/system-of-systems) assessed\n\n**Evidence & documentation**\n- [ ] Claims cite evidence; uncertainty recorded ([Principle 8](/architecture/principles))\n- [ ] Uses the canonical template; frontmatter correct\n- [ ] Digest / capability page / diagrams updated; registry row present\n- [ ] `llms.txt` + current-state (changelog, dashboard) updated\n\n**Decision & governance**\n- [ ] Significant decision recorded as an ADR (proposed → accepted with human sign-off)\n- [ ] Required human approvals identified ([AI Governance](/governance/ai-governance))\n- [ ] ★ Reuse & duplication re-checked ([Capability Reuse Map](/architecture/capability-reuse-map))\n- [ ] ★ New risks logged ([Architecture Risks](/architecture/architecture-risks))\n\n**Consistency (Definition of Done)**\n- [ ] Registry ⇄ digests ⇄ diagrams agree; no orphans, no dead links\n- [ ] `last_reviewed` dates current\n\n## Cadence\n- **Triggered reviews** — on any trigger above (event-driven).\n- **Annual strategic review** — a scheduled deep review refreshing the [Architecture Review](/architecture/architecture-review),\n [Risks](/architecture/architecture-risks), [Opportunities](/architecture/strategic-opportunities), and\n [Evolution](/architecture/architecture-evolution) pages.\n- **Portal phase gates** — each phase (A–F and beyond) ends with a review before the next begins.\n\n## Implemented vs recommended\n- ✅ **Implemented:** phase-gated reviews (portal phases A–F; WIL phase gates); the Phase-D ecosystem review; ADR sign-off.\n- ⏳ **Recommended:** a standing **annual review** cadence; **automated pre-review checks** (link/orphan/pin-freshness) via the orchestrator so human review focuses on judgement, not mechanics.\n\n## Related\n- [Architecture Governance](/governance) · [Capability Decision Matrix](/governance/capability-decision-matrix) · [Repository Lifecycle](/governance/repository-lifecycle)\n- [Architecture Review](/architecture/architecture-review) · [CLAUDE.md Definition of Done](/CLAUDE)\n"},{"id":"/governance/capability-decision-framework","kind":"page","entityType":"governance","title":"Capability Decision Framework","route":"/governance/capability-decision-framework","sourcePath":"portal/governance/capability-decision-framework.md","slug":null,"frontmatter":{"title":"Capability Decision Framework","type":"how-to","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"For any proposed feature, service, or repository, this framework decides where it belongs in the layered","headings":[{"depth":2,"text":"Primary decision tree","id":"primary-decision-tree"},{"depth":2,"text":"Secondary checks (after a destination is chosen)","id":"secondary-checks-after-a-destination-is-chosen"},{"depth":3,"text":"\"Is it really reusable, or venture-specific?\" (the trap to avoid)","id":"is-it-really-reusable-or-venture-specific-the-trap-to-avoid"},{"depth":3,"text":"\"Infrastructure?\" resolution","id":"infrastructure-resolution"},{"depth":3,"text":"\"Intelligence vs product?\" resolution","id":"intelligence-vs-product-resolution"},{"depth":2,"text":"Worked examples (evidence-based)","id":"worked-examples-evidence-based"},{"depth":2,"text":"Rules of thumb","id":"rules-of-thumb"},{"depth":2,"text":"Related","id":"related"}],"diagrams":2,"links":["capability-decision-matrix.md","README.md#2--architectural-decision-making-process","../decisions/0005-platform-services-and-consolidation.md","../architecture/architecture-review.md","../decisions/0003-intelligence-platform-layer-model.md","../architecture/principles.md","capability-decision-matrix.md","README.md","repository-lifecycle.md","../architecture/system-of-systems.md","../decisions/0005-platform-services-and-consolidation.md"],"body":"\n# Capability Decision Framework\n\nFor any proposed feature, service, or repository, this framework decides **where it belongs** in the layered\narchitecture — before it is built. Use it with the [Capability Decision Matrix](/governance/capability-decision-matrix)\n(the quick lookup) and the [four-part test](/governance#2--architectural-decision-making-process) (the gate).\n\n> **Destinations** map to the ecosystem layers. **Platform Services** is a **proposed** layer\n> ([ADR 0005](/decisions/0005-platform-services-and-consolidation), status *proposed*); until adopted, its\n> candidates live at the Applications layer but should be built *extraction-ready*.\n\n## Primary decision tree\n\n```mermaid\ngraph TD\n START([Proposed feature / service / repo]) --> GATE{Passes the four-part test?
real problem · reduces coupling · clear owner · one-paragraph}\n GATE -->|no| WAIT[[Wait / reject — record why]]\n GATE -->|yes| Q1{Is it reusable AI behaviour / competence
usable by many repos?}\n Q1 -->|yes| SS[[Shared Skills · L1]]\n Q1 -->|no| Q2{Does it capture / structure / retrieve
knowledge into intelligence?}\n Q2 -->|yes| IP[[Intelligence Platform · L2]]\n Q2 -->|no| Q3{Is it a published, versioned,
immutable artefact consumers pin?}\n Q3 -->|yes| IPR[[Intelligence Products · L3]]\n Q3 -->|no| Q4{Is it a reusable service
used across ≥2 ventures?
assessment · opportunity · retrieval · evaluation}\n Q4 -->|yes| PS[[Platform Services · L4 — proposed]]\n Q4 -->|no| Q5{Is it specific to one venture / an app or agent?}\n Q5 -->|yes| VEN[[Venture / Application · L5]]\n Q5 -->|no| Q6{Is it a customer-touching experience?}\n Q6 -->|yes| CX[[Customer-facing Solution · L6]]\n Q6 -->|no| Q7{Is it documentation / architecture governance?}\n Q7 -->|yes| DOCS[[portfolio-portal · Docs/Governance]]\n Q7 -->|no| Q8{Is it automation of the portal itself?}\n Q8 -->|yes| ORCH[[orchestrator skill · Docs/Automation]]\n Q8 -->|no| REVIEW[[Ambiguous → architecture review]]\n```\n\n## Secondary checks (after a destination is chosen)\n\n### \"Is it really reusable, or venture-specific?\" (the trap to avoid)\nThe review found reusable capabilities **trapped inside venture repos** ([Architecture Review §5](/architecture/architecture-review)).\nApply this test:\n\n```mermaid\ngraph TD\n A{Would a second venture want this unchanged?} -->|yes| B{Is it currently inside a venture repo?}\n A -->|no| VEN[Keep in the venture]\n B -->|yes| EXTRACT[[Extraction candidate → Platform Services]]\n B -->|no| OK[Correctly placed]\n```\n\n### \"Infrastructure?\" resolution\nInfrastructure is **not a separate layer** — it belongs *within* the platform/service it hosts (e.g. the WIL\nDocker/Caddy stack lives in `website-intelligence-lab`). Route infrastructure to the owning platform, not a new repo.\n\n### \"Intelligence vs product?\" resolution\n- If it **captures/structures/retrieves** → Intelligence Platform (L2).\n- If it is the **published, versioned output** → Intelligence Products (L3).\n- The **producer/consumer split** ([ADR 0003](/decisions/0003-intelligence-platform-layer-model)) is the deciding line.\n\n## Worked examples (evidence-based)\n\n| Proposal | Path through the tree | Destination |\n|----------|----------------------|-------------|\n| A new documentation skill | Q1 yes (reusable competence) | Shared Skills (L1) |\n| A new industry assessment **pack** | Q3 yes (published, versioned, immutable) | Intelligence Products (L3) |\n| The **assessment engine** (existing, in `inexisstudios`) | Q4 yes (reusable across ventures) | **Platform Services (L4, proposed)** — currently trapped in a venture (extraction candidate) |\n| A retrieval API over `knowledge_assets` | Q4 yes (reusable service) | Platform Services (L4, proposed) |\n| Inbound Lanka's booking site | Q5 → Q6 yes (customer experience) | Customer-facing (L6) |\n| A new capability page | Q7 yes | portfolio-portal (Docs) |\n\n## Rules of thumb\n- **Default to the lowest reusable layer** a thing can honestly live at — it maximises leverage ([Principle 9](/architecture/principles)).\n- **Never place a reusable service inside a venture repo** — build it extraction-ready.\n- **When ambiguous, review** — don't guess; run an architecture review and record an ADR.\n\n## Related\n- [Capability Decision Matrix](/governance/capability-decision-matrix) · [Architecture Governance](/governance) · [Repository Lifecycle](/governance/repository-lifecycle)\n- [Layered architecture](/architecture/system-of-systems) · [ADR 0005 (proposed)](/decisions/0005-platform-services-and-consolidation)\n"},{"id":"/governance/capability-decision-matrix","kind":"page","entityType":"governance","title":"Capability Decision Matrix","route":"/governance/capability-decision-matrix","sourcePath":"portal/governance/capability-decision-matrix.md","slug":null,"frontmatter":{"title":"Capability Decision Matrix","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The standard reference for architectural placement decisions — the quick lookup companion to the","headings":[{"depth":2,"text":"Question → destination","id":"question-destination"},{"depth":2,"text":"Disambiguation matrix (when two answers seem to apply)","id":"disambiguation-matrix-when-two-answers-seem-to-apply"},{"depth":2,"text":"Placement heuristics (evidence-derived)","id":"placement-heuristics-evidence-derived"},{"depth":2,"text":"How to use this as the standard","id":"how-to-use-this-as-the-standard"},{"depth":2,"text":"Related","id":"related"}],"diagrams":0,"links":["capability-decision-framework.md","../architecture/principles.md","../capabilities/cap-reusable-ai-skills.md","../capabilities/cap-knowledge-intelligence.md","../capabilities/cap-intelligence-productization.md","../decisions/0005-platform-services-and-consolidation.md","../portfolio-overview.md","../portfolio-overview.md","../../skills/portfolio-portal-orchestrator/SPEC.md","../repos/website-intelligence-lab.md","../capabilities/cap-architecture-governance.md","../capabilities/cap-reproducible-evaluation.md","../decisions/0003-intelligence-platform-layer-model.md","../architecture/architecture-review.md#5--capability-reuse","../operating-model/concept-ownership.md","README.md#2--architectural-decision-making-process","architecture-review-lifecycle.md","capability-decision-framework.md","README.md","../operating-model/concept-ownership.md"],"body":"\n# Capability Decision Matrix\n\nThe **standard reference** for architectural placement decisions — the quick lookup companion to the\n[Capability Decision Framework](/governance/capability-decision-framework). Answer the question; get the destination.\nWhen multiple rows apply, choose the **lowest reusable layer** that honestly fits ([Principle 9](/architecture/principles)).\n\n## Question → destination\n\n| # | Architectural question | If **yes** → destination | Layer | Evidence anchor |\n|---|------------------------|--------------------------|-------|-----------------|\n| 1 | Is it **shared AI behaviour / reusable competence** many repos would invoke? | **Shared Skills** | L1 | [cap-reusable-ai-skills](/capabilities/cap-reusable-ai-skills) |\n| 2 | Does it **generate reusable intelligence** (capture → structure → retrieve)? | **Intelligence Platform** | L2 | [cap-knowledge-intelligence](/capabilities/cap-knowledge-intelligence) |\n| 3 | Is it a **published artefact** — versioned, immutable, pinned by consumers? | **Intelligence Products** | L3 | [cap-intelligence-productization](/capabilities/cap-intelligence-productization) |\n| 4 | Is it **reusable across ≥2 ventures** as a service (assessment, opportunity, retrieval, evaluation)? | **Platform Services** *(proposed)* | L4 | [ADR 0005](/decisions/0005-platform-services-and-consolidation) |\n| 5 | Is it **customer/venture-specific** (an app or agent for one venture)? | **Venture / Application** | L5 | [Portfolio Overview](/overview) |\n| 6 | Is it a **customer-facing experience**? | **Customer-facing Solution** | L6 | [Portfolio Overview](/overview) |\n| 7 | Is it **orchestration / automation of the portal**? | **Orchestrator skill** (Docs/Automation) | Docs | [orchestrator SPEC](/skills/portfolio-portal-orchestrator/SPEC) |\n| 8 | Is it **infrastructure**? | **Within the owning platform** (not a new layer) | (host's layer) | [website-intelligence-lab](/repos/website-intelligence-lab) |\n| 9 | Is it **documentation / architecture governance**? | **portfolio-portal** | Docs | [cap-architecture-governance](/capabilities/cap-architecture-governance) |\n| 10 | Is it **evaluation / benchmarking of engines**? | **Platform Services (evaluation)** *(proposed)* / today the lab (L2) | L4/L2 | [cap-reproducible-evaluation](/capabilities/cap-reproducible-evaluation) |\n\n## Disambiguation matrix (when two answers seem to apply)\n\n| Tension | Deciding question | Rule |\n|---------|-------------------|------|\n| Skill vs Platform Service | Is it *knowledge/method* or a *running service with a contract*? | Method → Skill (L1); running contract → Platform Service (L4) |\n| Intelligence Platform vs Intelligence Products | Does it *produce* or *is it the published output*? | Producer → L2; published artefact → L3 (producer/consumer split, [ADR 0003](/decisions/0003-intelligence-platform-layer-model)) |\n| Platform Service vs Venture app | Would a *second venture* use it unchanged? | Yes → Platform Service (L4); no → Venture (L5) |\n| New repo vs feature in existing repo | Does it have a *distinct owner + change-rate + one-paragraph rationale*? | Yes → maybe new repo (pass four-part test); no → extend an existing repo |\n| Pack vs code | Is it *data/intelligence* or *behaviour*? | Data → pack (L3); behaviour → skill (L1) or service (L4) |\n\n## Placement heuristics (evidence-derived)\n- **Domain expansion is a pack, not a repo.** New verticals for an existing capability are new *packs*\n (cleaning, travel proved this) — do **not** spawn a repo per vertical.\n- **Reusable ⇒ platform, not venture.** If a second venture would use it, it is a Platform Service — never bury\n it in a venture repo (the [assessment-engine trap](/architecture/architecture-review#5--capability-reuse)).\n- **One source of truth per concept.** Before placing, check the [Concept Ownership Registry](/operating-model/concept-ownership) —\n if the concept already has an owner, extend it rather than duplicating (avoid the dual-scoring trap).\n- **Infrastructure has no layer of its own.** It belongs to the platform it serves.\n\n## How to use this as the standard\n1. Run the proposal through the [four-part test](/governance#2--architectural-decision-making-process).\n2. Find the first matching question above → destination.\n3. Resolve tensions with the disambiguation matrix.\n4. If still ambiguous → [architecture review](/governance/architecture-review-lifecycle) + an ADR.\n5. Record the placement decision (ADR for anything structural).\n\n## Related\n- [Capability Decision Framework](/governance/capability-decision-framework) · [Architecture Governance](/governance) · [Concept Ownership Registry](/operating-model/concept-ownership)\n"},{"id":"/governance/documentation-governance","kind":"page","entityType":"governance","title":"Documentation Governance","route":"/governance/documentation-governance","sourcePath":"portal/governance/documentation-governance.md","slug":null,"frontmatter":{"title":"Documentation Governance","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"How architectural knowledge is maintained and kept true. It defines the source of truth for every","headings":[{"depth":2,"text":"Source of truth per artefact","id":"source-of-truth-per-artefact"},{"depth":2,"text":"The synchronisation contract","id":"the-synchronisation-contract"},{"depth":2,"text":"Generated vs human-authored regions","id":"generated-vs-human-authored-regions"},{"depth":2,"text":"Portal synchronisation — implemented vs future","id":"portal-synchronisation-implemented-vs-future"},{"depth":2,"text":"Responsibilities","id":"responsibilities"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../../docs/update-conventions.md","../../docs/documentation-model.md","../../CLAUDE.md","../architecture/principles.md","../../docs/update-conventions.md","../../docs/documentation-model.md","../architecture/architecture-risks.md","ai-governance.md","README.md","../../docs/update-conventions.md","../../docs/documentation-model.md","../operating-model/context-architecture.md","ai-governance.md"],"body":"\n# Documentation Governance\n\nHow architectural knowledge is maintained and kept true. It defines the **source of truth** for every\narchitectural artefact and who owns keeping it current. Builds on the existing\n[update-conventions](/about/update-conventions), [documentation model](/about/documentation-model),\nand [CLAUDE.md](/CLAUDE). Evidence-first.\n\n## Source of truth per artefact\n\n| Artefact | Source of truth | Owner | Update frequency | Derives from |\n|----------|-----------------|-------|------------------|--------------|\n| **CLAUDE.md** (repo-level) | Each repo's own `CLAUDE.md` | that repo | with the code | the repo itself |\n| **Repository digest** | `portal/repos/.md` | `portfolio-portal` | when the repo changes materially | the repo's docs (README/CLAUDE/ADRs) |\n| **Capability page** | `portal/capabilities/cap-.md` | Capability Registry | when the capability's contract/maturity changes | repo digests + evidence |\n| **Architecture diagrams** | the embedded Mermaid in `portal/architecture/*` | `portfolio-portal` | per topology change | digests + dependency evidence |\n| **ADRs** | `portal/decisions/NNNN-*.md` | founder (accepts) | append-only; immutable once accepted | the decision itself |\n| **Operating Model** | `portal/operating-model/*` | `portfolio-portal` | per operating change | synthesis of digests/capabilities |\n| **Glossary (authoritative)** | `portal/operating-model/glossary.md` | `portfolio-portal` | when a term is added/standardised | the ecosystem's vocabulary |\n| **Registries** (repo, capability) | `portal/registry/` + `portal/capabilities/README.md` | `portfolio-portal` | when repos/capabilities added | digests + capability pages |\n| **Current state** (dashboard/changelog/roadmap) | `portal/current-state/*` | `portfolio-portal` | every change | all of the above |\n| **Machine index** | `llms.txt` | `portfolio-portal` | with structural changes | the registries |\n\n## The synchronisation contract\n\nThe portal is a **derived view** of many repos. Keeping it true is governed by explicit rules\n([Principle 2 — definition vs derivation](/architecture/principles)):\n\n```mermaid\ngraph LR\n REPO[Repo docs
CLAUDE.md · README · ADRs] -->|digest| DIG[Repo digest]\n DIG -->|roll up| CAP[Capability page]\n DIG --> REG[Registry row]\n CAP --> RUSE[Reuse map]\n DIG & CAP --> ARCH[Architecture diagrams]\n ALL[all pages] --> CS[Current-state + changelog]\n ALL --> LLMS[llms.txt]\n```\n\n**Invariants (must always hold — from [update-conventions](/about/update-conventions)):**\n- Registry ⇄ digests are 1:1 (no orphans, no duplicates).\n- Every diagram node resolves to a real digest/capability.\n- Every venture and its repos link both ways.\n- No dead internal links; no silent blanks (explicit placeholders only).\n- `last_reviewed` on any touched page is current.\n\n## Generated vs human-authored regions\nPages mark ownership so future automation is safe ([documentation model](/about/documentation-model)):\n- `…` — human-owned prose; automation must preserve it.\n- `…` — automation-owned; the orchestrator may overwrite.\n\n## Portal synchronisation — implemented vs future\n| Aspect | Today | Future |\n|--------|-------|--------|\n| Digest/diagram/registry updates | 🔶 **Manual**, per update-conventions | ⏳ `portfolio-portal-orchestrator` generates them from source |\n| Consistency checks (links/orphans) | 🔶 Manual + link-check script | ⏳ Automated in the orchestrator run + CI |\n| `llms.txt` freshness | 🔶 Manual | ⏳ Regenerated from the registry |\n| Pin-freshness (pack versions) | ❌ Not tracked | ⏳ Registry-tracked + CI check ([Risk R5](/architecture/architecture-risks)) |\n\n## Responsibilities\n- **Repos** own their `CLAUDE.md`, `README`, and ADRs (their truth).\n- **The portal** owns the *derived* views (digests, capabilities, diagrams, registries) and must not contradict\n a repo's own docs — if it does, the repo wins and the digest is corrected.\n- **The founder** owns accepting ADRs and resolving ambiguous ownership.\n- **AI assistants** may draft/generate any derived artefact but a **human reviews** structural changes ([AI Governance](/governance/ai-governance)).\n\n## Related\n- [Architecture Governance](/governance) · [update-conventions](/about/update-conventions) · [documentation model](/about/documentation-model)\n- [Context Architecture](/operating-model/context-architecture) · [AI Governance](/governance/ai-governance)\n"},{"id":"/governance/repository-lifecycle","kind":"page","entityType":"governance","title":"Repository Lifecycle","route":"/governance/repository-lifecycle","sourcePath":"portal/governance/repository-lifecycle.md","slug":null,"frontmatter":{"title":"Repository Lifecycle","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The governed lifecycle of a repository, from idea to archival, with governance expectations at each stage.","headings":[{"depth":2,"text":"The lifecycle","id":"the-lifecycle"},{"depth":2,"text":"Stage detail & governance expectations","id":"stage-detail-governance-expectations"},{"depth":2,"text":"Governance gates between stages","id":"governance-gates-between-stages"},{"depth":2,"text":"Rules","id":"rules"},{"depth":2,"text":"Current repositories against this lifecycle (from the registry)","id":"current-repositories-against-this-lifecycle-from-the-registry"},{"depth":2,"text":"Related","id":"related"}],"diagrams":2,"links":["../registry/repo-registry.md","../decisions/0002-layered-ecosystem-and-digest-standard.md","README.md#2--architectural-decision-making-process","capability-decision-matrix.md","../architecture/principles.md","../architecture/system-of-systems.md","architecture-review-lifecycle.md","../../docs/update-conventions.md","../architecture/principles.md","../current-state/status-dashboard.md","README.md","capability-decision-matrix.md","architecture-review-lifecycle.md","../registry/repo-registry.md","../../docs/update-conventions.md"],"body":"\n# Repository Lifecycle\n\nThe governed lifecycle of a repository, from idea to archival, with **governance expectations at each stage**.\nThis aligns the `lifecycle` and `maturity` fields already used in the [Repo Registry](/registry/repo-registry)\nwith an explicit stage model. Evidence-first; the maturity language matches the digests\n([ADR 0002](/decisions/0002-layered-ecosystem-and-digest-standard)).\n\n## The lifecycle\n\n```mermaid\ngraph LR\n P[Proposal] --> E[Evaluation]\n E -->|approved| C[Creation]\n E -->|rejected| X[Not created — recorded]\n C --> AD[Active Development]\n AD --> OP[Operational]\n OP --> MA[Maintenance]\n MA --> RE[Retirement]\n RE --> AR[Archival]\n OP -.superseded.-> RE\n```\n\n## Stage detail & governance expectations\n\n| Stage | Meaning | Registry `lifecycle` / `maturity` | Governance expectations |\n|-------|---------|-----------------------------------|-------------------------|\n| **Proposal** | A repo is suggested to fill a need | `idea` / `concept` | Pass the [four-part test](/governance#2--architectural-decision-making-process) and the [Decision Matrix](/governance/capability-decision-matrix); confirm it isn't a pack/skill/feature instead |\n| **Evaluation** | Placement & necessity reviewed | `idea` / `concept` | Architecture review; ADR if structural; confirm it won't trap a reusable capability in a venture |\n| **Creation** | Repo scaffolded | `prototype` / `early-development` | Root `README` + `CLAUDE.md` from day one; register a repo row + (if relevant) a capability page |\n| **Active Development** | Being built in phases | `active` / `active-development` | Phase-gated review ([Principle 10](/architecture/principles)); digest kept current; ADRs for decisions |\n| **Operational** | In real use | `active` / `operational` | Digest `last_reviewed` current; dependencies surfaced in the [dependency map](/architecture/system-of-systems); reuse/duplication tracked |\n| **Maintenance** | Stable, low change | `maintenance` / `operational` | Periodic review (annual, see [Review Lifecycle](/governance/architecture-review-lifecycle)); pin-freshness for any consumed packs |\n| **Retirement** | Being wound down / superseded | `deprecated` | ADR recording why + successor; consumers migrated off; dependency map updated |\n| **Archival** | Frozen, read-only | `archived` | Digest marked archived (not deleted); links preserved; provenance retained |\n\n## Governance gates between stages\n\n```mermaid\ngraph TD\n P[Proposal] -->|four-part test + Decision Matrix| E[Evaluation]\n E -->|architecture review + ADR if structural| C[Creation]\n C -->|README + CLAUDE.md + registry row| AD[Active Development]\n AD -->|phase reviews + current digest| OP[Operational]\n OP -->|dependencies surfaced + reuse checked| MA[Maintenance]\n MA -->|annual review| RE[Retirement]\n RE -->|migration + successor ADR| AR[Archival]\n```\n\n## Rules\n- **No repo without root docs.** A created repo must have `README` + `CLAUDE.md` (repo-level source of truth).\n- **No repo without a registry row.** Registration is part of creation (no orphan repos — [update-conventions](/about/update-conventions)).\n- **Retirement is a decision, not a deletion.** Record an ADR; migrate consumers first; keep the archived digest.\n- **Stage is state, not location** — advancing a repo is a field/maturity change plus evidence, never a silent move ([Principle 4](/architecture/principles)).\n- **Prefer not creating a repo.** Domain expansion → a pack; shared behaviour → a skill; reusable service → Platform Services. A new repo needs a distinct owner + change-rate + one-paragraph rationale.\n\n## Current repositories against this lifecycle (from the registry)\n\n| Repo | Stage (per registry) |\n|------|----------------------|\n| `shared-skills` | Operational |\n| `personalops` (FIP) | Active Development (early-development) |\n| `website-intelligence-lab` | Active Development (early-development) |\n| `intelproducts` | Operational (contract) |\n| `inexisstudios` | Active Development |\n| `leadplatform` | Active Development (in-progress) |\n| `outreachagent` | Operational |\n| `portfolio-portal` | Active Development |\n\n> `leadplatform`, `outreachagent`, and `inexisstudios` are registered but not yet fully digested — a\n> governance to-do recorded in the [status dashboard](/current-state/status-dashboard).\n\n## Related\n- [Architecture Governance](/governance) · [Capability Decision Matrix](/governance/capability-decision-matrix) · [Architecture Review Lifecycle](/governance/architecture-review-lifecycle)\n- [Repo Registry](/registry/repo-registry) · [update-conventions](/about/update-conventions)\n"},{"id":"/","kind":"page","entityType":"home","title":"Portal Home","route":"/","sourcePath":"portal/index.md","slug":null,"frontmatter":{"title":"Portal Home","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The entry point to the system-of-systems layer: how Azwaan's repos, ventures, and services","headings":[{"depth":2,"text":"Navigate","id":"navigate"},{"depth":2,"text":"The map at a glance","id":"the-map-at-a-glance"},{"depth":2,"text":"Current scope","id":"current-scope"}],"diagrams":1,"links":["portfolio-overview.md","../README.md","../CLAUDE.md","portfolio-overview.md","capabilities/README.md","operating-model/README.md","governance/README.md","registry/repo-registry.md","ventures/README.md","repos/README.md","architecture/system-of-systems.md","architecture/intelligence-platform.md","architecture/principles.md","architecture/architecture-review.md","architecture/architecture-risks.md","architecture/strategic-opportunities.md","architecture/architecture-evolution.md","current-state/status-dashboard.md","decisions/README.md","capabilities/README.md","portfolio-overview.md","architecture/intelligence-platform.md"],"body":"\n# Portfolio Portal — System of Systems\n\nThe entry point to the **system-of-systems** layer: how Azwaan's repos, ventures, and services\ncombine. New here? Start with the **[Portfolio Overview](/overview)** executive briefing.\nFor what this repo is and how to maintain it, see the root [README](/readme) and\n[CLAUDE.md](/CLAUDE).\n\n## Navigate\n\n| Go to | For |\n|-------|-----|\n| [**Portfolio Overview**](/overview) | **Executive briefing — read this first** |\n| [**Capability Registry**](/capabilities) | **Reusable capabilities — who owns & consumes what** |\n| [**Operating Model**](/operating-model) | **How the ecosystem functions today** |\n| [**Architecture Governance**](/governance) | **How the ecosystem evolves — decisions, reviews, lifecycle** |\n| [Repo registry](/registry/repo-registry) | The canonical index of every repository |\n| [Ventures / Systems](/ventures) | System / layer digests |\n| [Repos](/repos) | Per-repo digests |\n| [Architecture](/architecture/system-of-systems) | System-of-systems diagrams & dependency map |\n| [Intelligence Platform](/architecture/intelligence-platform) | Platform architecture (executive → runtime) |\n| [Architecture Principles](/architecture/principles) | Ecosystem-wide design principles |\n| [**Architecture Review**](/architecture/architecture-review) | **Phase-D ecosystem review** (ownership, duplication, boundaries) |\n| [Architecture Risks](/architecture/architecture-risks) | Risk register |\n| [Strategic Opportunities](/architecture/strategic-opportunities) | Simplification, automation, reuse, commercialisation |\n| [Architecture Evolution](/architecture/architecture-evolution) | Current → recommended → vision |\n| [Current state](/current-state/status-dashboard) | Live status, changelog, roadmap |\n| [Decisions](/decisions) | Architecture Decision Records |\n\n## The map at a glance\n\n```mermaid\ngraph TD\n Portal[Portfolio Portal] --> Overview[Portfolio Overview]\n Portal --> Ventures[Systems / Layers]\n Portal --> Repos[Repos]\n Portal --> Arch[Architecture]\n Portal --> State[Current State]\n Portal --> Dec[Decisions]\n\n Ventures -->|group| Repos\n Repos -->|indexed by| Registry[Repo Registry]\n Arch -->|draws| Repos\n Dec -->|govern| Arch\n\n Repos --> SS[shared-skills · L1]\n Repos --> IP[personalops · website-intelligence-lab · L2]\n Repos --> PR[intelproducts · L3]\n Ventures --> SSL[Shared Skills Layer]\n Ventures --> IPL[Intelligence Platform Layer]\n IPL --> IP\n```\n\n## Current scope\n\n\n- Architecture layers defined: **6** (+ Docs/Governance)\n- Capabilities registered: **7** (see the [Capability Registry](/capabilities))\n- Systems tracked: **2** (`shared-skills`, `intelligence-platform`)\n- Repos registered: **7** — 4 fully digested + `inexisstudios` (capability level) + 2 downstream\n- Architecture principles: **12** (ecosystem-wide)\n\n\n> Layers 1–4 have registered repositories (mixed maturity); layers 5–6 are vision. See the honest\n> realization labelling in the [Portfolio Overview](/overview) and the\n> [Intelligence Platform architecture](/architecture/intelligence-platform).\n"},{"id":"/operating-model","kind":"page","entityType":"operating-model","title":"Portfolio Operating Model","route":"/operating-model","sourcePath":"portal/operating-model/README.md","slug":null,"frontmatter":{"title":"Portfolio Operating Model","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"How the ecosystem operates — the complete lifecycle of work, from information entering the ecosystem to","headings":[{"depth":2,"text":"The operating lifecycle","id":"the-operating-lifecycle"},{"depth":3,"text":"Stage-by-stage (evidence-based)","id":"stage-by-stage-evidence-based"},{"depth":2,"text":"Activity types across the lifecycle","id":"activity-types-across-the-lifecycle"},{"depth":2,"text":"How the operating model governs itself","id":"how-the-operating-model-governs-itself"},{"depth":2,"text":"Related","id":"related"}],"diagrams":2,"links":["../architecture/system-of-systems.md","../capabilities/README.md","knowledge-asset-lifecycle.md","concept-ownership.md","glossary.md","context-architecture.md","operating-principles.md","ai-collaboration-model.md","knowledge-asset-lifecycle.md","../capabilities/cap-knowledge-intelligence.md","../capabilities/cap-website-assessment.md","../repos/personalops.md","../repos/personalops.md","../capabilities/cap-intelligence-productization.md","../capabilities/cap-website-assessment.md","../capabilities/cap-commercial-opportunity.md","../architecture/intelligence-platform.md","../architecture/principles.md","operating-principles.md","../governance/README.md","../decisions/README.md","../architecture/principles.md","../architecture/principles.md","../architecture/capability-reuse-map.md","../architecture/architecture-risks.md","knowledge-asset-lifecycle.md","concept-ownership.md","context-architecture.md","operating-principles.md","ai-collaboration-model.md","../portfolio-overview.md","../architecture/intelligence-platform.md#4--runtime-information-flow"],"body":"\n# Portfolio Operating Model\n\nHow the ecosystem **operates** — the complete lifecycle of work, from information entering the ecosystem to\ncustomer outcomes and feedback. Where the [architecture](/architecture/system-of-systems) pages describe\n*what exists* and the [capabilities](/capabilities) describe *what is reusable*, this section\ndescribes *how the ecosystem functions, evolves, and governs itself*. Evidence-first; uncertainty recorded.\n\nThis is the **Operating Model** section. Its pages:\n\n| Page | What it covers |\n|------|----------------|\n| **This page** | The end-to-end operating lifecycle of work |\n| [Knowledge Asset Lifecycle](/operating-model/knowledge-asset-lifecycle) | Raw sources → … → commercial outcomes, per stage |\n| [Concept Ownership Registry](/operating-model/concept-ownership) | Who owns each architectural concept; ambiguous ownership flagged |\n| [Portfolio Glossary](/operating-model/glossary) | The authoritative, de-duplicated vocabulary |\n| [Context Architecture](/operating-model/context-architecture) | Repository → capability → platform → portfolio → business context |\n| [Operating Principles](/operating-model/operating-principles) | How work is performed (vs how systems are structured) |\n| [AI Collaboration Model](/operating-model/ai-collaboration-model) | How humans, AI assistants, orchestration & future agents collaborate |\n\n---\n\n## The operating lifecycle\n\nWork flows through seven stages. This mirrors the [Knowledge Asset Lifecycle](/operating-model/knowledge-asset-lifecycle)\nbut focuses on *activity* — who or what does the work at each step.\n\n```mermaid\ngraph LR\n A[\"① Information enters
knowledge estate · captures · signals · website URLs\"] --> B[\"② Processed
harvest/extract → stage → structure\"]\n B --> C[\"③ Intelligence created
scoped, maturity-gated knowledge assets\"]\n C --> D[\"④ Products
versioned immutable packs\"]\n D --> E[\"⑤ Ventures consume
apply packs · assess · qualify\"]\n E --> F[\"⑥ Customer outcomes
reports · proposals · outreach · journeys\"]\n F --> G[\"⑦ Feedback
outcomes → (future) re-weight intelligence\"]\n G -. one-way, new pack version .-> D\n```\n\n### Stage-by-stage (evidence-based)\n\n| Stage | What happens | Primary systems | Evidence |\n|-------|--------------|-----------------|----------|\n| ① Enters | Founder knowledge, ad-hoc captures (voice/articles/agent research/legacy KB), market signals, and website URLs enter | FIP; the assessment engine | [Knowledge Intelligence](/capabilities/cap-knowledge-intelligence), [Website Assessment](/capabilities/cap-website-assessment) |\n| ② Processed | Extraction/harvest → staging queues → **human review & approval** → structuring | FIP (PersonalOps) | [personalops digest](/repos/personalops) |\n| ③ Intelligence | Approved intelligence becomes scoped, maturity-gated `knowledge_assets` (working→ready→proven) | FIP | [personalops digest](/repos/personalops) |\n| ④ Products | Builder skills synthesise assets into versioned, immutable **packs** | intelproducts (published by FIP) | [Intelligence Productization](/capabilities/cap-intelligence-productization) |\n| ⑤ Ventures consume | Engine applies a pinned pack to a website (crawl→score→findings→recs); apps qualify/segment | inexisstudios, outreachagent, leadplatform | [Website Assessment](/capabilities/cap-website-assessment) |\n| ⑥ Customer outcomes | Reports, COPs, proposals, outreach, journeys reach customers | ventures (Inexis Digital, Inbound Lanka, …) | [cap-commercial-opportunity](/capabilities/cap-commercial-opportunity) |\n| ⑦ Feedback | Outcomes signal quality; **planned** Hermes loop re-weights intelligence into a new pack version | (future) Hermes | [Intelligence Platform](/architecture/intelligence-platform) |\n\n> **Uncertainty (recorded):** stage ⑦ is **not built** (Hermes is a reserved future loop), and stage ⑤\n> cross-repo consumption is **mostly mock** in `outreachagent`. The loop is designed, not closed.\n\n---\n\n## Activity types across the lifecycle\n\nThe same lifecycle, coloured by **who or what performs the work** — the distinction the ecosystem must be\nexplicit about as it automates.\n\n```mermaid\ngraph TD\n subgraph HUMAN[\"👤 Human activities\"]\n H1[Capture intelligence]\n H2[Review & approve knowledge assets]\n H3[Approve assessment report]\n H4[Approve outreach send — 'nothing auto-sent']\n H5[Architectural governance / ADRs]\n end\n subgraph AI[\"🤝 AI-assisted activities\"]\n AI1[Harvest / extraction scripts]\n AI2[AI explains findings — narrative only]\n AI3[Skill invocations - Claude Code / ChatGPT]\n AI4[Pack authoring assistance]\n end\n subgraph AUTO[\"⚙️ Automated - deterministic\"]\n AU1[Rule-based scoring 0–100]\n AU2[Deterministic retrieval - search_assets, no embeddings]\n AU3[Immutable pack versioning]\n AU4[Website crawl]\n end\n subgraph FUTURE[\"🔮 Future autonomous\"]\n F1[OpenClaw agent - governed service consumer]\n F2[Hermes learning loop]\n F3[portfolio-portal-orchestrator - self-documenting]\n F4[Agent-initiated harvests]\n end\n\n H1 --> AI1 --> H2 --> AU2\n AU1 --> AI2 --> H3\n AI3 -.-> AU3\n F1 & F2 & F3 & F4 -.planned.-> H5\n classDef future fill:#eee,stroke-dasharray:4 3;\n class F1,F2,F3,F4 future;\n```\n\n| Activity type | Definition | Examples (evidenced) | Status |\n|---------------|-----------|----------------------|--------|\n| **👤 Human** | A person performs or must approve the step | Capture; **mandatory approval gates** (FIP asset promotion, report approval, outreach send); architectural governance | ✅ Implemented (the human boundary is by design, permanent for MVP) |\n| **🤝 AI-assisted** | AI does the work under human direction/skills; a human reviews | Harvest/extraction scripts; **AI explains findings (never decides)**; Claude Code / ChatGPT via skills & handoff files | ✅ Implemented |\n| **⚙️ Automated (deterministic)** | Runs without a model; exact & repeatable | Rule-based scoring; **deterministic retrieval (no embeddings at runtime)**; immutable pack versioning; crawl | ✅ Implemented |\n| **🔮 Future autonomous** | Agents act with limited human oversight | OpenClaw integration; Hermes learning; orchestrator auto-documentation; agent-initiated harvests | ⏳ Planned / not built |\n\n**The governing rule (evidenced):** across the ecosystem, **deterministic rules decide, AI explains, and a\nhuman approves before anything external happens** ([Principle 11](/architecture/principles);\n[Operating Principles](/operating-model/operating-principles)). Automation increases *within* stages; the **human approval\nboundary** (capture, review, approval) is deliberately preserved, not a temporary constraint.\n\n---\n\n## How the operating model governs itself\nSee the dedicated **[Architecture Governance](/governance)** section for how change is designed,\nreviewed, approved, and incorporated (decision framework, repository lifecycle, AI governance, review lifecycle).\nIn brief:\n- **Decisions** are recorded as [ADRs](/decisions); direction changes are proposed, not silently applied.\n- **Documentation** is evidence-first and honestly labelled ([Principle 8](/architecture/principles)); this portal is the operating manual.\n- **Change** is phase-gated with architecture review ([Principle 10](/architecture/principles)).\n- **Reuse & risk** are tracked in the [Capability Reuse Map](/architecture/capability-reuse-map) and [Architecture Risks](/architecture/architecture-risks).\n\n## Related\n- [Knowledge Asset Lifecycle](/operating-model/knowledge-asset-lifecycle) · [Concept Ownership](/operating-model/concept-ownership) · [Context Architecture](/operating-model/context-architecture)\n- [Operating Principles](/operating-model/operating-principles) · [AI Collaboration Model](/operating-model/ai-collaboration-model)\n- [Portfolio Overview](/overview) · [Intelligence Platform runtime flow](/architecture/intelligence-platform#4--runtime-information-flow)\n"},{"id":"/operating-model/ai-collaboration-model","kind":"page","entityType":"operating-model","title":"AI Collaboration Model","route":"/operating-model/ai-collaboration-model","sourcePath":"portal/operating-model/ai-collaboration-model.md","slug":null,"frontmatter":{"title":"AI Collaboration Model","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"How humans, AI assistants, orchestration systems, and future autonomous agents collaborate to operate the","headings":[{"depth":2,"text":"The actors","id":"the-actors"},{"depth":2,"text":"Who does what","id":"who-does-what"},{"depth":2,"text":"Collaboration patterns","id":"collaboration-patterns"},{"depth":3,"text":"Implemented today","id":"implemented-today"},{"depth":3,"text":"Future vision (not built)","id":"future-vision-not-built"},{"depth":2,"text":"The division of labour (target)","id":"the-division-of-labour-target"},{"depth":2,"text":"Guardrails (recommended, evidence-aligned)","id":"guardrails-recommended-evidence-aligned"},{"depth":2,"text":"Related","id":"related"}],"diagrams":2,"links":["context-architecture.md","operating-principles.md","../../ai/claude.handoff.md","../../ai/chatgpt.handoff.md","../capabilities/cap-reusable-ai-skills.md","../capabilities/cap-website-assessment.md","../architecture/intelligence-platform.md","../architecture/intelligence-platform.md","../../skills/portfolio-portal-orchestrator/SPEC.md","../../ai/AI-HANDOFF.md","operating-principles.md","../decisions/0005-platform-services-and-consolidation.md","../architecture/architecture-risks.md","operating-principles.md","context-architecture.md","README.md","../../ai/AI-HANDOFF.md","../../skills/portfolio-portal-orchestrator/SPEC.md"],"body":"\n# AI Collaboration Model\n\nHow humans, AI assistants, orchestration systems, and future autonomous agents collaborate to operate the\necosystem. This is the operating counterpart to the [Context Architecture](/operating-model/context-architecture): context\ntells each actor *what* to know; this page describes *who does what, together*. **Implemented behaviour is\nclearly separated from future vision.**\n\n## The actors\n\n```mermaid\ngraph TD\n HUMAN[\"👤 Human (founder / architect)
capture · review · approve · govern\"]\n subgraph Assistants[\"AI assistants (interactive)\"]\n CC[\"Claude Code ✅\"]\n GPT[\"ChatGPT ✅\"]\n end\n SKILLS[\"🧰 Shared Skills ✅
capability the assistants invoke\"]\n subgraph Future[\"Future autonomy 🔮\"]\n OC[\"OpenClaw ⏳
self-hosted agent\"]\n HER[\"Hermes ⏳
learning loop\"]\n ORCH[\"portfolio-portal-orchestrator ⏳
self-documenting\"]\n end\n\n HUMAN -->|directs| CC & GPT\n CC & GPT -->|invoke| SKILLS\n SKILLS -->|act on| REPOS[(repos · packs · portal)]\n HUMAN -->|governs via ADRs| REPOS\n OC -.consumes services.-> REPOS\n HER -.re-weights packs.-> REPOS\n ORCH -.regenerates.-> REPOS\n HUMAN -->|approves| GATE{{Approval gates}}\n classDef future fill:#eee,stroke-dasharray:4 3;\n class OC,HER,ORCH future;\n```\n\n## Who does what\n\n| Actor | Role | Status | Evidence |\n|-------|------|--------|----------|\n| **Human (founder/architect)** | Capture, review, **approval gates**, architectural governance (ADRs), strategy | ✅ Implemented | [Operating Principles O1–O2](/operating-model/operating-principles) |\n| **Claude Code** | Interactive AI assistant: builds/documents repos & this portal, invokes skills | ✅ Implemented | [ai/claude.handoff.md](/ai/claude.handoff); this portal was built with it |\n| **ChatGPT** | Interactive AI assistant with drop-in-to-templates working rules | ✅ Implemented (working rules defined) | [ai/chatgpt.handoff.md](/ai/chatgpt.handoff) |\n| **Shared Skills** | The capability layer the assistants invoke (169 skills; deterministic scripts + method) | ✅ Implemented | [cap-reusable-ai-skills](/capabilities/cap-reusable-ai-skills) |\n| **AI-in-product (assessment)** | LLM **explains** findings/recommendations from structured facts only | ✅ Implemented (engine) | [cap-website-assessment](/capabilities/cap-website-assessment) |\n| **OpenClaw** | Self-hosted personal agent; **planned** governed consumer of packs/services | ⏳ Planned (FIP Phase 5) | [Intelligence Platform](/architecture/intelligence-platform) |\n| **Hermes** | **Planned** learning loop re-weighting intelligence from outcomes | ⏳ Planned (not built) | [Intelligence Platform](/architecture/intelligence-platform) |\n| **portfolio-portal-orchestrator** | **Planned** skill that auto-maintains this portal | ⏳ Spec only | [SPEC](/skills/portfolio-portal-orchestrator/SPEC) |\n\n## Collaboration patterns\n\n### Implemented today\n1. **Human-directed, skill-powered assistance.** The founder directs Claude Code / ChatGPT, which invoke Shared\n Skills to build repos, author packs, and maintain the portal. Handoff files ([AI-HANDOFF](/ai/AI-HANDOFF))\n give any assistant the working rules; the portal + `llms.txt` supply context.\n2. **AI-as-narrator inside products.** In the assessment engine, deterministic rules decide and the LLM only\n explains — a bounded, auditable use of AI (Operating Principle O3).\n3. **Human governance.** Structural decisions are ADRs; nothing external is auto-sent.\n\n### Future vision (not built)\n4. **Governed autonomous agents.** OpenClaw becomes a *service consumer* — it pulls intelligence via the\n (future) retrieval service and assessment service, under one claims/tone guardrail, rather than a bespoke\n integration.\n5. **Closed learning loop.** Hermes observes outcomes and publishes re-weighted pack versions (one-way, O9),\n making recommendations outcome-driven instead of inference-derived.\n6. **Self-documenting portal.** The orchestrator regenerates digests, diagrams, registries, and `llms.txt`\n from source — keeping the operating manual true without manual upkeep.\n\n## The division of labour (target)\n\n```mermaid\ngraph LR\n H[Humans] -->|judgement, approval, governance| WORK((Work))\n AI[AI assistants + in-product AI] -->|drafting, extraction, explanation| WORK\n AUTO[Deterministic automation] -->|scoring, retrieval, versioning| WORK\n AGENTS[Future agents] -.->|routine consumption & upkeep| WORK\n```\n\n**Principle:** as autonomy increases, **the human approval boundary is preserved** — automation expands within\nstages, but capture/review/approval and architectural governance remain human ([Operating Principles](/operating-model/operating-principles)).\n\n## Guardrails (recommended, evidence-aligned)\n- Keep **AI explaining, not deciding** in customer-facing outputs; stricter review for regulated verticals (health).\n- Route future agents through **service contracts**, not venture repos ([ADR 0005, proposed](/decisions/0005-platform-services-and-consolidation)).\n- Converge AI prompt surfaces onto a **shared claims/tone guardrail** ([Architecture Risks R9](/architecture/architecture-risks)).\n\n## Related\n- [Operating Principles](/operating-model/operating-principles) · [Context Architecture](/operating-model/context-architecture) · [Portfolio Operating Model](/operating-model)\n- [AI handoff files](/ai/AI-HANDOFF) · [Orchestrator spec](/skills/portfolio-portal-orchestrator/SPEC)\n"},{"id":"/operating-model/concept-ownership","kind":"page","entityType":"operating-model","title":"Concept Ownership Registry","route":"/operating-model/concept-ownership","sourcePath":"portal/operating-model/concept-ownership.md","slug":null,"frontmatter":{"title":"Concept Ownership Registry","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"For every major architectural concept: its owner, the owning repository, the capability it belongs to, its","headings":[{"depth":2,"text":"Registry","id":"registry"},{"depth":2,"text":"Concepts with ambiguous or diffuse ownership (priority)","id":"concepts-with-ambiguous-or-diffuse-ownership-priority"},{"depth":2,"text":"Related","id":"related"}],"diagrams":0,"links":["../capabilities/cap-reusable-ai-skills.md","../capabilities/cap-knowledge-intelligence.md","../capabilities/cap-website-assessment.md","../capabilities/cap-intelligence-productization.md","../capabilities/cap-reproducible-evaluation.md","../capabilities/README.md","../capabilities/cap-commercial-opportunity.md","../capabilities/cap-architecture-governance.md","../decisions/0005-platform-services-and-consolidation.md","glossary.md","glossary.md","knowledge-asset-lifecycle.md","../architecture/capability-reuse-map.md","../architecture/architecture-review.md#1--capability-ownership"],"body":"\n# Concept Ownership Registry\n\nFor every major architectural **concept**: its owner, the owning repository, the capability it belongs to, its\nlifecycle, its consumers, and its **source of truth**. This surfaces concepts with **ambiguous ownership** —\nthe biggest operating risk as the ecosystem grows. Evidence-first; concepts the portal cannot yet substantiate\nare marked **⚠ uncertain**, not invented.\n\n## Registry\n\n| Concept | Owner | Repository | Capability | Lifecycle | Consumers | Source of truth |\n|---------|-------|-----------|------------|-----------|-----------|-----------------|\n| **Skills** | shared-skills library | `shared-skills` | [Reusable AI Skills](/capabilities/cap-reusable-ai-skills) | operational | all repos, agents | `SKILL.md` files |\n| **Knowledge Assets** | FIP | `personalops` | [Knowledge Intelligence](/capabilities/cap-knowledge-intelligence) | early-dev | retrieval, builders | `knowledge_assets` (Supabase) |\n| **Findings** | assessment engine (rules from pack) | `inexisstudios` | [Website Assessment](/capabilities/cap-website-assessment) | active-dev | recommendations, COP | engine `assessment_findings` (derived from pack rules) |\n| **Recommendations** | ⚠ **ambiguous** — engine rules + pack library + COP action | `inexisstudios` + `intelproducts` + `outreachagent` | Website Assessment / Commercial Opportunity | mixed | outreach, proposals | **should be the pack** (`recommendation-library` REC-001…015) — currently three layers |\n| **Packs** | intelproducts | `intelproducts` | [Intelligence Productization](/capabilities/cap-intelligence-productization) | operational | engine, apps | immutable versioned pack dirs |\n| **Intelligence Products** | intelproducts | `intelproducts` | Intelligence Productization | operational | ventures | `intelproducts` repo (= Packs) |\n| **Opportunity Scores** | ⚠ **ambiguous** — pack score vs leadplatform's own | `intelproducts` + `leadplatform` | Website Assessment / (leadplatform) | mixed | outreach, CRM | **two competing** — recommend pack as single source (R2) |\n| **Website Assessments** | ⚠ **diffuse** — 4 co-owners | `inexisstudios` (engine) + `intelproducts` (pack) + `personalops` (authoring) + `website-intelligence-lab` (harness) | Website Assessment | mixed | outreach, leadplatform | engine result contract (`/api/assessments/:slug`); scoring truth = pack |\n| **Journey Intelligence** | intelproducts (cinnamon-stories) | `intelproducts` | (travel/Inbound Lanka) | operational (pack) | Inbound Lanka | `sri-lanka-journey-architecture-pack-v1` |\n| **Signals** | intelproducts (travel signal catalogue) / FIP authoring | `intelproducts` + `personalops` | Website Assessment (travel) | operational (pack) | rule packs, engine | travel `signal catalogue` (WP-48B); 159 signals |\n| **Observations** | ⚠ maps to WIL **observed assets** | `website-intelligence-lab` | [Reproducible Evaluation](/capabilities/cap-reproducible-evaluation) | early-dev (`capture_pending`) | cases, runs | `corpus/businesses//observed/` manifests |\n| **Domain Briefs** | ⚠ **not directly evidenced** | uncertain (possibly relates to industry packs / opportunity-briefs route) | uncertain | uncertain | uncertain | ⚠ **term not substantiated in processed docs** |\n| **Review Packages** | ⚠ **not directly evidenced** as a named concept | uncertain (FIP review queue / lab review gate) | uncertain | uncertain | uncertain | ⚠ **term not substantiated in processed docs** |\n| **Capabilities** | Capability Registry | `portfolio-portal` | (all) | mixed | ventures | [Capability Registry](/capabilities) |\n| **Runs** | website-intelligence-lab | `website-intelligence-lab` | Reproducible Evaluation | early-dev | evaluation | immutable `runs////` |\n| **Cases / Businesses / Reference assets / Benchmarks** | website-intelligence-lab | `website-intelligence-lab` | Reproducible Evaluation | early-dev | runs, evaluation | WIL `corpus/` + contracts |\n| **Commercial Opportunity Profile (COP)** | outreachagent | `outreachagent` | [Commercial Opportunity](/capabilities/cap-commercial-opportunity) | operational (mock) | CRM, email, proposal | COP schema v2 (frozen) |\n| **Maturity levels** | ⚠ **two definitions** — pack (1–5 site maturity) vs FIP (working/ready/proven/archived asset maturity) | `intelproducts` + `personalops` | Website Assessment / Knowledge Intelligence | operational | scoring / asset promotion | two distinct, both valid in context — **standardise naming** |\n| **Digests / ADRs / Principles** | portfolio-portal | `portfolio-portal` | [Architecture & Docs Governance](/capabilities/cap-architecture-governance) | operational | humans, agents | this portal |\n\n## Concepts with ambiguous or diffuse ownership (priority)\n\n| Concept | Problem | Recommendation |\n|---------|---------|----------------|\n| **Recommendations** | Logic in 3 layers (engine / pack / COP) | Make the **pack** the single source; engine & COP pin to it |\n| **Opportunity Scores** | Two competing scores (pack vs leadplatform) | Single source (pack/COP); retire leadplatform's parallel score |\n| **Website Assessments** | 4 co-owners, no single accountable owner | Assign capability ownership: pack = scoring truth, engine = execution (see [ADR 0005](/decisions/0005-platform-services-and-consolidation)) |\n| **Maturity levels** | Same word, two meanings (site maturity vs asset maturity) | Standardise names: \"site maturity level\" vs \"asset maturity state\" (see [Glossary](/operating-model/glossary)) |\n| **Domain Briefs / Review Packages** | Named in the brief but **not evidenced** in processed docs | Do not model until evidenced; confirm whether these exist or are aliases |\n\n> **Evidence discipline:** \"Domain Briefs\" and \"Review Packages\" were requested for review but are **not\n> substantiated** in the documentation processed so far. They are recorded here as *unresolved* rather than\n> given invented owners. Confirm against `PersonalOps` (opportunity-briefs / review queue) before modelling.\n\n## Related\n- [Portfolio Glossary](/operating-model/glossary) · [Knowledge Asset Lifecycle](/operating-model/knowledge-asset-lifecycle) · [Capability Reuse Map](/architecture/capability-reuse-map)\n- [Architecture Review §1 Ownership](/architecture/architecture-review#1--capability-ownership)\n"},{"id":"/operating-model/context-architecture","kind":"page","entityType":"operating-model","title":"Context Architecture","route":"/operating-model/context-architecture","sourcePath":"portal/operating-model/context-architecture.md","slug":null,"frontmatter":{"title":"Context Architecture","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The ecosystem operates across five levels of context. Each level answers a different question, has a","headings":[{"depth":2,"text":"The five levels","id":"the-five-levels"},{"depth":2,"text":"Level detail","id":"level-detail"},{"depth":3,"text":"1 · Repository Context","id":"1-repository-context"},{"depth":3,"text":"2 · Capability Context","id":"2-capability-context"},{"depth":3,"text":"3 · Platform Context","id":"3-platform-context"},{"depth":3,"text":"4 · Portfolio Context","id":"4-portfolio-context"},{"depth":3,"text":"5 · Business Context","id":"5-business-context"},{"depth":2,"text":"Context flow rules","id":"context-flow-rules"},{"depth":2,"text":"AI context (cross-cutting)","id":"ai-context-cross-cutting"},{"depth":2,"text":"Anti-patterns to avoid (recommendations)","id":"anti-patterns-to-avoid-recommendations"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../capabilities/README.md","../architecture/intelligence-platform.md","../portfolio-overview.md","../architecture/system-of-systems.md","../portfolio-overview.md","../../ai/AI-HANDOFF.md","README.md","concept-ownership.md","glossary.md","../portfolio-overview.md","ai-collaboration-model.md"],"body":"\n# Context Architecture\n\nThe ecosystem operates across **five levels of context**. Each level answers a different question, has a\ndifferent owner, changes at a different rate, and has a distinct source of truth. Getting context placement\nright is what lets humans *and* AI agents act correctly at the right altitude. Evidence-first.\n\n## The five levels\n\n```mermaid\ngraph TD\n BC[\"🏢 Business Context
ventures, market, strategy, outcomes\"] --> POC\n POC[\"🗺️ Portfolio Context
system of systems, layers, capabilities\"] --> PLC\n PLC[\"🧠 Platform Context
a platform's architecture & lifecycle\"] --> CC\n CC[\"🔧 Capability Context
a reusable capability's contract\"] --> RC\n RC[\"📦 Repository Context
one repo: CLAUDE.md, README, ADRs\"]\n\n RC -. rolls up to .-> CC -. rolls up to .-> PLC -. rolls up to .-> POC -. rolls up to .-> BC\n```\n\nContext **flows down** as intent/strategy and **rolls up** as evidence: a repository's facts roll up into a\ncapability's contract, which rolls up into a platform view, the portfolio map, and the business strategy;\nconversely, business strategy sets direction that constrains platforms, capabilities, and repos.\n\n## Level detail\n\n### 1 · Repository Context\n- **Purpose:** everything needed to work correctly *inside one repository*.\n- **Scope:** a single repo — its purpose, domain model, conventions, decisions.\n- **Consumers:** contributors and AI agents editing that repo.\n- **Update frequency:** with the code (frequent).\n- **Source of truth:** the repo's own `CLAUDE.md`, `README`, `docs/`, and ADRs (e.g. WIL's philosophy/ADRs, FIP's design package).\n\n### 2 · Capability Context\n- **Purpose:** how a reusable capability works, independent of any repo — its contract, owners, consumers.\n- **Scope:** one capability (may span repos, e.g. Website Assessment across 4).\n- **Consumers:** teams/agents composing or consuming the capability.\n- **Update frequency:** when the capability's contract or maturity changes (occasional).\n- **Source of truth:** the [Capability Registry](/capabilities) + capability pages.\n\n### 3 · Platform Context\n- **Purpose:** a platform's internal architecture and lifecycle (executive → runtime).\n- **Scope:** one platform/system (e.g. the [Intelligence Platform](/architecture/intelligence-platform)).\n- **Consumers:** architects, platform builders, AI agents reasoning about the platform.\n- **Update frequency:** per architectural change (occasional).\n- **Source of truth:** the platform architecture pages + system digests.\n\n### 4 · Portfolio Context\n- **Purpose:** the *system of systems* — how repos, capabilities, layers, and dependencies fit together.\n- **Scope:** the whole ecosystem's architecture.\n- **Consumers:** the architect (founder), new collaborators, AI context (`llms.txt`).\n- **Update frequency:** per phase / significant change.\n- **Source of truth:** the [Portfolio Overview](/overview), [system dependency map](/architecture/system-of-systems), registries, `llms.txt`.\n\n### 5 · Business Context\n- **Purpose:** why the ecosystem exists — ventures, market, strategy, commercial outcomes.\n- **Scope:** the founder's five venture areas and their goals.\n- **Consumers:** the founder; investors/partners; strategy.\n- **Update frequency:** slow (strategic).\n- **Source of truth:** the [Portfolio Overview](/overview) vision/strategy + venture digests; some business facts live in venture systems **outside** the processed repos (**uncertainty recorded**).\n\n## Context flow rules\n\n| Direction | What flows | Example |\n|-----------|-----------|---------|\n| **Down (intent)** | Strategy → platform priorities → capability requirements → repo work | Business decides \"AI website replacements\" → assessment capability → engine repo |\n| **Up (evidence)** | Repo facts → capability status → platform maturity → portfolio map → business truth | Engine maturity rolls up into the capability page, the platform doc, the dashboard |\n| **Sideways (contracts)** | Capabilities expose contracts consumed by peers | Pack contract consumed by engine + apps |\n\n## AI context (cross-cutting)\nContext is not only for humans. The ecosystem exposes machine-readable context so AI agents act at the right\nlevel:\n- **`llms.txt`** — portfolio-level machine index.\n- **Repo `CLAUDE.md` + portal [AI handoff files](/ai/AI-HANDOFF)** — repo & portal working rules.\n- **Capability pages & digests** — structured, linkable context for retrieval.\n- **(Future)** the retrieval service + orchestrator would let agents pull the exact context level they need on demand.\n\n## Anti-patterns to avoid (recommendations)\n- **Context at the wrong level** — putting cross-repo capability facts inside one repo's `CLAUDE.md` (they belong in the capability page).\n- **Duplicated context** — copying business strategy into every repo; link up instead.\n- **Stale roll-up** — repo changes not reflected in the capability/portfolio level (the orchestrator would fix this).\n\n## Related\n- [Portfolio Operating Model](/operating-model) · [Concept Ownership](/operating-model/concept-ownership) · [Portfolio Glossary](/operating-model/glossary)\n- [Portfolio Overview](/overview) · [AI Collaboration Model](/operating-model/ai-collaboration-model)\n"},{"id":"/operating-model/glossary","kind":"page","entityType":"operating-model","title":"Portfolio Glossary (authoritative)","route":"/operating-model/glossary","sourcePath":"portal/operating-model/glossary.md","slug":null,"frontmatter":{"title":"Portfolio Glossary (authoritative)","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The single authoritative vocabulary for the ecosystem. Every architectural term has one definition","headings":[{"depth":2,"text":"Terms","id":"terms"},{"depth":2,"text":"Duplicate / colliding terminology to standardise","id":"duplicate-colliding-terminology-to-standardise"},{"depth":2,"text":"Related","id":"related"}],"diagrams":0,"links":["../../docs/glossary.md","concept-ownership.md","knowledge-asset-lifecycle.md","../../docs/glossary.md"],"body":"\n# Portfolio Glossary (authoritative)\n\nThe **single authoritative vocabulary** for the ecosystem. Every architectural term has **one** definition\nhere. Each entry records: **meaning · owner · related concepts · where used · first-class** (a first-class term\nis a modelled concept with an owner and a source of truth, not just descriptive language).\n\n> This supersedes ad-hoc definitions elsewhere. The portal-maintenance vocabulary in\n> [`docs/glossary.md`](/about/glossary) is scoped to *how the portal is built*; this page is the\n> *ecosystem* glossary. Where they overlap, this page wins.\n\n## Terms\n\n| Term | Meaning | Owner | Related | Where used | First-class |\n|------|---------|-------|---------|------------|:----------:|\n| **Skill** | A modular `SKILL.md` capability package that extends an AI agent | `shared-skills` | Consumer skill, Builder skill | all repos | ✅ Yes |\n| **Knowledge Estate** | The founder's corpus of markdown docs + captures — the raw source layer | FIP | Knowledge Asset, Raw Sources | `personalops` | ✅ Yes |\n| **Knowledge Asset** | A structured, scoped, maturity-gated intelligence record | FIP | Scope dimension, Asset maturity | `personalops` | ✅ Yes |\n| **Asset maturity state** | `working → ready → proven → archived` for a knowledge asset (**not** site maturity) | FIP | Maturity, Knowledge Asset | `personalops` | ✅ Yes |\n| **Scope dimension** | One of venture · industry · market · capability · use-case tagging a knowledge asset | FIP | Knowledge Asset | `personalops` | ✅ Yes |\n| **Pack (Intelligence Pack)** | A versioned, immutable, machine-consumable intelligence product | `intelproducts` | Intelligence Product, Rule pack, Runtime pack | `intelproducts` + consumers | ✅ Yes |\n| **Intelligence Product** | Synonym for a published Pack (the productised output) | `intelproducts` | Pack | ecosystem | ✅ Yes (= Pack) |\n| **Consumer skill** | A skill a consuming repo uses to act on a pack | `intelproducts` | Skill, Pack | `intelproducts/skills` | ✅ Yes |\n| **Builder skill** | A skill FIP uses to author packs from assets | `shared-skills`/FIP | Skill, Pack | `personalops` | ✅ Yes |\n| **Finding** | An evidence-backed issue produced by applying a rule to a crawled site | assessment engine | Rule, Recommendation | `inexisstudios` | ✅ Yes |\n| **Recommendation** | A rule-based suggested action/offer derived from findings + scores | ⚠ pack (should own) | Finding, REC-001…015, COP | engine, pack, COP | ✅ Yes (needs single owner) |\n| **Website Assessment** | Crawl + score a site against an industry pack → findings, recs, report | capability (4 repos) | Pack, Finding, COP, Score | `inexisstudios` | ✅ Yes |\n| **Score (assessment)** | Deterministic 0–100 weighted-domain website score | pack | Domain, Band, Site maturity level | engine, pack | ✅ Yes |\n| **Site maturity level** | 1–5 website maturity (Basic → Industry-Leading) — **not** asset maturity | pack | Score, Assessment | `intelproducts` | ✅ Yes |\n| **Opportunity Score** | A score ranking a prospect's commercial opportunity | ⚠ **two owners** (pack vs leadplatform) | Score, COP | `intelproducts`, `leadplatform` | ⚠ Yes but **duplicated** |\n| **Commercial Opportunity Profile (COP)** | Structured decision (evidence→diagnosis→recommendation→blueprint) on a prospect | `outreachagent` | Recommendation, Assessment | `outreachagent` | ✅ Yes |\n| **Signal** | A discrete measurable indicator in a domain (e.g. travel: 159 signals) | `intelproducts`/FIP | Rule, Pack | travel/cleaning packs | ✅ Yes |\n| **Observed asset / Observation** | A business's real digital presence, referenced + snapshotted, never rehosted | `website-intelligence-lab` | Digital Asset, Case | WIL corpus | ✅ Yes |\n| **Journey Intelligence** | Travel journey architecture intelligence (Sri Lanka inbound) | `intelproducts` | Pack, Signal | cinnamon-stories | ✅ Yes |\n| **Run** | One immutable, fully-provenanced experiment execution | `website-intelligence-lab` | Case, Benchmark | WIL | ✅ Yes |\n| **Case / Business / Reference asset / Benchmark** | WIL corpus & evaluation entities | `website-intelligence-lab` | Run, Observed asset | WIL | ✅ Yes |\n| **Capability** | A reusable business/technical capability documented independent of repos | Capability Registry | (all) | portal | ✅ Yes |\n| **Venture / System** | A grouping delivering a product; positioned in an architecture layer | portal | Layer, Repo | portal | ✅ Yes |\n| **Layer** | One of the 6 (proposed 7) architecture layers | portal | Venture, Capability | portal | ✅ Yes |\n| **Digest** | A canonical one-page summary of a repo or system | `portfolio-portal` | Registry | portal | ✅ Yes |\n| **ADR** | An Architecture Decision Record | `portfolio-portal` | Principle | portal | ✅ Yes |\n| **Domain Brief** | ⚠ term named in Phase E but **not evidenced** — do not use until confirmed | — | — | — | ❌ **Unresolved** |\n| **Review Package** | ⚠ term named in Phase E but **not evidenced** — possibly FIP review queue / lab review | — | — | — | ❌ **Unresolved** |\n\n## Duplicate / colliding terminology to standardise\n\n| Collision | Problem | Standard (recommended) |\n|-----------|---------|------------------------|\n| **\"Maturity\"** | Means two things — site maturity (1–5) and asset maturity (working/ready/proven) | Always qualify: **\"site maturity level\"** vs **\"asset maturity state\"** |\n| **\"Opportunity Score\"** | Two implementations (pack vs leadplatform) | One score sourced from the pack/COP; deprecate the parallel one (R2) |\n| **\"Recommendation\"** | Defined in engine, pack, and COP | Pack `recommendation-library` is the source; engine/COP reference it |\n| **\"Pack\" vs \"Intelligence Product\"** | Used interchangeably | Treat as synonyms; prefer **\"pack\"** in technical contexts, **\"intelligence product\"** in commercial ones |\n| **\"Observation\" vs \"Observed asset\"** | Same concept, two phrasings | Prefer **\"observed asset\"** (WIL's term) |\n| **\"Venture\" vs \"System\"** | Portal uses both for the grouping digest | Keep both: **\"system\"** for internal groupings, **\"venture\"** for a business |\n\n## Related\n- [Concept Ownership Registry](/operating-model/concept-ownership) · [Knowledge Asset Lifecycle](/operating-model/knowledge-asset-lifecycle)\n- Portal-maintenance vocabulary: [`docs/glossary.md`](/about/glossary)\n"},{"id":"/operating-model/knowledge-asset-lifecycle","kind":"page","entityType":"operating-model","title":"Knowledge Asset Lifecycle","route":"/operating-model/knowledge-asset-lifecycle","sourcePath":"portal/operating-model/knowledge-asset-lifecycle.md","slug":null,"frontmatter":{"title":"Knowledge Asset Lifecycle","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The lifecycle of information as it is progressively refined from raw source into commercial outcome. Each stage","headings":[{"depth":2,"text":"The lifecycle","id":"the-lifecycle"},{"depth":2,"text":"Stage detail","id":"stage-detail"},{"depth":3,"text":"1 · Raw Sources","id":"1-raw-sources"},{"depth":3,"text":"2 · Extracted Knowledge","id":"2-extracted-knowledge"},{"depth":3,"text":"3 · Knowledge Assets","id":"3-knowledge-assets"},{"depth":3,"text":"4 · Intelligence","id":"4-intelligence"},{"depth":3,"text":"5 · Intelligence Products","id":"5-intelligence-products"},{"depth":3,"text":"6 · Capabilities","id":"6-capabilities"},{"depth":3,"text":"7 · Customer Experiences","id":"7-customer-experiences"},{"depth":3,"text":"8 · Commercial Outcomes","id":"8-commercial-outcomes"},{"depth":2,"text":"Ownership & persistence summary","id":"ownership-persistence-summary"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../capabilities/cap-website-assessment.md","../capabilities/README.md","../architecture/architecture-review.md","../decisions/0005-platform-services-and-consolidation.md","README.md","concept-ownership.md","glossary.md","../architecture/intelligence-platform.md#4--runtime-information-flow"],"body":"\n# Knowledge Asset Lifecycle\n\nThe lifecycle of information as it is progressively refined from raw source into commercial outcome. Each stage\nrecords **owner, lifecycle, consumers, persistence, and evolution**, grounded in documented evidence.\nUncertainty is flagged where the portal's evidence is incomplete.\n\n## The lifecycle\n\n```mermaid\ngraph TD\n RS[Raw Sources] --> EK[Extracted Knowledge]\n EK --> KA[Knowledge Assets]\n KA --> INT[Intelligence]\n INT --> IP[Intelligence Products]\n IP --> CAP[Capabilities]\n CAP --> CX[Customer Experiences]\n CX --> CO[Commercial Outcomes]\n CO -. feedback (future Hermes, one-way) .-> IP\n```\n\n## Stage detail\n\n### 1 · Raw Sources\n- **Meaning:** unstructured founder knowledge — markdown docs (knowledge estate, 46 registered / ~4,600 lines),\n ad-hoc captures (voice, articles, agent research, legacy KB), market signals, and website URLs.\n- **Owner:** the founder / FIP (`personalops`). Website URLs are supplied to the assessment engine.\n- **Lifecycle:** authored/collected continuously; never the retrieval layer (\"documents are the source, not the asset\").\n- **Consumers:** the extraction/harvest pipeline.\n- **Persistence:** Git markdown (authoritative narrative), plus incoming captures.\n- **Evolution:** grows continuously; markdown remains the authoritative narrative even after extraction.\n\n### 2 · Extracted Knowledge\n- **Meaning:** candidate insights pulled from sources by harvest/extraction scripts — `harvest_candidates`.\n- **Owner:** FIP harvest pipeline.\n- **Lifecycle:** transient — a **staging** state awaiting human review; not yet canonical.\n- **Consumers:** the founder (review queue).\n- **Persistence:** staging tables (`ingestion_queue`, `harvest_candidates`) until approved or rejected.\n- **Evolution:** promoted to a Knowledge Asset on approval, or discarded.\n\n### 3 · Knowledge Assets\n- **Meaning:** structured, scoped, maturity-gated records — the **canonical intelligence store** (`knowledge_assets`).\n- **Owner:** FIP (`personalops`) — one canonical store, no duplication.\n- **Lifecycle:** maturity `working → ready → proven → archived`; `working` internal-only, `ready`/`proven` external-facing.\n- **Consumers:** retrieval (`search_assets`), pack builders, agents.\n- **Persistence:** Supabase PostgreSQL (canonical).\n- **Evolution:** re-scoped/re-matured by the founder; **post-MVP** relationship graph & semantic search.\n\n### 4 · Intelligence\n- **Meaning:** distilled, proven intelligence ready to be productised (the higher-maturity subset of assets +\n synthesis).\n- **Owner:** FIP.\n- **Lifecycle:** the input to pack synthesis; matures via the approval/maturity model.\n- **Consumers:** builder skills (`intelligence-pack-publisher`).\n- **Persistence:** in `knowledge_assets`; synthesised views are generated, not a new store.\n- **Evolution:** feeds new/updated packs.\n\n### 5 · Intelligence Products\n- **Meaning:** versioned, immutable, machine-consumable **packs** (proposal, website-assessment, cinnamon-stories, outreach-messaging).\n- **Owner:** `intelproducts` (published by FIP builder skills; FIP does not consume them).\n- **Lifecycle:** immutable once published; additive → `v1.x` in place, structural → new `v2` dir.\n- **Consumers:** the assessment engine, `leadplatform`, `outreachagent`, consumer skills.\n- **Persistence:** immutable versioned Git; vendored into consumers as pinned submodules.\n- **Evolution:** re-run the builder skill → publish the next version.\n\n### 6 · Capabilities\n- **Meaning:** reusable business/technical capabilities (e.g. [Website Assessment](/capabilities/cap-website-assessment))\n that apply products to produce outputs.\n- **Owner:** the [Capability Registry](/capabilities); some capabilities currently span/are trapped\n in multiple repos (see [Architecture Review](/architecture/architecture-review)).\n- **Lifecycle:** concept → early-dev → operational; tracked per capability page.\n- **Consumers:** ventures & apps.\n- **Persistence:** engine code + pinned packs + service contracts.\n- **Evolution:** recommended extraction into platform services ([ADR 0005, proposed](/decisions/0005-platform-services-and-consolidation)).\n\n### 7 · Customer Experiences\n- **Meaning:** the outputs customers touch — assessment reports, Commercial Opportunity Profiles, proposals,\n outreach, travel journeys.\n- **Owner:** the ventures/apps (`inexisstudios`, `outreachagent`, future venture front-ends).\n- **Lifecycle:** produced per prospect/engagement; gated by human approval (\"nothing auto-sent\").\n- **Consumers:** prospects & customers of the ventures.\n- **Persistence:** reports (`/api/assessments/:slug`), CRM records, emails/proposals.\n- **Evolution:** improves as packs and capabilities improve.\n\n### 8 · Commercial Outcomes\n- **Meaning:** the business results — won engagements, website replacements, bookings, revenue.\n- **Owner:** the ventures (Inexis Digital, Inexis Consulting, Inbound Lanka, City Retreats).\n- **Lifecycle:** the end of the value chain; the source of feedback signals.\n- **Consumers:** the founder (strategy); **(future)** the Hermes learning loop.\n- **Persistence:** CRM / venture systems (outside the processed repos — **uncertainty recorded**).\n- **Evolution:** outcomes should feed back to re-weight intelligence — **planned, not built** (Hermes).\n\n## Ownership & persistence summary\n\n| Stage | Owner | Persistence | Consumers | Status |\n|-------|-------|-------------|-----------|--------|\n| Raw Sources | Founder / FIP | Git markdown | Harvest | ✅ |\n| Extracted Knowledge | FIP harvest | Staging tables | Review queue | ✅ |\n| Knowledge Assets | FIP | Supabase | Retrieval, builders | 🔶 (schema built; UI phases pending) |\n| Intelligence | FIP | Supabase (subset) | Builders | 🔶 |\n| Intelligence Products | intelproducts | Immutable Git | Engine, apps | ✅ contract |\n| Capabilities | Capability Registry | Code + packs | Ventures | 🔶 mixed |\n| Customer Experiences | Ventures/apps | Reports, CRM | Customers | 🔶 (mostly mock cross-repo) |\n| Commercial Outcomes | Ventures | Venture systems | Founder, (future) Hermes | 🧭 feedback unbuilt |\n\n> **Evidence boundary:** stages 7–8 partly rely on systems outside the four processed repos (CRM, venture\n> front-ends); their persistence is asserted only where documented. The feedback edge (8 → 5) is **designed,\n> not implemented**.\n\n## Related\n- [Portfolio Operating Model](/operating-model) · [Concept Ownership](/operating-model/concept-ownership) · [Portfolio Glossary](/operating-model/glossary)\n- [Intelligence Platform runtime flow](/architecture/intelligence-platform#4--runtime-information-flow)\n"},{"id":"/operating-model/operating-principles","kind":"page","entityType":"operating-model","title":"Operating Principles","route":"/operating-model/operating-principles","sourcePath":"portal/operating-model/operating-principles.md","slug":null,"frontmatter":{"title":"Operating Principles","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The Architecture Principles mix two kinds of principle: those about how","headings":[{"depth":2,"text":"Split of the existing 12 principles","id":"split-of-the-existing-12-principles"},{"depth":2,"text":"Operating Principles (how work is performed)","id":"operating-principles-how-work-is-performed"},{"depth":3,"text":"O1. Humans own capture, review, and approval","id":"o1-humans-own-capture-review-and-approval"},{"depth":3,"text":"O2. Nothing is ever auto-sent","id":"o2-nothing-is-ever-auto-sent"},{"depth":3,"text":"O3. Deterministic first; AI explains, never decides","id":"o3-deterministic-first-ai-explains-never-decides"},{"depth":3,"text":"O4. Capture first","id":"o4-capture-first"},{"depth":3,"text":"O5. Maturity is a human quality gate","id":"o5-maturity-is-a-human-quality-gate"},{"depth":3,"text":"O6. Immutable, versioned contracts; consumers pin versions","id":"o6-immutable-versioned-contracts-consumers-pin-versions"},{"depth":3,"text":"O7. Evidence-first; record uncertainty","id":"o7-evidence-first-record-uncertainty"},{"depth":3,"text":"O8. Phase-gated change with architecture review","id":"o8-phase-gated-change-with-architecture-review"},{"depth":3,"text":"O9. One-way feedback (never mutate a consumed artefact)","id":"o9-one-way-feedback-never-mutate-a-consumed-artefact"},{"depth":2,"text":"Operating vs Architecture at a glance","id":"operating-vs-architecture-at-a-glance"},{"depth":2,"text":"Related","id":"related"}],"diagrams":1,"links":["../architecture/principles.md","../architecture/principles.md","../architecture/principles.md","../architecture/principles.md","ai-collaboration-model.md","README.md"],"body":"\n# Operating Principles\n\nThe [Architecture Principles](/architecture/principles) mix two kinds of principle: those about **how\nsystems are structured** (architecture) and those about **how work is performed** (operating). This page\nseparates them and adds operating-specific principles evidenced across the ecosystem. It is a\n**reclassification and extension** — the existing principles page is unchanged.\n\n## Split of the existing 12 principles\n\n| # | Principle | Kind |\n|---|-----------|------|\n| 1 | Reproducibility & complete provenance | Both — leans **Operating** (how work is recorded) |\n| 2 | Definition vs. derivation (inputs ≠ outputs) | **Architecture** |\n| 3 | Knowledge is referenced, never owned | **Architecture** |\n| 4 | Stage is state, not location | **Architecture** |\n| 5 | Composable, opt-in services | **Architecture** |\n| 6 | Measurement / evaluation is first-class | **Operating** |\n| 7 | No speculative abstraction (four-part test) | **Operating** (how we decide to build) |\n| 8 | Honest realization labelling | **Operating** (how we document) |\n| 9 | Layered leverage (capability flows upward) | **Architecture** |\n| 10 | Phase-gated, reviewable change | **Operating** |\n| 11 | Deterministic rules decide; AI explains | **Operating** (how decisions are made) |\n| 12 | Capabilities are first-class & repo-independent | **Architecture** |\n\n**Architecture principles (structure):** 2, 3, 4, 5, 9, 12.\n**Operating principles (work):** 1, 6, 7, 8, 10, 11 — plus the additions below.\n\n## Operating Principles (how work is performed)\n\nEach is grounded in documented evidence.\n\n### O1. Humans own capture, review, and approval\nThe founder's irreducible responsibilities are **capture, review, and approval**; classification, enrichment,\nand structuring are automated where possible. *(Source: FIP \"founder responsibility boundary\".)*\n\n### O2. Nothing is ever auto-sent\nNo externally-visible output (email, proposal, published report) leaves the ecosystem without a human approval\ngate. *(Source: `outreachagent` \"golden rule\"; assessment `ready_for_review → approved`.)*\n\n### O3. Deterministic first; AI explains, never decides\nRouting, retrieval, scoring, and recommendations are **deterministic**; an LLM narrates results from structured\nfacts only. *(Source: assessment engine §13; PersonalOps \"determinism-first, no embeddings at runtime\".)* — the\noperating form of [Principle 11](/architecture/principles).\n\n### O4. Capture first\nPrioritise low-friction capture over structuring completeness — \"capture now, classify on review.\" Most\nintelligence is lost because it is never captured. *(Source: FIP Principle 9.)*\n\n### O5. Maturity is a human quality gate\nIntelligence advances through maturity states only by **founder judgement about evidence**, not an automation\nmilestone. *(Source: FIP \"maturity as quality gate\".)*\n\n### O6. Immutable, versioned contracts; consumers pin versions\nPublished products are immutable and versioned; consumers depend on an exact version and treat it as a\nread-only contract. *(Source: `intelproducts` pack contract; ADR-0004 (WIL) immutable runs.)*\n\n### O7. Evidence-first; record uncertainty\nDocumentation and decisions are based on documented evidence; unknowns are labelled, never invented. *(Source:\n[Principle 8](/architecture/principles); this portal throughout.)*\n\n### O8. Phase-gated change with architecture review\nWork proceeds in small, independently reviewable phases; each ends with an architecture review before the next\nbegins. *(Source: WIL implementation philosophy; the portal's own A–E phases.)*\n\n### O9. One-way feedback (never mutate a consumed artefact)\nFeedback improves the system by producing a **new immutable version**, never by mutating an artefact others\nalready consume. *(Source: ADR 0005 (proposed) Hermes design; immutable-runs principle.)*\n\n## Operating vs Architecture at a glance\n\n```mermaid\ngraph LR\n subgraph ARCH[\"Architecture Principles — how systems are STRUCTURED\"]\n A2[Definition vs derivation]\n A3[Knowledge referenced, not owned]\n A4[Stage is state]\n A5[Composable services]\n A9[Layered leverage]\n A12[Capabilities first-class]\n end\n subgraph OPS[\"Operating Principles — how WORK is performed\"]\n O1a[Humans own capture/review/approval]\n O2a[Nothing auto-sent]\n O3a[Deterministic decides / AI explains]\n O4a[Capture first]\n O7a[Evidence-first]\n O8a[Phase-gated review]\n end\n ARCH -. governs .-> OPS\n```\n\n## Related\n- [Architecture Principles](/architecture/principles) (the source list; unchanged)\n- [AI Collaboration Model](/operating-model/ai-collaboration-model) · [Portfolio Operating Model](/operating-model)\n"},{"id":"/overview","kind":"page","entityType":"overview","title":"Portfolio Overview — Executive Briefing","route":"/overview","sourcePath":"portal/portfolio-overview.md","slug":null,"frontmatter":{"title":"Portfolio Overview — Executive Briefing","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"foundation up into products, applications, and customer-facing ventures — so each improvement at the base","headings":[{"depth":2,"text":"Vision","id":"vision"},{"depth":2,"text":"Architecture Layers","id":"architecture-layers"},{"depth":2,"text":"Information Flow","id":"information-flow"},{"depth":2,"text":"Portfolio Map","id":"portfolio-map"},{"depth":2,"text":"Current Maturity","id":"current-maturity"},{"depth":2,"text":"Technology Landscape","id":"technology-landscape"},{"depth":2,"text":"Strategic Roadmap (next 6–12 months)","id":"strategic-roadmap-next-6-12-months"},{"depth":2,"text":"Executive Summary","id":"executive-summary"}],"diagrams":3,"links":["index.md","architecture/principles.md","repos/shared-skills.md","repos/personalops.md","repos/website-intelligence-lab.md","repos/intelproducts.md","capabilities/README.md","capabilities/cap-website-assessment.md","capabilities/README.md","architecture/capability-reuse-map.md","decisions/0004-capability-architecture.md","governance/README.md","governance/capability-decision-framework.md","governance/capability-decision-matrix.md","governance/repository-lifecycle.md","governance/documentation-governance.md","governance/ai-governance.md","governance/architecture-review-lifecycle.md","decisions/0006-architecture-governance-framework.md","operating-model/README.md","operating-model/README.md","operating-model/knowledge-asset-lifecycle.md","operating-model/concept-ownership.md","operating-model/glossary.md","operating-model/context-architecture.md","operating-model/operating-principles.md","operating-model/ai-collaboration-model.md","architecture/architecture-review.md","architecture/architecture-risks.md","architecture/strategic-opportunities.md","architecture/architecture-evolution.md","decisions/0005-platform-services-and-consolidation.md","architecture/intelligence-platform.md#4--runtime-information-flow","capabilities/cap-website-assessment.md","repos/shared-skills.md","repos/personalops.md","repos/website-intelligence-lab.md","repos/intelproducts.md","capabilities/cap-website-assessment.md","../README.md","../skills/portfolio-portal-orchestrator/SPEC.md","architecture/intelligence-platform.md","architecture/system-of-systems.md","architecture/principles.md"],"body":"\n# Portfolio Overview — Executive Briefing\n\n> The single-page executive briefing for Azwaan's AI venture ecosystem. Read this first, then explore the\n> detailed [portal](/). It describes the layered architecture and marks honestly which layers are\n> **implemented**, **partial/planned**, or **vision** ([Architecture Principle 8](/architecture/principles)).\n>\n> **Realization note (recorded, evidence-based, 2026-07-05):** the portal now documents **four processed\n> systems** across the foundational layers — [Shared Skills](/repos/shared-skills),\n> [PersonalOps/FIP](/repos/personalops), [website-intelligence-lab](/repos/website-intelligence-lab),\n> and [intelproducts](/repos/intelproducts) — plus a **[Capability Architecture](/capabilities)**\n> layer and the first cross-repo platform capability,\n> **[Website Assessment](/capabilities/cap-website-assessment)** (spanning `inexisstudios` + the pack + FIP\n> + the lab). Downstream consumers `leadplatform`, `outreachagent`, and `inexisstudios` are registered.\n> Maturity labels come from direct source-doc evidence.\n\n> **New in Phase C — Capability Architecture.** The portal now documents reusable **capabilities**\n> independently of repositories: see the **[Capability Registry](/capabilities)** (a primary entry\n> point) and the **[Capability Reuse Map](/architecture/capability-reuse-map)**. This shifts the portal from\n> a repository catalogue to an architectural source of truth ([ADR 0004](/decisions/0004-capability-architecture)).\n\n> **Phase F — Architecture Governance.** The portal now also governs *how the ecosystem evolves*: the\n> **[Architecture Governance](/governance)** section defines the decision process, the\n> [Capability Decision Framework](/governance/capability-decision-framework) &\n> [Matrix](/governance/capability-decision-matrix), the [Repository Lifecycle](/governance/repository-lifecycle),\n> [Documentation Governance](/governance/documentation-governance), [AI Governance](/governance/ai-governance),\n> and the [Architecture Review Lifecycle](/governance/architecture-review-lifecycle) ([ADR 0006](/decisions/0006-architecture-governance-framework)).\n> Documentation only — no architecture modified.\n\n> **Phase E — Operating Model.** The portal now documents *how the ecosystem operates*, not just what exists:\n> the **[Operating Model](/operating-model)** section covers the\n> [work lifecycle](/operating-model), [Knowledge Asset Lifecycle](/operating-model/knowledge-asset-lifecycle),\n> [Concept Ownership](/operating-model/concept-ownership), the authoritative\n> [Portfolio Glossary](/operating-model/glossary), [Context Architecture](/operating-model/context-architecture),\n> [Operating Principles](/operating-model/operating-principles), and the\n> [AI Collaboration Model](/operating-model/ai-collaboration-model). This makes the portal the ecosystem's\n> operating manual. Documentation only — no architecture modified.\n\n> **Phase D — Ecosystem Architecture Review (recommendations only).** A holistic EA review is now available:\n> [Architecture Review](/architecture/architecture-review) · [Risks](/architecture/architecture-risks) ·\n> [Strategic Opportunities](/architecture/strategic-opportunities) ·\n> [Recommended Architecture Evolution](/architecture/architecture-evolution). Its headline proposal — a\n> **Platform Services layer** extracting reusable services out of venture repos — is captured as **proposed**\n> [ADR 0005](/decisions/0005-platform-services-and-consolidation). The layer model on this page is\n> **unchanged**; the review recommends, it does not modify.\n\n---\n\n## Vision\n\n**Purpose.** Build a compounding, multi-venture AI ecosystem where reusable intelligence flows from a shared\nfoundation up into products, applications, and customer-facing ventures — so each improvement at the base\nmultiplies value across everything above it.\n\n**The founder operates five venture areas** (`PersonalOps …/01-architecture.md`): **Inexis Digital\n(Victoria)** — AI & digital transformation for Victorian trades; **Inexis Consulting (Sri Lanka)** —\nenterprise architecture & AI consulting; **Inbound Lanka** — curated inbound travel; **City Retreats** —\nshort-stay rentals; and **Cross-Cutting** intelligence spanning all of them.\n\n**How the pieces fit.** A foundation of reusable AI skills feeds intelligence platforms; the platforms\nproduce versioned intelligence products; those power applications and agents; which drive the ventures and\ntheir customer-facing solutions — with a feedback loop so the system learns.\n\n---\n\n## Architecture Layers\n\n```mermaid\ngraph TD\n L6[6 · Customer-facing Solutions] --> OUT((Customers / Market))\n L5[5 · Ventures
Inexis Digital · Consulting · Inbound Lanka · City Retreats] --> L6\n L4[4 · Applications & Agents
leadplatform · outreachagent] --> L5\n L3[3 · Intelligence Products
intelproducts] --> L4\n L2[2 · Intelligence Platform
PersonalOps/FIP · website-intelligence-lab] --> L3\n L1[1 · Shared Skills
169 skills] --> L2\n SRC((Sources / knowledge estate / signals)) --> L2\n L1 -.reusable capability.-> L2 & L3 & L4 & L5 & L6\n\n classDef live fill:#1f7a1f,color:#fff,stroke:#0d4d0d;\n classDef partial fill:#fff3cd,color:#333,stroke:#b8860b;\n classDef planned fill:#eee,color:#333,stroke:#bbb,stroke-dasharray:4 3;\n class L1 live;\n class L2,L3,L4 partial;\n class L5,L6 planned;\n```\n\n| # | Layer | Responsibility | Realization (evidence) |\n|---|-------|----------------|------------------------|\n| 1 | **Shared Skills** | Manufactures & standardizes reusable AI capability (169 skills). | ✅ **Operational** |\n| 2 | **Intelligence Platform** | Turns raw knowledge/signals into structured, reusable intelligence. Two systems: **PersonalOps/FIP** (knowledge platform + dashboard) and **website-intelligence-lab** (engine evaluation). | 🔶 **Partial** — FIP design v1.0 + Phase 0; lab infra VPS-validated; core loops pending |\n| 3 | **Intelligence Products** | Publishes versioned, immutable intelligence **packs** (the output contract). `intelproducts`. | 🔶 **Operational as a contract** — packs published & consumed |\n| 4 | **Applications & Agents** | Software/agents that act on intelligence. `leadplatform`, `outreachagent`. | 🔶 **Partial** — outreachagent operational; leadplatform in-progress |\n| 5 | **Ventures** | The founder's five businesses built on the apps/agents. | 🧭 Vision (ventures exist as businesses; not yet portal-registered as repos) |\n| 6 | **Customer-facing Solutions** | The experiences customers touch. | 🧭 Vision |\n\n**How layers interact:** each layer consumes the layer(s) below and serves the layer above. **Shared Skills**\nis consumed *laterally by every layer* — the ecosystem's point of maximum leverage (Principle 9).\n\n---\n\n## Information Flow\n\nThe lifecycle of information through the ecosystem — see the detailed runtime flow in the\n[Intelligence Platform architecture](/architecture/intelligence-platform#4--runtime-information-flow).\n\n```mermaid\ngraph LR\n S[Sources
knowledge estate · captures · signals · website subjects] --> P[Intelligence Platform
capture → approve → structure → evaluate]\n P --> Pr[Intelligence Products
versioned, immutable packs]\n Pr --> A[Applications & Agents
pin packs → act → recommend]\n A --> C[Ventures & Customer-facing
proposals · outreach · deliverables]\n C -->|outcomes / usage signals| S\n SK[[Shared Skills]] -.capability at every step.-> P & Pr & A & C\n```\n\n1. **Sources** — the founder's *knowledge estate* (46 docs, ~4,600 lines) + captures + market signals; website subjects (lab).\n2. **Intelligence Platform** — capture → **human-approved** structuring into scoped, maturity-gated knowledge assets; reproducible engine evaluation (lab).\n3. **Intelligence Products** — distilled intelligence published as versioned, immutable packs.\n4. **Applications & Agents** — pin a pack version, act on it, emit recommendations (e.g. commercial-opportunity profiles).\n5. **Ventures / customer-facing** — proposals, outreach, and deliverables reach customers; outcomes return as new signals.\n\n---\n\n## Portfolio Map\n\n```mermaid\ngraph TD\n SS[shared-skills
169 skills · L1] -->|built with| PORTAL[portfolio-portal
docs/governance]\n SS -.-> FIP & LAB & IPR\n subgraph L2[Layer 2 · Intelligence Platform]\n FIP[personalops / FIP
producer + dashboard]\n LAB[website-intelligence-lab
engine evaluation]\n end\n IPR[intelproducts · L3
published packs]\n FIP --> IPR\n IPR -->|website-assessment pack| INX[inexisstudios · L4
assessment engine]\n IPR -->|pinned submodule| LEAD[leadplatform · L4]\n INX -->|COP| OA[outreachagent · L4]\n IPR --> OA\n INX & LEAD & OA --> VEN[Ventures · L5
Inexis Digital · Consulting · Inbound Lanka · City Retreats]\n PORTAL -.will be automated by.-> ORCH[[portfolio-portal-orchestrator · spec]]\n```\n\n**First reusable platform capability:** the **[Website Assessment Platform](/capabilities/cap-website-assessment)** —\none capability composed from four repos (`inexisstudios` engine + `intelproducts` pack + FIP authoring + the\nlab harness), consumed by `outreachagent` (and, declared, `leadplatform`) as Inexis Digital's lead-gen wedge.\n\n| Repository | Layer | Purpose | Maturity | Digest |\n|------------|-------|---------|----------|--------|\n| **shared-skills** | 1 Shared Skills | Reusable AI capability library (169 skills) | Operational | [digest](/repos/shared-skills) |\n| **personalops** | 2 Intelligence Platform | FIP — knowledge intelligence platform + dashboard (producer) | Early-development | [digest](/repos/personalops) |\n| **website-intelligence-lab** | 2 Intelligence Platform | Website engine experimentation & evaluation | Early-development | [digest](/repos/website-intelligence-lab) |\n| **intelproducts** | 3 Intelligence Products | Versioned, immutable intelligence packs | Operational (contract) | [digest](/repos/intelproducts) |\n| **inexisstudios** | 4 Applications & Agents | Website Assessment engine (crawler + scoring + report) | Active development | [capability](/capabilities/cap-website-assessment) |\n| **leadplatform** | 4 Applications & Agents | Lead platform; consumes packs (pinned submodule) | In-progress | *not yet processed* |\n| **outreachagent** | 4 Applications & Agents | Outreach agent; COP recommendations | Operational | *not yet processed* |\n| **portfolio-portal** | Docs / Governance | Documents the system of systems (this repo) | Active (Phase B) | [README](/readme) |\n| *portfolio-portal-orchestrator* | Docs / Automation | Future skill to automate the portal | Spec only | [spec](/skills/portfolio-portal-orchestrator/SPEC) |\n\n---\n\n## Current Maturity\n\nScale: **Concept → Early Development → Active Development → Operational → Production.**\n\n| System | Maturity | Rationale (evidence) |\n|--------|----------|----------------------|\n| **shared-skills** | Operational | 169 versioned, licensed skills in active use; built this portal. |\n| **personalops / FIP** | Early Development | Design v1.0 approved; Phase 0 built (Supabase schema, seed, TS, harvest scripts, dashboard rendering); Phases 1–5 not started. |\n| **website-intelligence-lab** | Early Development | Phase 1–2 complete & VPS-validated; Phase 2.5 in progress; core loop (adapter/runs/eval) pending. |\n| **intelproducts** | Operational (contract) | Multiple packs published across 4 domains, already consumed by leadplatform + outreachagent. |\n| **inexisstudios (Website Assessment engine)** | Active Development | Engine core built & self-tests pass (40/40); async crawl→score→report + external API shipped; durable queueing, competitor benchmarking, public form = future phases. *(evidence hunt)* |\n| **outreachagent** | Operational | Steps 1–5 + renderers + operational layer done; live end-to-end run completed; assessment runs **mock by default**, live-send/live-assessment toggles pending. *(evidence hunt)* |\n| **leadplatform** | Active Development | Phase 1 Next.js MVP + Phase 2 Cloudflare Worker/D1 + live Upwork OAuth working; website-assessment consumption declared, not wired. *(evidence hunt)* |\n| **portfolio-portal** | Active Development | Phase B underway. |\n| **Ventures / Customer-facing** | Concept (in portal) | Real businesses, but not yet represented as portal-registered repos. |\n\n---\n\n## Technology Landscape\n\nNow largely **evidenced** (not merely implied). Architectural summary, not an exhaustive inventory.\n\n| Category | Technologies | Evidence |\n|----------|-------------|----------|\n| **AI runtime / agents** | Anthropic Claude (Agent Skills, Agent SDK, Claude Code); Codex; OpenClaw (self-hosted, planned) | shared-skills, PersonalOps FIP audience |\n| **Skill/content medium** | Markdown (`SKILL.md`, packs, knowledge estate) | shared-skills, intelproducts, PersonalOps |\n| **Data / backend** | Supabase (PostgreSQL, RLS, RPC) — FIP canonical store | PersonalOps `01-architecture.md` |\n| **Web app / UI** | TanStack Router/Start + TanStack Query, React 19, Vite 7, Tailwind v4, shadcn/Radix, TypeScript | PersonalOps `ka.*.tsx`; inexisstudios |\n| **Edge / infra** | Cloudflare (DNS, Workers, **Pages**, **D1**, **R2**), Docker Compose, Caddy 2.11.4, Let's Encrypt | website-intelligence-lab, leadplatform, inexisstudios |\n| **Crawling / automation** | Playwright (standalone Node crawler-service) | inexisstudios `crawler-service/` |\n| **CMS / backend (lab)** | WordPress 6.9 Multisite (php8.3), MariaDB 11.4, WP-CLI | website-intelligence-lab |\n| **Scripting / pipelines** | Node/JS (harvest, extract, estate-map), Python (skills), Shell | PersonalOps scripts, shared-skills |\n| **Distribution** | Git submodules for pinned pack contracts | leadplatform vendors intelproducts |\n| **Retrieval** | Postgres FTS (`search_assets` RPC); pgvector = post-MVP | PersonalOps non-goals |\n\n---\n\n## Strategic Roadmap (next 6–12 months)\n\n| Theme | Direction |\n|-------|-----------|\n| **Platform evolution** | Build FIP Phases 1–5 (capture → harvest UI → AI classification → legacy → agent ingestion + OpenClaw); stand up the lab's core loop (adapter → runs → evaluation). |\n| **Intelligence improvements** | Expand pack domains; implement the **Hermes** learning loop once outcome data exists; add semantic search at asset scale. |\n| **Automation** | Implement `portfolio-portal-orchestrator` so the portal maintains itself from source repos. |\n| **Customer products** | Mature leadplatform + outreachagent into reliable revenue engines across the ventures. |\n| **Internal tooling** | Skills taxonomy/index; consolidate duplicated skills; full digests for leadplatform/outreachagent. |\n| **Showcase & commercialisation** | Build the public showcase (Phase C) demonstrating ecosystem scale & sophistication. |\n\n---\n\n## Executive Summary\n\nAzwaan runs a **multi-venture AI ecosystem** — Inexis Digital, Inexis Consulting, Inbound Lanka, and City\nRetreats — organized as a **layered architecture** so intelligence compounds from a shared foundation up to\ncustomer-facing work.\n\nThe **foundations are real**. A curated library of **169 AI skills** (Shared Skills, operational) is the base.\nAbove it, an **Intelligence Platform** turns the founder's knowledge estate into structured, retrievable\nintelligence — the **Founder Intelligence Platform** (design-complete with a built Phase-0 foundation and a\nworking Intelligence Dashboard) alongside a **Website Intelligence Lab** (a provenanced evaluation platform\nwhose infrastructure is live). That platform publishes **intelligence products** — versioned, immutable packs\nthat are **already consumed** by downstream apps (`leadplatform`, `outreachagent`) to generate proposals,\noutreach, and commercial-opportunity recommendations.\n\nMaturity is mixed and **labelled honestly**: some systems are operational, others are design-plus-foundation.\nNamed-but-unbuilt elements — the **Hermes** learning loop and **OpenClaw** integration — are marked planned,\nand one requested concept, **\"estate generation,\" does not exist** and is recorded as such rather than\ninvented. The next 6–12 months are about **building upward**: completing the platform's capture-to-retrieval\nloop, standing up the lab's evaluation loop, automating this portal, and hardening the customer-facing apps.\n\n**For a new engineer, architect, investor, or client:** start here, then read the\n[Intelligence Platform architecture](/architecture/intelligence-platform) for the platform in depth, the\n[system-of-systems architecture](/architecture/system-of-systems) for how everything connects, and the\n[Architecture Principles](/architecture/principles) that govern it all.\n"},{"id":"/registry/repo-registry","kind":"page","entityType":"registry","title":"Repo Registry","route":"/registry/repo-registry","sourcePath":"portal/registry/repo-registry.md","slug":null,"frontmatter":{"title":"Repo Registry","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The canonical index of every repository in the ecosystem. Every repo digest in","headings":[{"depth":2,"text":"Column contract","id":"column-contract"},{"depth":2,"text":"Adding a repo","id":"adding-a-repo"}],"diagrams":0,"links":["../ventures/shared-skills.md","../repos/shared-skills.md","../ventures/intelligence-platform.md","../repos/personalops.md","../ventures/intelligence-platform.md","../repos/website-intelligence-lab.md","../ventures/intelligence-platform.md","../repos/intelproducts.md","../capabilities/cap-website-assessment.md","../capabilities/cap-website-assessment.md","../../docs/update-conventions.md"],"body":"\n# Repo Registry\n\nThe **canonical index of every repository** in the ecosystem. Every repo digest in\n[`portal/repos/`](../repos/) MUST have exactly one row here (no orphans, no duplicates). This table\nis the source the future orchestrator and `llms.txt` are kept in sync with.\n\n\n| Repo (slug) | System | Layer | Lifecycle | Maturity | Language(s) | Digest | Source | Last reviewed |\n|-------------|--------|-------|-----------|----------|-------------|--------|--------|---------------|\n| `shared-skills` | [shared-skills](/ventures/shared-skills) | Shared Skills | active | operational | Markdown, Python, TS, Shell | [digest](/repos/shared-skills) | private (`~/.claude/skills`) | 2026-07-05 |\n| `personalops` | [intelligence-platform](/ventures/intelligence-platform) | Intelligence Platform | active | early-development | TypeScript, SQL (Supabase), JS | [digest](/repos/personalops) | private | 2026-07-05 |\n| `website-intelligence-lab` | [intelligence-platform](/ventures/intelligence-platform) | Intelligence Platform | active | early-development | YAML, Shell, Docker, PHP (WP) | [digest](/repos/website-intelligence-lab) | private | 2026-07-05 |\n| `intelproducts` | [intelligence-platform](/ventures/intelligence-platform) | Intelligence Products | active | operational | Markdown (packs), SKILL.md | [digest](/repos/intelproducts) | private | 2026-07-05 |\n| `inexisstudios` | website-assessment | Applications & Agents | active | active-development | TanStack Start/React 19, TS, Cloudflare Pages/D1/R2, Playwright | via [capability](/capabilities/cap-website-assessment) | private | 2026-07-05 |\n| `leadplatform` | intelligence consumers | Applications & Agents | active | in-progress | TypeScript (Next.js), Cloudflare Worker/D1 | *not yet processed* | private | 2026-07-05 |\n| `outreachagent` | intelligence consumers | Applications & Agents | active | operational | TypeScript | *not yet processed* | private | 2026-07-05 |\n\n\n> **Documented at capability level (recorded honestly):** `inexisstudios` is the **Website Assessment\n> engine** (marketing site + CMS + assessment product). It is documented via the\n> [Website Assessment Platform capability](/capabilities/cap-website-assessment) rather than a full repo\n> digest for now.\n>\n> **Not yet fully processed:** `leadplatform` and `outreachagent` are **downstream consumers** of the\n> Intelligence Platform (they pin/consume `intelproducts`; `outreachagent` also consumes Website Assessment).\n> Registered for dependency-map completeness; full digests are a future task. Maturity noted from the evidence\n> hunt, not a full review.\n\n## Column contract\n\n| Column | Meaning | Allowed values |\n|--------|---------|----------------|\n| Repo (slug) | Stable slug = digest filename | lowercase-hyphenated |\n| System | Owning system/venture slug | must match a `portal/ventures/*` |\n| Layer | Architecture layer | Shared Skills / Intelligence Platform / Intelligence Products / Applications & Agents / Ventures / Customer-facing Solutions / Docs |\n| Lifecycle | Maturity (operational) | idea / prototype / active / maintenance / deprecated / archived |\n| Maturity | Assessment | concept / early-development / active-development / operational / production |\n| Language(s) | Primary languages | free text or `Unknown` |\n| Digest | Link to the repo digest | `../repos/.md` |\n| Source | Repo URL or `private` | url / `private` |\n| Last reviewed | Date the row was verified | `YYYY-MM-DD` |\n\n## Adding a repo\n\nFollow \"Recipe: add a repo\" in [update conventions](/about/update-conventions). Add the row\nhere **and** create the digest — the two must always agree.\n"},{"id":"/repos","kind":"page","entityType":"doc","title":"Repos","route":"/repos","sourcePath":"portal/repos/README.md","slug":null,"frontmatter":{"title":"Repos","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"One digest per repository. A digest is the canonical one-pager that summarizes a repo, explains","headings":[{"depth":2,"text":"Digests","id":"digests"},{"depth":3,"text":"Layer 1 — Shared Skills","id":"layer-1-shared-skills"},{"depth":3,"text":"Layer 2 — Intelligence Platform","id":"layer-2-intelligence-platform"},{"depth":3,"text":"Layer 3 — Intelligence Products","id":"layer-3-intelligence-products"},{"depth":3,"text":"Layer 4 — Applications & Agents","id":"layer-4-applications-agents"},{"depth":3,"text":"Docs / Governance","id":"docs-governance"}],"diagrams":0,"links":["../registry/repo-registry.md","../../templates/repo-digest.template.md","../../docs/update-conventions.md#recipe-add-a-repo","shared-skills.md","personalops.md","website-intelligence-lab.md","intelproducts.md","../capabilities/cap-website-assessment.md","../capabilities/README.md","../decisions/0004-capability-architecture.md","../../README.md"],"body":"\n# Repos\n\nOne **digest** per repository. A digest is the canonical one-pager that summarizes a repo, explains\nwhat it does and why it exists, and links back to its source.\n\n- **Index of record:** [Repo registry](/registry/repo-registry)\n- **Template / standard:** [`templates/repo-digest.template.md`](../../templates/repo-digest.template.md)\n (the standard is set by the Shared Skills digest below)\n- **How to add one:** [update conventions](/about/update-conventions#recipe-add-a-repo)\n\n## Digests\n\n\n### Layer 1 — Shared Skills\n- [`shared-skills`](/repos/shared-skills) — reusable AI Agent Skills library (169 skills). **Reference digest / standard.**\n\n### Layer 2 — Intelligence Platform\n- [`personalops`](/repos/personalops) — Founder Intelligence Platform (FIP) + Intelligence Dashboard (producer).\n- [`website-intelligence-lab`](/repos/website-intelligence-lab) — website engine experimentation & evaluation platform.\n\n### Layer 3 — Intelligence Products\n- [`intelproducts`](/repos/intelproducts) — published, versioned intelligence packs.\n\n### Layer 4 — Applications & Agents\n- `inexisstudios` — Website Assessment **engine**; documented via the [Website Assessment capability](/capabilities/cap-website-assessment); full repo digest pending.\n- `leadplatform` — ⏳ registered as a downstream consumer; full digest pending.\n- `outreachagent` — ⏳ registered as a downstream consumer; full digest pending.\n\n> See also the **[Capability Registry](/capabilities)** — capabilities are documented\n> independently of repos ([ADR 0004](/decisions/0004-capability-architecture)).\n\n### Docs / Governance\n- `portfolio-portal` — this repo (see root [README](/readme); no self-digest needed).\n\n\n> **TODO:** Full digests for `leadplatform` and `outreachagent` (layer 4); register layer-5 ventures.\n"},{"id":"/repos/intelproducts","kind":"page","entityType":"repository","title":"intelproducts — Intelligence Products","route":"/repos/intelproducts","sourcePath":"portal/repos/intelproducts.md","slug":"intelproducts","frontmatter":{"title":"intelproducts — Intelligence Products","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"intelproducts","system":"intelligence-products","layer":"Intelligence Products","repo_url":"private (local git repo — Documents/github/intelproducts)","lifecycle":"active","maturity":"operational"},"excerpt":"platform that produces them.\" (README.md). It holds intelligence-packs/ (the data — versioned,","headings":[{"depth":2,"text":"What it is","id":"what-it-is"},{"depth":2,"text":"Why it exists","id":"why-it-exists"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Business capability provided","id":"business-capability-provided"},{"depth":2,"text":"Technical responsibilities","id":"technical-responsibilities"},{"depth":2,"text":"Core concepts","id":"core-concepts"},{"depth":2,"text":"Key workflows","id":"key-workflows"},{"depth":2,"text":"Technologies used","id":"technologies-used"},{"depth":2,"text":"Major modules / components — pack families","id":"major-modules-components-pack-families"},{"depth":2,"text":"Capabilities","id":"capabilities"},{"depth":2,"text":"Upstream dependencies","id":"upstream-dependencies"},{"depth":2,"text":"Downstream consumers","id":"downstream-consumers"},{"depth":2,"text":"Major interfaces & integration points","id":"major-interfaces-integration-points"},{"depth":2,"text":"Reusable assets exposed to other repositories","id":"reusable-assets-exposed-to-other-repositories"},{"depth":2,"text":"Architectural decisions","id":"architectural-decisions"},{"depth":2,"text":"Architecture snapshot","id":"architecture-snapshot"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Roadmap","id":"roadmap"},{"depth":2,"text":"Known limitations","id":"known-limitations"},{"depth":2,"text":"Future opportunities","id":"future-opportunities"},{"depth":2,"text":"Relationship to the wider AI venture ecosystem","id":"relationship-to-the-wider-ai-venture-ecosystem"},{"depth":2,"text":"Links","id":"links"}],"diagrams":1,"links":["personalops.md","../ventures/intelligence-platform.md#layer-3--intelligence-products","personalops.md","personalops.md","shared-skills.md","../decisions/0003-intelligence-platform-layer-model.md","../architecture/intelligence-platform.md","../portfolio-overview.md","../architecture/intelligence-platform.md","personalops.md","../registry/repo-registry.md"],"body":"\n# intelproducts — Intelligence Products — Repo Digest\n\n> The **published output contract** of the Intelligence Platform: versioned, immutable intelligence\n> **packs** that downstream repos consume. Produced by [PersonalOps/FIP](/repos/personalops); this is\n> **layer 3** (Intelligence Products) in the ecosystem model.\n\n\n## What it is\n*\"Published **intelligence products** for the Inexis / PersonalOps ecosystem, kept separate from the\nplatform that produces them.\"* (`README.md`). It holds `intelligence-packs/` (the **data** — versioned,\nimmutable, machine-consumable packs) and `skills/` (**consumer skills** that consuming repos use to act on\nthe packs).\n\n## Why it exists\nDownstream applications need a **stable, versioned intelligence contract**, not ad-hoc copies of the\nfounder's knowledge. Separating the *published products* from the *platform that produces them* lets\nconsumers **pin a version** and treat intelligence as an immutable dependency — additive changes land as\n`v1.x` in place, structural changes as a new `v2` directory. This is the ecosystem's\n\"knowledge referenced, never owned\" principle made concrete.\n\n\n## At a glance\n\n| Field | Value |\n|-------|-------|\n| Slug | `intelproducts` |\n| System | [`intelligence-products`](/ventures/intelligence-platform#layer-3--intelligence-products) |\n| Architecture layer | `Intelligence Products` (layer 3) |\n| Lifecycle | `active` |\n| Maturity | `operational` (as a data contract — packs published & consumed) |\n| Structure | `intelligence-packs/` (data) + `skills/` (consumer skills) |\n| Producer | [PersonalOps/FIP](/repos/personalops) (authors; does not consume) |\n| Consumers | `leadplatform` (pinned submodule), `outreachagent` |\n| Last reviewed | 2026-07-05 |\n\n\n## Business capability provided\n**Intelligence as a versioned, immutable product** — a machine-consumable contract that turns the\nplatform's knowledge into dependable inputs for apps and agents.\n\n## Technical responsibilities\n- Hold **immutable, versioned packs** grouped by domain.\n- Provide **consumer skills** that operate on the packs.\n- Preserve the **Stage-1 → Stage-3 contract** each pack encodes.\n- Enforce versioning discipline (additive → in place; structural → new version dir).\n- **Not**: producing intelligence (that's FIP), or consuming it.\n\n## Core concepts\n| Concept | Meaning |\n|---------|---------|\n| **Intelligence pack** | Versioned, immutable, machine-consumable knowledge product for a domain. |\n| **Consumer skill** | A skill a consuming repo vendors/uses to act on a pack. |\n| **Pin a version** | Consumers depend on an exact pack version (contract stability). |\n| **Producer/consumer split** | PersonalOps authors; consuming repos consume; the two never mix. |\n\n## Key workflows\n1. **Publish** — PersonalOps builder skills author a pack and publish it here (immutable).\n2. **Pin & consume** — a consuming repo pins a pack version and uses the matching consumer skill.\n3. **Evolve** — re-run the builder skill in PersonalOps; publish the next version (never edit in place structurally).\n\n## Technologies used\n- **Markdown + structured pack files** (manifests, rule-packs, runtime-packs, corpus, runs).\n- Distributed to consumers via **git submodule** (e.g. `leadplatform/vendor/intelproducts`).\n- Consumer **skills** in the Agent Skills format (`SKILL.md`).\n\n## Major modules / components — pack families\n| Domain | Pack | Consumer skill(s) |\n|--------|------|-------------------|\n| `proposal/` | `proposal-pack-v1/` (+ `corpus/`, `runs/`) | `proposal-generator` (used by leadplatform) |\n| `website-assessment/` | `website-assessment-pack-v1/`, rule-packs, runtime-packs, industry packs (cleaning, travel) | — |\n| `cinnamon-stories/` | `sri-lanka-journey-architecture-pack-v1/` | — |\n| `outreach-messaging/` | `outreach-messaging-pack-v1/` | `first-touch-email`, `follow-up-email`, `website-replacement-proposal`, `findings-translator`, `commercial-opportunity` (used by outreachagent) |\n\n## Capabilities\n- `intelligence-packaging` · `versioned-contract` · `consumer-skills`\n\n## Upstream dependencies\n\n| Dependency | Type | Version | Notes |\n|------------|------|---------|-------|\n| [PersonalOps/FIP](/repos/personalops) | internal-repo | n/a | Authors the packs (producer) |\n| [Shared Skills](/repos/shared-skills) | internal-repo | n/a | Builder skill `intelligence-pack-publisher` + consumer-skill format |\n\n\n## Downstream consumers\n- **`leadplatform`** — vendors this repo as a **pinned git submodule** (`vendor/intelproducts`, read-only\n contract); uses `proposal-generator`.\n- **`outreachagent`** — consumes `outreach-messaging` skills → commercial-opportunity recommendations.\n- **OpenClaw / Hermes / MCP consumers** — named as **future** programmatic consumers in `pack-manifest.md`.\n\n## Major interfaces & integration points\n- **Consumes:** published packs from PersonalOps.\n- **Exposes:** immutable versioned **packs** (data) + **consumer skills** (behaviour) — the read-only\n contract downstream repos pin.\n\n## Reusable assets exposed to other repositories\n- The **intelligence packs** themselves (proposal, website-assessment, cinnamon-stories, outreach-messaging).\n- The **consumer skills** that act on them.\n- The **pack contract & versioning convention** (immutable, pin-a-version).\n\n## Architectural decisions\n- **Products are separated from the platform that produces them** (producer/consumer split).\n- **Packs are immutable and versioned** (additive vs structural change rule).\n- Portal-level modelling: [ADR 0003](/decisions/0003-intelligence-platform-layer-model).\n\n## Architecture snapshot\n\n```mermaid\ngraph LR\n FIP[PersonalOps/FIP
builder skills] -->|publish immutable| PK[(intelligence-packs
versioned)]\n PK --> SK[consumer skills]\n PK -->|pinned submodule| LEAD[leadplatform]\n SK --> OA[outreachagent]\n PK -.future.-> OC[OpenClaw / MCP]\n```\n\n## Current maturity\n**Operational (as a data contract).** Rationale: multiple packs are published across four domains and are\n**already consumed** by `leadplatform` (pinned submodule) and `outreachagent`. It is \"operational\" in the\ncontract sense — a stable, versioned dependency — rather than a running service. *(Source: `README.md`,\nconsumer repos.)*\n\n## Roadmap\n- New pack domains as the knowledge estate grows; new versions as builder skills evolve.\n- Wire **OpenClaw / Hermes / MCP** programmatic consumers (future, per `pack-manifest.md`).\n\n## Known limitations\n- Packs are only as fresh as the last builder run in PersonalOps (no live sync).\n- Some domains have packs but **no consumer skill yet** (website-assessment, cinnamon-stories).\n- Value depends on downstream discipline in pinning versions.\n\n## Future opportunities\n- MCP-server access to packs for agent consumers.\n- Feedback of consumption outcomes into pack quality (the future **Hermes** loop).\n\n## Relationship to the wider AI venture ecosystem\n**Layer 3 (Intelligence Products)** — the published output of the Intelligence Platform (layer 2), consumed\nby Applications & Agents (layer 4) and, through them, the Ventures (layer 5). See\n[Intelligence Platform architecture](/architecture/intelligence-platform) and the\n[Portfolio Overview](/overview).\n\n## Links\n- Source: local git repo `intelproducts` (private)\n- Platform doc: [Intelligence Platform](/architecture/intelligence-platform)\n- Producer: [PersonalOps/FIP](/repos/personalops)\n- Registry row: [repo registry](/registry/repo-registry)\n"},{"id":"/repos/personalops","kind":"page","entityType":"repository","title":"PersonalOps — Founder Intelligence Platform","route":"/repos/personalops","sourcePath":"portal/repos/personalops.md","slug":"personalops","frontmatter":{"title":"PersonalOps — Founder Intelligence Platform","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"personalops","system":"intelligence-platform","layer":"Intelligence Platform","repo_url":"private (local git repo — Documents/github/PersonalOps/PersonalOps)","lifecycle":"active","maturity":"early-development"},"excerpt":"A structured knowledge-management platform — the Founder Intelligence Platform (FIP) — that \"extracts,","headings":[{"depth":2,"text":"What it is","id":"what-it-is"},{"depth":2,"text":"Why it exists","id":"why-it-exists"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Business capability provided","id":"business-capability-provided"},{"depth":2,"text":"Technical responsibilities","id":"technical-responsibilities"},{"depth":2,"text":"Core concepts","id":"core-concepts"},{"depth":2,"text":"Key workflows","id":"key-workflows"},{"depth":2,"text":"Technologies used","id":"technologies-used"},{"depth":2,"text":"Major modules / components","id":"major-modules-components"},{"depth":2,"text":"Capabilities","id":"capabilities"},{"depth":2,"text":"Upstream dependencies","id":"upstream-dependencies"},{"depth":2,"text":"Downstream consumers","id":"downstream-consumers"},{"depth":2,"text":"Major interfaces & integration points","id":"major-interfaces-integration-points"},{"depth":2,"text":"Reusable assets exposed to other repositories","id":"reusable-assets-exposed-to-other-repositories"},{"depth":2,"text":"Architectural decisions","id":"architectural-decisions"},{"depth":2,"text":"Architecture snapshot","id":"architecture-snapshot"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Roadmap","id":"roadmap"},{"depth":2,"text":"Known limitations","id":"known-limitations"},{"depth":2,"text":"Future opportunities","id":"future-opportunities"},{"depth":2,"text":"Relationship to the wider AI venture ecosystem","id":"relationship-to-the-wider-ai-venture-ecosystem"},{"depth":2,"text":"Links","id":"links"}],"diagrams":1,"links":["../architecture/intelligence-platform.md","../ventures/intelligence-platform.md","intelproducts.md","shared-skills.md","intelproducts.md","../decisions/0003-intelligence-platform-layer-model.md","../architecture/principles.md","shared-skills.md","intelproducts.md","../architecture/intelligence-platform.md","../portfolio-overview.md","../ventures/intelligence-platform.md","../architecture/intelligence-platform.md","../registry/repo-registry.md"],"body":"\n# PersonalOps — Founder Intelligence Platform (FIP) — Repo Digest\n\n> The **producer** at the heart of the Intelligence Platform layer, and the home of the existing\n> **Intelligence Dashboard**. Platform-level view (4 architecture diagrams, subsystem map) lives in\n> [architecture/intelligence-platform.md](/architecture/intelligence-platform).\n\n\n## What it is\nA structured knowledge-management platform — the **Founder Intelligence Platform (FIP)** — that *\"extracts,\nstores, and retrieves actionable intelligence from a multi-venture founder's knowledge estate. It\ntransforms unstructured markdown documents and ad-hoc intelligence captures into a queryable,\nAI-accessible asset library.\"* (`docs/founder-intelligence-platform/01-architecture.md`). PersonalOps also\nhosts the **Intelligence Dashboard** (a TanStack Router app rendering markdown + Supabase asset sections).\n\n## Why it exists\n*\"The layer between raw knowledge documents and the AI agents and workflows that use that knowledge to\nproduce output.\"* A founder accumulates intelligence continuously but loses it inside un-queryable\ndocuments. FIP makes every material insight a **retrievable, scoped asset an AI agent can pull on demand**\n— and publishes distilled intelligence as versioned products for downstream apps. Its hardest problem is\n**capture**, not retrieval (Principle 9: capture first).\n\n\n## At a glance\n\n| Field | Value |\n|-------|-------|\n| Slug | `personalops` |\n| System | [`intelligence-platform`](/ventures/intelligence-platform) |\n| Architecture layer | `Intelligence Platform` (layer 2) — the producer |\n| Lifecycle | `active` |\n| Maturity | `early-development` (design v1.0 approved; Phase 0 built; Phases 1–5 not started) |\n| Data store | Supabase PostgreSQL (`knowledge_assets` canonical) |\n| UI | TanStack Router (existing PersonalOps app) — the Intelligence Dashboard |\n| Knowledge estate | 46 registered markdown docs (~4,600 lines) |\n| Serves ventures | Inexis Digital, Inexis Consulting, Inbound Lanka, City Retreats, Cross-Cutting |\n| Last reviewed | 2026-07-05 |\n\n\n## Business capability provided\n**Founder intelligence as a queryable, AI-accessible asset library** — turning scattered knowledge into\nscoped, maturity-gated intelligence that both the founder and AI agents can retrieve, and into published\nintelligence products downstream ventures consume.\n\n## Technical responsibilities\n- Own the **canonical intelligence store** (`knowledge_assets`) — one place, no duplication (Principle 4).\n- Run **capture → stage → human-approve → structure** workflows across all sources.\n- Run the **extraction/harvest pipeline** (docs → candidates).\n- Provide **scoped retrieval** via the `search_assets()` RPC.\n- Render the **Intelligence Dashboard** (markdown + Supabase asset sections; Principle 11).\n- **Author intelligence packs** (via builder skills) for publication to `intelproducts`.\n- Explicitly **not**: auto-approve, write markdown directly, or act as a public/multi-tenant product.\n\n## Core concepts\n| Concept | Meaning |\n|---------|---------|\n| **Knowledge estate** | The founder's corpus of markdown docs + captures — the input source. |\n| **Knowledge asset** | A structured, scoped, maturity-gated record in `knowledge_assets` — the canonical intelligence. |\n| **Maturity** | `working → ready → proven → archived`; only ready/proven are external-facing (Principle 3). |\n| **Scope dimensions** | venture · industry · market · capability · use-case (independent lookup tables, many-to-many). |\n| **Human approval** | Mandatory gate to any asset — no auto-approve path (Principle 2). |\n| **Markdown ⇄ Supabase boundary** | Documents = narrative context; assets = structured retrieval (never conflate). |\n\n## Key workflows\n1. **Capture** — manual form / voice / article / agent research / legacy KB → staging queues.\n2. **Harvest/extract** — scripts turn documents into `harvest_candidates`.\n3. **Review & approve** — founder approves each candidate/capture (mandatory).\n4. **Structure** — approved intelligence becomes a scoped, maturity-tagged `knowledge_asset`.\n5. **Retrieve** — `search_assets()` filters by type/maturity/scope/free-text for 8 retrieval use cases\n (proposal gen, marketing, strategy, solution design, opportunity eval, agent context injection, lead\n qualification, website assessment).\n6. **Synthesise & publish** — builder skills author versioned packs to [`intelproducts`](/repos/intelproducts).\n\n## Technologies used\n- **Data:** Supabase (PostgreSQL) — `knowledge_assets` + 5 lookup + 5 join + staging + registry tables + `search_assets()` RPC; RLS.\n- **App/UI:** TanStack Router + TanStack Query, TypeScript (`src/lib/ka.ts`, `src/routes/ka.*.tsx`).\n- **Pipelines:** Node/JS harvest & extraction scripts (`harvest-os.js`, `extract-pdf.js`, `capability-harvest/`, `estate-map.mjs`).\n- **Content:** Git markdown (`content-intelligence/`, `docs/`).\n- Retrieval is **FTS** for MVP; vector/pgvector is post-MVP (non-goal now).\n\n## Major modules / components\n| Component | Responsibility |\n|-----------|----------------|\n| Presentation (`/ka`, `/ka/capture`, `/ka/review`, `/ka/harvest`, `/ka/legacy`) | Intelligence Dashboard + workflow UIs |\n| Data layer (Supabase) | Canonical `knowledge_assets` + scope/lookup/staging/registry |\n| Extraction/harvest pipeline | Documents → candidates (✅ scripts exist) |\n| Builder skills | Author intelligence packs from assets |\n| Knowledge estate (markdown) | Read-only narrative source |\n\n## Capabilities\n- `knowledge-capture` · `document-extraction` · `intelligence-structuring` · `scoped-retrieval`\n- `intelligence-dashboard` · `pack-authoring` (producer of intelligence products)\n\n## Upstream dependencies\n\n| Dependency | Type | Version | Notes |\n|------------|------|---------|-------|\n| Knowledge estate (markdown) | internal | 46 docs | Read-only source of truth for narrative |\n| Supabase (PostgreSQL) | external-service | — | Canonical data store |\n| [Shared Skills](/repos/shared-skills) | internal-repo | n/a | Builder skill `intelligence-pack-publisher`, others |\n| Claude / Codex / OpenClaw agents | external-service | — | Implementation & (future) ingestion agents |\n\n\n## Downstream consumers\n- [`intelproducts`](/repos/intelproducts) — receives the **published packs** this platform authors.\n- `leadplatform`, `outreachagent` — consume packs (downstream of intelproducts). *(Layer 4.)*\n- `OpenClaw` — **planned** programmatic consumer (FIP Phase 5, not started).\n- The founder's ventures (Inexis Digital, Consulting, Inbound Lanka, City Retreats) via retrieval.\n\n## Major interfaces & integration points\n- **Consumes:** knowledge estate (read-only), Supabase, Shared Skills.\n- **Exposes:** `search_assets()` RPC (scoped retrieval); the Intelligence Dashboard; **published intelligence\n packs** (to `intelproducts`); `doc_update_suggestions` (suggested, human-applied — never auto-written).\n\n## Reusable assets exposed to other repositories\n- The **published intelligence packs** (via `intelproducts`) — the primary reusable output.\n- The **knowledge model + Supabase schema** (a reusable pattern for founder/knowledge intelligence).\n- The **Intelligence Dashboard rendering model** (markdown + asset + hybrid sections).\n\n## Architectural decisions\nFIP records ADRs in `docs/founder-intelligence-platform/06-decisions.md` and 11 architectural principles in\n`01-architecture.md`. The portal-level modelling decision is [ADR 0003](/decisions/0003-intelligence-platform-layer-model).\nSeveral FIP principles seed the ecosystem [Architecture Principles](/architecture/principles)\n(intelligence-over-documents, human-approval-mandatory, one-canonical-store).\n\n## Architecture snapshot\n\n```mermaid\ngraph TD\n EST[[Knowledge Estate
markdown]] --> HARV[Extraction/harvest ✅]\n SRC[Captures · voice · research · legacy] --> Q[/staging queues/]\n HARV --> Q\n Q --> REV{Human approval ✅}\n REV -->|approve| KA[(knowledge_assets
scoped × maturity)]\n KA --> RPC[search_assets RPC]\n RPC --> DASH[Intelligence Dashboard + agents]\n KA --> PACKS[(Published packs → intelproducts)]\n```\n\n## Current maturity\n**Early-development.** Rationale (evidence): FIP design is **v1.0, approved, June 2026**; **Phase 0 is\ncomplete** (Supabase migration + seed + TS foundation, harvest/extraction scripts, estate-map, dashboard\nmarkdown rendering). **Phases 1–5 are not started** (asset library, capture, review queue, harvest UI, AI\nclassification, legacy migration, agent ingestion + OpenClaw). So the design and foundation exist and some\npipeline code runs, but the core product surfaces are unbuilt. *(Source: `.../README.md` status table.)*\n\n## Roadmap\nPhase 1 asset library + capture + review queue → Phase 2 document harvest + coverage dashboard → Phase 3\nAI classification + doc-update suggestions → Phase 4 legacy migration → Phase 5 agent ingestion + OpenClaw\nintegration. Post-MVP: asset relationships graph, pgvector semantic search, automated doc updates,\nthird-party source ingestion. *(Source: `01-architecture.md` Future Evolution + README phases.)*\n\n## Known limitations\n- Core product surfaces (capture, review, harvest UI, classification) **not yet built** (Phases 1–5).\n- Retrieval is FTS-only for MVP; no semantic search, no asset relationship graph yet (explicit non-goals).\n- Single-founder, private tool — no multi-tenant, no public API.\n- **Hermes** learning loop and **OpenClaw** integration are future, not implemented.\n\n## Future opportunities\n- Complete the capture→retrieve loop to realise the \"capture first\" thesis.\n- Add the **Hermes** feedback loop to close intelligence quality on real outcomes.\n- Semantic search + relationship graph once the asset library reaches scale (≥200 assets).\n\n## Relationship to the wider AI venture ecosystem\nThe **producer** of the Intelligence Platform (layer 2): it consumes [Shared Skills](/repos/shared-skills)\n(layer 1), publishes **intelligence products** ([intelproducts](/repos/intelproducts), layer 3), and feeds\nApplications & Agents (leadplatform, outreachagent — layer 4) and the founder's Ventures (layer 5). See\n[Intelligence Platform architecture](/architecture/intelligence-platform) and the\n[Portfolio Overview](/overview).\n\n## Links\n- Source: local git repo `PersonalOps/PersonalOps` (private)\n- System digest: [`intelligence-platform`](/ventures/intelligence-platform)\n- Platform doc: [Intelligence Platform](/architecture/intelligence-platform)\n- Registry row: [repo registry](/registry/repo-registry)\n"},{"id":"/repos/shared-skills","kind":"page","entityType":"repository","title":"Shared Skills","route":"/repos/shared-skills","sourcePath":"portal/repos/shared-skills.md","slug":"shared-skills","frontmatter":{"title":"Shared Skills","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"shared-skills","system":"shared-skills","layer":"Shared Skills","repo_url":"private (local library at ~/.claude/skills)","lifecycle":"active","maturity":"operational"},"excerpt":"A curated library of 169 Agent Skills — modular, self-contained capability packages that extend","headings":[{"depth":2,"text":"What it is","id":"what-it-is"},{"depth":2,"text":"Why it exists","id":"why-it-exists"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Business capability provided","id":"business-capability-provided"},{"depth":2,"text":"Technical responsibilities","id":"technical-responsibilities"},{"depth":2,"text":"Core concepts","id":"core-concepts"},{"depth":2,"text":"Key workflows","id":"key-workflows"},{"depth":2,"text":"Technologies used","id":"technologies-used"},{"depth":2,"text":"Major modules / components","id":"major-modules-components"},{"depth":2,"text":"Capabilities","id":"capabilities"},{"depth":2,"text":"Upstream dependencies","id":"upstream-dependencies"},{"depth":2,"text":"Downstream consumers","id":"downstream-consumers"},{"depth":2,"text":"Major interfaces & integration points","id":"major-interfaces-integration-points"},{"depth":2,"text":"Reusable assets exposed to other repositories","id":"reusable-assets-exposed-to-other-repositories"},{"depth":2,"text":"Architectural decisions","id":"architectural-decisions"},{"depth":2,"text":"Architecture snapshot","id":"architecture-snapshot"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Roadmap","id":"roadmap"},{"depth":2,"text":"Known limitations","id":"known-limitations"},{"depth":2,"text":"Future opportunities","id":"future-opportunities"},{"depth":2,"text":"Relationship to the wider AI venture ecosystem","id":"relationship-to-the-wider-ai-venture-ecosystem"},{"depth":2,"text":"Links","id":"links"}],"diagrams":1,"links":["../../templates/repo-digest.template.md","../ventures/shared-skills.md","../ventures/shared-skills.md","../portfolio-overview.md","../decisions/0002-layered-ecosystem-and-digest-standard.md","../current-state/roadmap.md","../portfolio-overview.md","../architecture/system-of-systems.md","../ventures/shared-skills.md","../registry/repo-registry.md","../architecture/recommendations.md","../portfolio-overview.md"],"body":"\n# Shared Skills — Repo Digest\n\n> **This is the reference digest.** It is the first real repository processed for the portal and\n> **sets the documentation standard** every future repo digest must follow (see the section order and\n> depth here, mirrored in [`templates/repo-digest.template.md`](../../templates/repo-digest.template.md)).\n\n\n## What it is\nA curated library of **169 Agent Skills** — modular, self-contained capability packages that extend\nClaude (and other AI coding tools) with domain expertise, procedures, templates, and executable\nscripts. Each skill is a directory containing a `SKILL.md` (instructions + metadata) plus optional\n`references/`, `scripts/`, `assets/`, and `templates/`. It is the **foundational capability layer**\nof Azwaan's AI venture ecosystem.\n\n## Why it exists\nEvery venture, platform, product, and agent in the ecosystem needs the same underlying competencies —\narchitecture, documentation, diagramming, cloud engineering, security, marketing, sales, product,\nfinance, and operations. Rather than re-teaching those competencies to each project, they are\nfactored **once** into reusable skills and shared across the whole ecosystem. This repo is where\ncapability is *manufactured and standardized*; downstream layers *consume* it. It exists so that the\necosystem's intelligence compounds: improving a skill upgrades every venture that uses it.\n\n\n## At a glance\n\n| Field | Value |\n|-------|-------|\n| Slug | `shared-skills` |\n| System | [`shared-skills`](/ventures/shared-skills) (Shared Skills layer) |\n| Architecture layer | `Shared Skills` (foundation) |\n| Lifecycle | `active` |\n| Maturity | `operational` |\n| Skills count | **169** (verified 2026-07-05) |\n| Primary content | Markdown (`SKILL.md` + `references/`) — 370 `.md` files observed |\n| Executable scripts | Python (referenced by many skills), TypeScript (10), Shell (6) |\n| Location | `~/.claude/skills` (local; not a standalone git repo at time of review) |\n| Licensing | Mixed open source — MIT and Apache-2.0 |\n| Authors | Multiple (≥7 distinct), incl. `claude-code-skills`, Alireza Rezvani, Utkarsh Patrikar |\n| Last reviewed | 2026-07-05 |\n\n\n> **Assumption / uncertainty (recorded):** At review time `~/.claude/skills` is a local directory,\n> not an initialized git repository, and has no repo-level `README`/`CLAUDE.md`. Skill *content*\n> files are largely OneDrive cloud placeholders, so POSIX `find`/glob under-report; counts above were\n> verified with Windows-API tooling (PowerShell). If this library is later promoted to a first-class\n> git repo with its own root docs, revisit this digest.\n\n## Business capability provided\n**Reusable AI competence as infrastructure.** The repo supplies ready-made, standardized expertise\nthat any part of the ecosystem can invoke on demand — turning \"we need someone who knows X\" into \"we\nhave a skill for X.\" It is the ecosystem's *skills marketplace and standard library* rolled into one.\n\n## Technical responsibilities\n- Package domain expertise into self-contained, discoverable Agent Skills using the `SKILL.md` format.\n- Provide **progressive disclosure**: a lightweight `SKILL.md` entry point that pulls in heavier\n `references/`, `scripts/`, and `assets/` only when needed.\n- Ship deterministic tooling (Python/TS/shell scripts) for skills that require computation rather\n than prose (e.g. diagram generation, dependency analysis, process/cycle-time math).\n- Maintain metadata contracts (name, description-as-trigger, version, license, tags,\n `compatible_tools`, `context`) that make skills routable by the harness.\n- **Not responsible for:** runtime orchestration of agents, hosting products, or storing customer\n data — those belong to higher layers.\n\n## Core concepts\n| Concept | Meaning |\n|---------|---------|\n| **Skill** | A directory with a `SKILL.md` that extends an AI agent with a specific capability. |\n| **SKILL.md** | Front-matter (`name`, `description`, metadata) + instructions. The `description` doubles as the *trigger* the harness matches against user intent. |\n| **Progressive disclosure** | Core instructions live in `SKILL.md`; `references/` (121 skills), `scripts/` (67), `assets/` (31), `templates/` (3) load only when required. |\n| **Trigger routing** | Skills are selected by matching user intent to the `description`, not called by name. |\n| **`context: fork`** | Some skills (3 observed) run in an isolated fork context. |\n| **`compatible_tools`** | Many skills (13 observed) declare portability across claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli. |\n| **Deterministic tooling** | Skills that need exactness embed stdlib scripts rather than relying on model generation. |\n\n## Key workflows\n1. **Invocation** — the harness surfaces skills; a user's request matching a skill's `description`\n triggers it; the agent reads `SKILL.md` and, as needed, its `references/`/`scripts/`.\n2. **Authoring** — a new capability is captured as `SKILL.md` + supporting files, versioned, licensed,\n and tagged, following the established skill format.\n3. **Composition** — skills reference sibling skills (\"For X, see Y-skill\"), forming an informal\n capability graph across domains.\n4. **Execution** — computational skills shell out to their bundled scripts for deterministic output.\n5. **Curation / upkeep** — skills are added, versioned, and pruned (a `.last-cleanup` marker and\n `backups/` were observed under `~/.claude`).\n\n## Technologies used\n- **Primary medium:** Markdown (`SKILL.md`, `references/*.md`) — 370 `.md` files observed.\n- **Scripting:** Python (referenced throughout skill bodies, e.g. `senior-architect`, `knowledge-ops`,\n `process-mapper`, `dependency-auditor`), TypeScript (10 files), Shell (6 files); plus JSON, TOML, HTML.\n- **Format standard:** Anthropic Agent Skills (`SKILL.md` front-matter + progressive disclosure).\n- **Distribution/compat:** cross-tool via `compatible_tools`; open-source licensed (MIT, Apache-2.0).\n\n## Major modules / components\nThe library is best understood as **domain clusters** (≈169 skills). This clustering is the raw\nmaterial for the ecosystem's higher layers and for duplication analysis.\n\n| Cluster | Representative skills | Role in ecosystem |\n|---------|----------------------|-------------------|\n| **Engineering & Architecture** | `senior-architect`, `senior-backend/frontend/fullstack/devops`, `code-reviewer`, `adversarial-reviewer`, `api-design-reviewer`, `dependency-auditor`, `tech-stack-evaluator`, `spec-driven-workflow` | Build & review the platforms and products |\n| **Cloud & Infra** | `aws-solution-architect`, `azure-cloud-architect`, `gcp-cloud-architect`, `cloudflare` (+ `workers-best-practices`, `wrangler`, `durable-objects`, `agents-sdk`, `sandbox-sdk`) | Provision the runtime substrate |\n| **Security & Compliance** | `ai-security`, `cloud-security`, `skill-security-auditor`, `ai-prompt-engineering-safety-review`, `gdpr-dsgvo-expert` | Guardrails across layers |\n| **AI / Agents / Data** | `agent-designer`, `agent-workflow-designer`, `ai-team-orchestration`, `rag-architect`, `pinecone-rag`, `llm-cost-optimizer`, `prompt-optimizer`, `universal-scraping-architect` | Build the Intelligence Platform & agents |\n| **Docs / Knowledge / Diagrams** | `documentation-writer`, `create-readme`, `create-llms`/`update-llms`, `create-specification`, `create-architectural-decision-record`, `knowledge-ops`, `drawio`, `excalidraw-diagram-generator`, `process-mapper`, `md-slides` | **Powers this very portal** |\n| **Product & PM** | `prd`, `product-analytics`, `product-discovery`, `product-manager-toolkit`, `roadmap-communicator`, `scrum-master`, `jira-expert`, `experiment-designer`, `ux-researcher-designer` | Shape products & ventures |\n| **Design & Frontend** | `design-system`, `ui-design-system`, `premium-frontend-ui`, `landing-page-generator`, `web-design-reviewer`, `penpot-uiux-design`, `image`/`generate-image`, `video` | Build customer-facing experiences |\n| **Marketing / GTM / Growth** | ~50 skills incl. `content-strategy`, `copywriting`, `seo-audit`, `ai-seo`, `ads`, `emails`, `social`, `cro`, `launch`, `gtm-*`, `competitive-intel` | Commercialize ventures |\n| **Sales / RevOps / Finance** | `sales-enablement`, `prospecting`, `deal-desk`, `revops`, `saas-metrics-coach`, `pricing-strategist`, `financial-analyst`, `commercial-forecaster`, `rfp-responder` | Revenue engine |\n| **Ops / Bizops / Strategy** | `capacity-planner`, `vendor-management`, `internal-comms`, `founder-coach`, `automate-this`, `intelligence-pack-publisher` | Run the business |\n\n> Full per-skill descriptions live in each skill's `SKILL.md`. A complete inventory is intentionally\n> **not** duplicated here — see the [Shared Skills system digest](/ventures/shared-skills).\n\n## Capabilities\n- `skill-authoring` — a standard format & method for packaging AI capabilities\n- `architecture-tooling` — Mermaid/PlantUML diagram + dependency generation (`senior-architect`)\n- `documentation-generation` — Diátaxis docs, READMEs, specs, ADRs, `llms.txt`\n- `diagram-generation` — draw.io, Excalidraw, Mermaid, BPMN process maps\n- `dependency-analysis` — multi-language dependency & license auditing\n- `knowledge-ops` — SOP/runbook hygiene, orphan/dead-link detection\n- `go-to-market` — end-to-end marketing/sales/growth competence\n- `cloud-architecture` — AWS/Azure/GCP/Cloudflare design\n- `agent-engineering` — multi-agent design, RAG, prompt optimization\n> These capabilities are the **inputs** the future `portfolio-portal-orchestrator` will itself consume.\n\n## Upstream dependencies\n\n| Dependency | Type | Version | Notes |\n|------------|------|---------|-------|\n| Anthropic Agent Skills format | platform | n/a | Defines the `SKILL.md` contract |\n| Claude Code / Agent SDK harness | platform | n/a | Runtime that routes & executes skills |\n| Python stdlib | external-package | 3.x | Deterministic scripts (stdlib-only in several skills) |\n| Node/TypeScript runtime | external-package | Unknown | For TS-based skill scripts |\n| Various external services | external-service | n/a | Some skills call cloud/AI/SaaS APIs (declared per skill) |\n\n\n## Downstream consumers\nThis is a **foundational layer** — nearly everything can consume it. Concretely:\n\n| Consumer | How it consumes Shared Skills |\n|----------|-------------------------------|\n| **This portal (Docs layer)** | Built using `site-architecture`, `documentation-writer`, `senior-architect`, etc. |\n| **Future `portfolio-portal-orchestrator`** | Will reuse `senior-architect`, `dependency-auditor`, `create-llms`, `knowledge-ops` |\n| **Intelligence Platform** (planned) | Agent/RAG/data skills to build the platform |\n| **Intelligence Products** (planned) | Content/analysis skills to generate product intelligence |\n| **Applications & Agents** (planned) | Engineering + agent-engineering skills |\n| **Customer-facing Solutions** (planned) | Design, frontend, GTM, sales skills |\n\n> Only the portal is a *realized* consumer today; the rest are planned layers (see\n> [portfolio overview](/overview)). Recorded as forward-looking, not asserted as built.\n\n## Major interfaces & integration points\n- **Consumes:** the AI harness (skill routing), external APIs invoked by individual skills.\n- **Exposes:**\n - `SKILL.md` **trigger descriptions** — the interface the harness matches intent against.\n - **Reference documents** (`references/*.md`) — deep knowledge loaded on demand.\n - **Executable scripts** (`scripts/`) — deterministic tools with documented CLIs.\n - **Templates & assets** (`templates/`, `assets/`) — copy-ready artifacts.\n - **Metadata** (`name`, `version`, `tags`, `compatible_tools`) — machine-routable contracts.\n\n## Reusable assets exposed to other repositories\n- **169 invocable skills** across 10 domain clusters.\n- **Deterministic scripts** — e.g. `senior-architect/scripts/architecture_diagram_generator.py`,\n `dependency_analyzer.py`, `project_architect.py`; `knowledge-ops`/`process-mapper` analysis tools.\n- **Document templates** — README, spec, ADR, llms.txt scaffolds.\n- **Design tokens & brand onboarding** — `design-system`, `ui-design-system`.\n- **A reusable authoring standard** — the `SKILL.md` format itself, which the orchestrator skill will target.\n\n## Architectural decisions\n- Skills are **self-contained** and **progressively disclosed** (keep `SKILL.md` light).\n- Skills are **triggered by description**, not called by name (routing is intent-based).\n- **Determinism via scripts** where prose would be unreliable.\n- **Cross-tool portability** via `compatible_tools` and open-source licensing.\n- Portal-level decision to treat Shared Skills as the foundation layer: see\n [ADR 0002](/decisions/0002-layered-ecosystem-and-digest-standard).\n\n## Architecture snapshot\n\n```mermaid\ngraph TD\n subgraph Skill[\"Anatomy of a Skill\"]\n SM[SKILL.md
front-matter + instructions] --> REF[references/*.md]\n SM --> SCR[scripts/ py·ts·sh]\n SM --> AST[assets/ · templates/]\n end\n Harness[AI Harness / Agent SDK] -->|matches description| SM\n SM -->|invokes| SCR\n SM -.->|composes with| SM2[Other skills]\n\n subgraph Library[\"Shared Skills Library — 169 skills, 10 clusters\"]\n Eng[Engineering & Arch]\n Cloud[Cloud & Infra]\n Sec[Security]\n AI[AI / Agents / Data]\n Docs[Docs / Diagrams]\n Prod[Product / PM]\n Design[Design / Frontend]\n Mktg[Marketing / GTM]\n Sales[Sales / RevOps / Fin]\n Ops[Ops / Bizops]\n end\n```\n\n## Current maturity\n**Operational.** Rationale: 169 skills are present and actively used (this portal was built with\nthem); the library is versioned (68 skills carry a `version`), licensed, multi-author, and under\nactive curation (observed `backups/` and a `.last-cleanup` marker). It is not \"production\" in a\nhosted-SLA sense — it is a local, curated developer asset without CI, tests, or a published release\nprocess. Hence **operational, not production**.\n\n## Roadmap\nNear-term themes (see [roadmap](/current-state/roadmap)):\n- Promote the library to a first-class git repo with root `README`/`CLAUDE.md` and CI hygiene checks.\n- Build `portfolio-portal-orchestrator` (Phase D) that *consumes* these skills to automate the portal.\n- Add an internal skills index / taxonomy and de-duplicate overlapping capabilities (see review notes).\n\n## Known limitations\n- **No repo-level docs or git history** at review time — no root `README`/`CLAUDE.md`, not a git repo.\n- **No automated tests or CI** for skills; quality is by curation.\n- **Capability overlap** — several clusters contain near-duplicate skills (e.g. `revops` vs\n `revenue-operations`; `database-designer` vs `database-schema-designer`; multiple `senior-*`).\n- **Discoverability** relies on `description` quality; there is no unified taxonomy/index inside the repo.\n- **Cloud-placeholder storage** makes some tooling (POSIX `find`, glob) under-report contents.\n\n## Future opportunities\n- A **skills registry/taxonomy** file inside the repo (the orchestrator could generate it).\n- **Consolidation** of duplicated skills to reduce routing ambiguity.\n- **Test/eval harness** to regression-check skill outputs.\n- **Packaging** as a shareable/publishable skills pack (it already carries open-source licenses).\n- Treat the library as a **product** (a curated AI skills distribution) — a commercialization path.\n\n## Relationship to the wider AI venture ecosystem\nShared Skills is the **bottom, load-bearing layer** of the layered architecture described in the\n[Portfolio Overview](/overview). Intelligence flows *upward*: skills manufacture\ncapability → the Intelligence Platform turns capability into processed intelligence → Intelligence\nProducts package it → Applications & Agents operationalize it → Customer-facing Solutions deliver it.\nBecause improving one skill upgrades every dependent layer, this repo is the ecosystem's primary\npoint of **compounding leverage**. See [system-of-systems architecture](/architecture/system-of-systems).\n\n## Links\n- Source: `~/.claude/skills` (local, private)\n- System digest: [`shared-skills`](/ventures/shared-skills)\n- Registry row: [repo registry](/registry/repo-registry)\n- Architecture review notes: [recommendations](/architecture/recommendations)\n- Portfolio overview: [portfolio-overview](/overview)\n"},{"id":"/repos/website-intelligence-lab","kind":"page","entityType":"repository","title":"Website Intelligence Lab","route":"/repos/website-intelligence-lab","sourcePath":"portal/repos/website-intelligence-lab.md","slug":"website-intelligence-lab","frontmatter":{"title":"Website Intelligence Lab","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"website-intelligence-lab","system":"intelligence-platform","layer":"Intelligence Platform","repo_url":"private (local git repo — Documents/github/website-intelligence-lab)","lifecycle":"active","maturity":"early-development"},"excerpt":"An experimentation and evaluation platform — a \"scientific instrument\" whose purpose is not","headings":[{"depth":2,"text":"What it is","id":"what-it-is"},{"depth":2,"text":"Why it exists","id":"why-it-exists"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Business capability provided","id":"business-capability-provided"},{"depth":2,"text":"Technical responsibilities","id":"technical-responsibilities"},{"depth":2,"text":"Core concepts","id":"core-concepts"},{"depth":2,"text":"Key workflows","id":"key-workflows"},{"depth":2,"text":"Technologies used","id":"technologies-used"},{"depth":2,"text":"Major modules / components","id":"major-modules-components"},{"depth":2,"text":"Capabilities","id":"capabilities"},{"depth":2,"text":"Upstream dependencies","id":"upstream-dependencies"},{"depth":2,"text":"Downstream consumers","id":"downstream-consumers"},{"depth":2,"text":"Major interfaces & integration points","id":"major-interfaces-integration-points"},{"depth":2,"text":"Reusable assets exposed to other repositories","id":"reusable-assets-exposed-to-other-repositories"},{"depth":2,"text":"Architectural decisions","id":"architectural-decisions"},{"depth":2,"text":"Architecture snapshot","id":"architecture-snapshot"},{"depth":2,"text":"Current maturity","id":"current-maturity"},{"depth":2,"text":"Roadmap","id":"roadmap"},{"depth":2,"text":"Known limitations","id":"known-limitations"},{"depth":2,"text":"Future opportunities","id":"future-opportunities"},{"depth":2,"text":"Relationship to the wider AI venture ecosystem","id":"relationship-to-the-wider-ai-venture-ecosystem"},{"depth":2,"text":"Links","id":"links"}],"diagrams":1,"links":["../architecture/intelligence-platform.md","../ventures/intelligence-platform.md","shared-skills.md","../architecture/intelligence-platform.md","../architecture/principles.md","../architecture/principles.md","shared-skills.md","../architecture/intelligence-platform.md","../portfolio-overview.md","../ventures/intelligence-platform.md","../architecture/intelligence-platform.md","../registry/repo-registry.md","../architecture/principles.md"],"body":"\n# Website Intelligence Lab — Repo Digest\n\n> The foundational engineering repository of the **Intelligence Platform** layer for **Inexis\n> Digital**. It is documented as a *platform component*; the platform-level view (with executive,\n> container, component, and runtime diagrams) is in\n> [architecture/intelligence-platform.md](/architecture/intelligence-platform).\n\n\n## What it is\nAn **experimentation and evaluation platform** — a \"scientific instrument\" whose purpose is *not*\nhosting websites but enabling **repeatable, measurable improvement** of website assessment, migration,\nand optimisation capabilities across website technologies. Websites are subjects of study; WordPress is\nthe first backend; **measurement is the point.** *(Source: `README.md`, `docs/philosophy.md`.)*\n\n## Why it exists\nInexis Digital's value depends on engines (Website Assessment, Migration, Proposal, AI Search) getting\nmeasurably better over time. You cannot improve what you cannot reproduce and compare. The lab exists to\nprovide the **reproducible harness, the corpus of subject businesses, and the immutable record of every\nexperiment** so that any engine version can be objectively evaluated against prior versions — answering\nquestions like *\"Did Migration Engine v9.4 beat v9.3, and can we prove exactly why?\"* It is deliberately\n**not** the engines themselves (they live in separate repos and run *against* the lab) and **not** a\nproduction host. *(Source: `CLAUDE.md` \"What this repository is / is NOT\".)*\n\n\n## At a glance\n\n| Field | Value |\n|-------|-------|\n| Slug | `website-intelligence-lab` |\n| System | [`intelligence-platform`](/ventures/intelligence-platform) |\n| Architecture layer | `Intelligence Platform` (layer 2) |\n| Owner org | Inexis Digital (`inexisdigital.com.au`) |\n| Lifecycle | `active` |\n| Maturity | `early-development` (infra operational; core loop not yet built) |\n| Repo type | Git repo, MADR-style ADRs, phase-gated |\n| Phase status | 1 ✅ · 2 ✅ (VPS-validated) · 2.5 🔄 in progress · 3–6 ⏳ pending |\n| Last reviewed | 2026-07-05 |\n\n\n## Business capability provided\n**Reproducible measurement & evaluation of website-intelligence capabilities.** It gives Inexis Digital\nan objective, provenanced basis to evolve its service engines, backed by a curated corpus of real and\nsynthetic businesses and an immutable experiment history.\n\n## Technical responsibilities\nPer `CLAUDE.md`, the lab owns exactly three things and explicitly disclaims the rest:\n- The **infrastructure** that hosts generated and test websites.\n- The **corpus** of businesses those websites belong to.\n- The **immutable record** of every experiment run against them.\n\nIt does **not** own: the engines (separate repos), production hosting, or knowledge content (referenced,\nnever copied).\n\n## Core concepts\nThe domain model (memorised verbatim in `CLAUDE.md`, detailed in `docs/domain-model.md`):\n\n| Concept | Meaning |\n|---------|---------|\n| **Capability** | Declarative service taxonomy — *what Inexis knows how to do*. Owns no execution. |\n| **Business** | The subject: `origin: real | synthetic`. Owns Observed assets; has Cases. |\n| **Digital Asset** | Two orthogonal axes: **category** (`observed \\| reference \\| generated`) × **role** (`input \\| target \\| output \\| fixture`). |\n| **Case** | The **unit of work & evaluation** (supersedes Project). Selects input (observed) + optional target (reference); references Capabilities; accumulates Runs. |\n| **Run** | **One immutable, fully-provenanced experiment execution**. Re-execution mints a new run-id. |\n| **Reference asset** | Curated, versioned best-practice exemplar (Astra, Kadence, GeneratePress). Owned by no business. |\n| **Benchmark** | Versioned dataset of Cases, tiered by observed-input quality (Gold/Good/Average/Poor). |\n\n**The single most important split:** authored **inputs** (`corpus/`) and generated **outputs** (`runs/`)\nnever share a folder.\n\n## Key workflows\n1. **Author a subject** — define a Business (`business.yml`), register its Observed assets (real presence,\n referenced + snapshotted, *never rehosted*; `capture_pending` until the crawler exists).\n2. **Define a Case** — reference Capabilities, select an Observed input and optional Reference target.\n3. **Execute a Run** — an *external engine* runs against the lab, producing immutable Generated assets in\n `runs////` with complete provenance (engine+version, model, prompt/knowledge\n versions, config, input lineage).\n4. **Evaluate** — score engine versions against Benchmarks tiered by input quality; diff runs to explain\n differences.\n5. **Reference knowledge** — external intelligence is pinned by immutable ref in `knowledge/`, never copied.\n\n## Technologies used\n- **Host/infra:** Docker + Docker Compose (project `wil`), Ubuntu 24.04.\n- **Edge/TLS:** Caddy `2.11.4` + Cloudflare DNS plugin `v0.2.4` (wildcard TLS via DNS-01), Let's Encrypt/ACME.\n- **Backend:** WordPress `6.9-php8.3-apache` **Multisite (subdomain mode)**, WP-CLI, MariaDB `11.4.12`, phpMyAdmin.\n- **DNS:** Cloudflare (`wp-lab.inexisdigital.com.au`).\n- **Contracts:** YAML schemas in `docs/contracts/`; scripts favour POSIX `sh` + a Makefile entrypoint.\n- Builds are **pinned/deterministic** (ADR-0010).\n\n## Major modules / components\nThe repo is organised into **domains** separated by change-rate, owner, and responsibility:\n\n| Domain | Path | Responsibility | Change-rate |\n|--------|------|----------------|-------------|\n| Infrastructure | `infrastructure/` | The host: Docker, Caddy, MariaDB, WP Multisite | Rarely |\n| Platforms | `platforms/` | Technology adapters + adapter contract (WordPress = reference) | Per new tech |\n| Capabilities | `capabilities/` | Service taxonomy registry (declarative) | Occasionally |\n| Reference | `reference/` | Curated, versioned best-practice targets | Occasionally |\n| Corpus | `corpus/` | Businesses, Observed assets, Cases, benchmarks (INPUTS) | Continuously |\n| Runs | `runs/` | Immutable, provenanced experiment records (OUTPUTS) | Constantly |\n| Knowledge | `knowledge/` | Pinned references to external knowledge repos | Independently |\n| Services | `services/` | Future composable compute (crawler, screenshot…) | Additively |\n\n## Capabilities\n- `reproducible-experiment-harness` — immutable, provenanced run execution & comparison\n- `corpus-management` — real/synthetic businesses, observed assets, cases, benchmarks\n- `evaluation-benchmarking` — quality-tiered benchmark datasets for engine evaluation\n- `reference-catalog` — shared versioned best-practice targets\n- `capability-taxonomy` — declarative registry of Inexis services\n- `knowledge-referencing` — pinned external-knowledge boundary\n- `platform-adapter-contract` — technology-agnostic provision/teardown/snapshot interface\n\n## Upstream dependencies\n\n| Dependency | Type | Version | Notes |\n|------------|------|---------|-------|\n| External **engines** (Assessment, Migration, Proposal, AI Search) | internal-repo (separate) | n/a | Run *against* the lab; produce runs |\n| External **knowledge** repositories | internal-repo (by reference) | pinned SHA/hash | Never copied in (ADR-0006) |\n| Docker / Docker Compose | platform | — | Host substrate |\n| Caddy + Cloudflare DNS plugin | external-package | 2.11.4 / v0.2.4 | Pinned together (ADR-0010) |\n| WordPress + MariaDB + WP-CLI | external-package | 6.9 / 11.4.12 | First backend |\n| Cloudflare | external-service | — | DNS + DNS-01 TLS |\n| [Shared Skills](/repos/shared-skills) | internal-repo | n/a | Used to engineer/document this repo (ecosystem layer 1) |\n\n\n## Downstream consumers\n- **The engines** — consume the lab as their execution & evaluation harness (they write immutable runs).\n- **Inexis Digital service delivery** — capabilities → customer work (assessment, migration, SEO, etc.).\n- **Intelligence products** — relationship to the `intelproducts` repo (intelligence packs) is documented\n at the platform level; see [Intelligence Platform](/architecture/intelligence-platform). *(Cross-repo\n linkage recorded there to avoid over-claiming here.)*\n- Higher ecosystem layers (Applications & Agents, Ventures) consume the platform's outputs — planned.\n\n## Major interfaces & integration points\n- **Consumes:** external engines (execution), external knowledge (pinned refs), Cloudflare/Docker/WordPress.\n- **Exposes:**\n - **Adapter contract** (`platforms/README.md`) — provision/teardown/snapshot, technology-agnostic.\n - **Contract schemas** (`docs/contracts/`) — `business`, `digital-asset`, `case`, `run-manifest`,\n `reference`, `benchmark`, `capability` — the seams between domains.\n - **Immutable run manifests** — the provenanced record other systems evaluate.\n - **Capabilities registry** (`capabilities/registry.yml`) — the shared service vocabulary.\n\n## Reusable assets exposed to other repositories\n- The **domain model + YAML contract schemas** (a reusable pattern for provenanced experiment platforms).\n- The **reference catalog** of best-practice targets (Astra / Kadence / GeneratePress, versioned).\n- The **deterministic infrastructure stack** (Compose + Caddy + Cloudflare DNS + WP Multisite).\n- The **capabilities taxonomy** as the bridge between platform modules and customer work.\n\n## Architectural decisions\n11 ADRs (MADR-style; 9 Accepted, 2 Proposed) — full index in the repo's `docs/adr/`:\n- **0002** Technology-agnostic lab (not a WordPress repo) · **0003** The subject is a Business, not a Website\n- **0004** Runs are immutable & fully provenanced · **0005** Capabilities as a first-class taxonomy\n- **0006** External knowledge by pinned reference · **0009** Reverse-proxy topology + subdomain Multisite\n- **0010** Deterministic image/Caddy builds · **0011** Asset categories, Cases, and the reference domain\n- **0007** Run-id scheme *(Proposed)* · **0008** Object storage for run blobs *(Proposed)*\n\nThese decisions seed several ecosystem-wide [Architecture Principles](/architecture/principles).\n\n## Architecture snapshot\n\n```mermaid\ngraph TD\n subgraph Inputs[\"corpus/ — INPUTS (authored, in Git)\"]\n BIZ[Businesses + Observed assets]\n CASE[Cases → reference Capabilities]\n BENCH[Benchmarks]\n end\n REF[reference/ — best-practice targets]\n CAP[capabilities/ — service taxonomy]\n KNOW[knowledge/ — external, pinned]\n ENG[[External Engines]]\n SVC[services/ — future compute]\n subgraph Outputs[\"runs/ — OUTPUTS (immutable, provenanced)\"]\n RUN[Runs → Generated assets]\n end\n INFRA[infrastructure/ — Docker · Caddy · WP Multisite]\n\n CAP -.referenced by.-> CASE\n BIZ --> CASE --> ENG\n REF -->|target| ENG\n KNOW -->|pinned versions| ENG\n ENG --> RUN\n SVC --> RUN\n BENCH -->|evaluate| RUN\n INFRA -->|hosts generated/fixture sites| RUN\n```\n\n## Current maturity\n**Early-development.** Rationale (evidence-based): Phase 1 (scaffold) and Phase 2 (infrastructure —\nCompose, Caddy, MariaDB, WP Multisite) are **complete and VPS-validated**; Phase 2.5 (corpus seeding) is\n**in progress**. The core lab loop — platform adapter (Phase 3), corpus model & validation (Phase 4),\nrun/provenance capture (Phase 5), and DX (Phase 6) — is **not yet built**, and the engines that produce\nruns are external and separate. So infrastructure is operational but the platform's central capability\n(reproducible runs & evaluation) is still ahead. *(Source: `README.md` phase table, `CLAUDE.md` status.)*\n\n## Roadmap\n- **Near term:** finish corpus seeding (2.5) → WordPress adapter (3) → corpus model/validation (4) →\n immutable runs & provenance capture (5) → developer experience/Makefile (6).\n- **Future domains (acknowledged, not scaffolded):** `experiments/` (compare runs across strategies/models);\n shared **Resource registry** (first instance already exists as `reference/`); additional **platform\n adapters** (Wix, Squarespace, Shopify, Webflow, static HTML); additional **engines** (all writing\n immutable runs). *(Source: `docs/roadmap.md`.)*\n\n## Known limitations\n- **Crawler not built** → Observed assets are `capture_pending`; real inputs cannot yet be captured.\n- **Core loop unbuilt** — adapters, run/provenance capture, and evaluation (Phases 3–5) are pending.\n- **Engines are external** and (at review time) not evidenced in this portal as registered repos.\n- **Single-org scope** — Inexis Digital website domain; multi-tech breadth is designed but WordPress-only today.\n- Reproducibility depends on **upstream knowledge versioning discipline** (mitigated by pinning to immutable refs).\n\n## Future opportunities\n- Stand up the **Experiments domain** once multiple runs need cross-comparison.\n- Onboard a **second platform adapter** to prove technology-agnosticism in practice.\n- Use the lab to **benchmark engine versions at scale**, turning capability improvement into a measured pipeline.\n- Generalise the provenanced-run pattern as a reusable ecosystem asset (see [principles](/architecture/principles)).\n\n## Relationship to the wider AI venture ecosystem\nThis repo is the **engineering foundation of the Intelligence Platform (layer 2)** for Inexis Digital. It\n**consumes [Shared Skills](/repos/shared-skills) (layer 1)** for its own engineering and documentation, and its\noutputs (measured capabilities, evaluated engines, generated assets) feed **Intelligence Products (layer 3)**\nand, above them, **Applications, Agents, and Ventures**. See the\n[Intelligence Platform](/architecture/intelligence-platform) page and the\n[Portfolio Overview](/overview).\n\n## Links\n- Source: local git repo `website-intelligence-lab` (private)\n- System digest: [`intelligence-platform`](/ventures/intelligence-platform)\n- Platform doc: [Intelligence Platform](/architecture/intelligence-platform)\n- Registry row: [repo registry](/registry/repo-registry)\n- Principles: [Architecture Principles](/architecture/principles)\n"},{"id":"/ventures","kind":"page","entityType":"doc","title":"Ventures / Systems","route":"/ventures","sourcePath":"portal/ventures/README.md","slug":null,"frontmatter":{"title":"Ventures / Systems","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"One digest per venture or system. A system groups one or more repos that together deliver a","headings":[{"depth":2,"text":"Systems by layer","id":"systems-by-layer"}],"diagrams":0,"links":["../portfolio-overview.md","../architecture/system-of-systems.md","../../templates/venture-digest.template.md","../../docs/update-conventions.md#recipe-add-a-venture--system","shared-skills.md","intelligence-platform.md","intelligence-platform.md#layer-3--intelligence-products"],"body":"\n# Ventures / Systems\n\nOne **digest** per venture or system. A system groups one or more repos that together deliver a\ncapability, and is positioned within an **architecture layer** (see the\n[Portfolio Overview](/overview)). This is the \"system of systems\" story at the grouping\nlevel; the whole-ecosystem view lives in [architecture](/architecture/system-of-systems).\n\n- **Template:** [`templates/venture-digest.template.md`](../../templates/venture-digest.template.md)\n- **How to add one:** [update conventions](/about/update-conventions#recipe-add-a-venture--system)\n\n## Systems by layer\n\n\n| Layer | System | Realization | Digest |\n|-------|--------|-------------|--------|\n| 1 · Shared Skills | `shared-skills` | Operational | [Shared Skills Layer](/ventures/shared-skills) |\n| 2 · Intelligence Platform | `intelligence-platform` (personalops + website-intelligence-lab) | Partial | [Intelligence Platform Layer](/ventures/intelligence-platform) |\n| 3 · Intelligence Products | `intelproducts` (within intelligence-platform digest) | Operational (contract) | [Intelligence Platform Layer](/ventures/intelligence-platform#layer-3--intelligence-products) |\n| 4 · Applications & Agents | `leadplatform`, `outreachagent` | Partial | ⏳ not yet processed |\n| 5 · Ventures | Inexis Digital · Consulting · Inbound Lanka · City Retreats | Vision (in portal) | — |\n| 6 · Customer-facing Solutions | — | Vision | — |\n\n\n> **TODO:** Add a system digest for the Applications & Agents layer once `leadplatform`/`outreachagent` are\n> fully processed; register layer-5 ventures.\n"},{"id":"/ventures/intelligence-platform","kind":"page","entityType":"venture","title":"Intelligence Platform Layer","route":"/ventures/intelligence-platform","sourcePath":"portal/ventures/intelligence-platform.md","slug":"intelligence-platform","frontmatter":{"title":"Intelligence Platform Layer","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"intelligence-platform","layer":"Intelligence Platform","lifecycle":"building"},"excerpt":"reusable, versioned intelligence. It is not a single repository but an assembly of sibling systems, plus","headings":[{"depth":2,"text":"Purpose","id":"purpose"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Member repos","id":"member-repos"},{"depth":2,"text":"Layer 3 — Intelligence Products","id":"layer-3-intelligence-products"},{"depth":2,"text":"Capabilities provided","id":"capabilities-provided"},{"depth":2,"text":"System map","id":"system-map"},{"depth":2,"text":"External dependencies & integrations","id":"external-dependencies-integrations"},{"depth":2,"text":"Cross-venture relationships","id":"cross-venture-relationships"},{"depth":2,"text":"Named-subsystem status (recorded honestly)","id":"named-subsystem-status-recorded-honestly"},{"depth":2,"text":"Status & roadmap pointers","id":"status-roadmap-pointers"},{"depth":2,"text":"Links","id":"links"}],"diagrams":1,"links":["../architecture/intelligence-platform.md","../repos/personalops.md","../repos/website-intelligence-lab.md","../repos/intelproducts.md","../repos/intelproducts.md","../repos/shared-skills.md","../current-state/status-dashboard.md","../decisions/0003-intelligence-platform-layer-model.md","../architecture/intelligence-platform.md","../repos/personalops.md","../repos/website-intelligence-lab.md","../repos/intelproducts.md","../architecture/principles.md"],"body":"\n# Intelligence Platform Layer — System Digest\n\n\n## Purpose\n**Layer 2** of the ecosystem: the systems that turn raw knowledge and market signals into **structured,\nreusable, versioned intelligence**. It is not a single repository but an assembly of sibling systems, plus\nthe published-products contract it feeds. The full platform-level architecture (executive → container →\ncomponent → runtime, with the subsystem reconciliation) is in\n[architecture/intelligence-platform.md](/architecture/intelligence-platform).\n\n\n## At a glance\n| Field | Value |\n|-------|-------|\n| Slug | `intelligence-platform` |\n| Architecture layer | `Intelligence Platform` (layer 2) + feeds `Intelligence Products` (layer 3) |\n| Lifecycle | `building` |\n| Maturity | mixed — see member systems |\n| Owner org | Inexis / PersonalOps (founder: Azwaan) |\n| Serves ventures | Inexis Digital, Inexis Consulting, Inbound Lanka, City Retreats, Cross-Cutting |\n| Last reviewed | 2026-07-05 |\n\n## Member repos\n\n| Repo | Role | Layer | Maturity | Digest |\n|------|------|-------|----------|--------|\n| `personalops` | **FIP** — knowledge intelligence platform + Intelligence Dashboard (producer) | 2 | early-development | [digest](/repos/personalops) |\n| `website-intelligence-lab` | Website engine experimentation & evaluation platform | 2 | early-development | [digest](/repos/website-intelligence-lab) |\n| `intelproducts` | Published intelligence packs (the output contract) | 3 | operational | [digest](/repos/intelproducts) |\n\n\n## Layer 3 — Intelligence Products\nThe layer produces **intelligence products** ([`intelproducts`](/repos/intelproducts)): versioned,\nimmutable packs (proposal, website-assessment, cinnamon-stories, outreach-messaging) that downstream apps\npin and consume. Modelled as layer 3 because it is the *output* of layer 2, not a platform itself.\n\n## Capabilities provided\n| Capability | Provided by |\n|------------|-------------|\n| Knowledge capture, extraction, structuring | `personalops` (FIP) |\n| Scoped retrieval + Intelligence Dashboard | `personalops` |\n| Reproducible engine evaluation (websites) | `website-intelligence-lab` |\n| Versioned intelligence products (packs) | `intelproducts` |\n\n## System map\n\n```mermaid\ngraph TD\n subgraph L2[Layer 2 · Intelligence Platform]\n FIP[PersonalOps / FIP
producer + dashboard]\n LAB[Website Intelligence Lab
evaluation platform]\n end\n L3[intelproducts · layer 3
published packs]\n FIP --> L3\n L3 --> DOWN[Applications & Agents
leadplatform · outreachagent]\n SS[Shared Skills · layer 1] -.-> FIP & LAB & L3\n FIP -. sibling, non-dependent .- LAB\n```\n\n## External dependencies & integrations\n- **Supabase** (FIP data store), **Docker/Caddy/WordPress/Cloudflare** (lab infra), **Claude/Codex/OpenClaw** (agents).\n- **Shared Skills** builder skill `intelligence-pack-publisher` and consumer skills.\n\n## Cross-venture relationships\n- **Produces intelligence products** consumed by `leadplatform` and `outreachagent` (layer 4).\n- **Consumes [Shared Skills](/repos/shared-skills)** (layer 1) for engineering and pack authoring.\n- **Serves five venture areas** (layer 5): Inexis Digital, Inexis Consulting, Inbound Lanka, City Retreats, cross-cutting.\n\n## Named-subsystem status (recorded honestly)\n| Subsystem | Status |\n|-----------|--------|\n| Intelligence products, extraction pipelines, knowledge assets | ✅ Implemented |\n| Recommendations | 🔶 Partial (output in outreachagent; engine spec out-of-scope in `inexisstudios`) |\n| OpenClaw, Hermes | 🔶 Planned / not built |\n| \"Estate generation\" | ❌ Not found — not a real subsystem |\n\n## Status & roadmap pointers\n- **Current state:** mixed maturity; see [status dashboard](/current-state/status-dashboard).\n- **Roadmap:** build FIP Phases 1–5; stand up the lab's core loop; implement Hermes once outcome data exists.\n- **Related ADRs:** [ADR 0003](/decisions/0003-intelligence-platform-layer-model); source-repo ADRs in each system.\n\n## Links\n- Platform architecture: [Intelligence Platform](/architecture/intelligence-platform)\n- Digests: [PersonalOps/FIP](/repos/personalops) · [website-intelligence-lab](/repos/website-intelligence-lab) · [intelproducts](/repos/intelproducts)\n- Principles: [Architecture Principles](/architecture/principles)\n"},{"id":"/ventures/shared-skills","kind":"page","entityType":"venture","title":"Shared Skills Layer","route":"/ventures/shared-skills","sourcePath":"portal/ventures/shared-skills.md","slug":"shared-skills","frontmatter":{"title":"Shared Skills Layer","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan","slug":"shared-skills","layer":"Shared Skills","lifecycle":"live"},"excerpt":"The Shared Skills layer is the foundational capability layer of the ecosystem: a single curated","headings":[{"depth":2,"text":"Purpose","id":"purpose"},{"depth":2,"text":"At a glance","id":"at-a-glance"},{"depth":2,"text":"Member repos","id":"member-repos"},{"depth":2,"text":"Capabilities provided","id":"capabilities-provided"},{"depth":2,"text":"System map","id":"system-map"},{"depth":2,"text":"External dependencies & integrations","id":"external-dependencies-integrations"},{"depth":2,"text":"Cross-venture relationships","id":"cross-venture-relationships"},{"depth":2,"text":"Status & roadmap pointers","id":"status-roadmap-pointers"},{"depth":2,"text":"Known duplication / review flags","id":"known-duplication-review-flags"},{"depth":2,"text":"Links","id":"links"}],"diagrams":1,"links":["../repos/shared-skills.md","../portfolio-overview.md","../current-state/status-dashboard.md","../current-state/roadmap.md","../decisions/0002-layered-ecosystem-and-digest-standard.md","../architecture/recommendations.md","../repos/shared-skills.md","../repos/README.md","../architecture/system-of-systems.md"],"body":"\n# Shared Skills Layer — System Digest\n\n\n## Purpose\nThe **Shared Skills layer** is the foundational capability layer of the ecosystem: a single curated\nlibrary of reusable AI Agent Skills that every other layer draws on. It exists so competence is built\nonce and reused everywhere — the ecosystem's standard library and skills marketplace in one. This is\nalso the **Skills Layer documentation** referenced by the portal's layered-architecture model.\n\n\n## At a glance\n| Field | Value |\n|-------|-------|\n| Slug | `shared-skills` |\n| Architecture layer | `Shared Skills` (foundation, layer 1) |\n| Lifecycle | `live` |\n| Maturity | operational |\n| Primary domain | Reusable AI capability / developer tooling |\n| Public-facing? | No (internal foundation; potential future product) |\n| Owner | Azwaan |\n| Last reviewed | 2026-07-05 |\n\n## Member repos\n\n| Repo | Role in the layer | Lifecycle | Digest |\n|------|-------------------|-----------|--------|\n| `shared-skills` | The skills library itself (169 skills) | active | [digest](/repos/shared-skills) |\n\n\n## Capabilities provided\nOrganized into the 10 domain clusters that make up the layer:\n\n| Cluster | Provides to the ecosystem |\n|---------|---------------------------|\n| Engineering & Architecture | System design, code review, dependency & stack analysis |\n| Cloud & Infra | AWS/Azure/GCP/Cloudflare architecture and Workers tooling |\n| Security & Compliance | AI/cloud security assessment, prompt-safety, GDPR |\n| AI / Agents / Data | Agent design, multi-agent orchestration, RAG, prompt optimization |\n| Docs / Knowledge / Diagrams | Documentation, ADRs, `llms.txt`, Mermaid/draw.io/Excalidraw, process maps |\n| Product & PM | PRDs, discovery, analytics, roadmaps, agile delivery |\n| Design & Frontend | Design systems, premium UI, landing pages, media generation |\n| Marketing / GTM / Growth | ~50 skills across content, SEO, ads, email, social, CRO, GTM |\n| Sales / RevOps / Finance | Sales enablement, pricing, forecasting, financial analysis |\n| Ops / Bizops / Strategy | Capacity, vendors, internal comms, automation, founder coaching |\n\n## System map\n\n```mermaid\ngraph TD\n Harness[AI Harness] -->|routes intent| Lib[Shared Skills Library
169 skills]\n Lib --> C1[Engineering & Arch]\n Lib --> C2[Cloud & Infra]\n Lib --> C3[Security]\n Lib --> C4[AI / Agents / Data]\n Lib --> C5[Docs / Diagrams]\n Lib --> C6[Product / PM]\n Lib --> C7[Design / Frontend]\n Lib --> C8[Marketing / GTM]\n Lib --> C9[Sales / RevOps / Fin]\n Lib --> C10[Ops / Bizops]\n Lib -.feeds.-> Up[All higher layers]\n```\n\n## External dependencies & integrations\n- Anthropic Agent Skills format and the Claude Code / Agent SDK harness (runtime).\n- Per-skill external services (cloud, AI, and SaaS APIs) declared inside individual skills.\n\n## Cross-venture relationships\n- **Feeds every other layer** — this is the base of the layered architecture. See the\n [Portfolio Overview](/overview).\n- **Powers this portal** — the Docs/portal layer is built directly on Shared Skills.\n- **Will power the `portfolio-portal-orchestrator`** — the future automation skill consumes skills\n from this layer (`senior-architect`, `dependency-auditor`, `create-llms`, `knowledge-ops`).\n\n## Status & roadmap pointers\n- **Current state:** operational; 169 skills; see [status dashboard](/current-state/status-dashboard).\n- **Roadmap:** promote to a first-class repo, add taxonomy/index, consolidate duplicates — see\n [roadmap](/current-state/roadmap).\n- **Related ADRs:** [ADR 0002](/decisions/0002-layered-ecosystem-and-digest-standard).\n\n## Known duplication / review flags\nRecorded (not acted on) — see [architecture recommendations](/architecture/recommendations):\n- `revops` ⟷ `revenue-operations`\n- `database-designer` ⟷ `database-schema-designer`\n- Overlap across `senior-*` engineering skills\n- Multiple competitor-analysis skills (`competitors`, `competitor-profiling`, `competitive-teardown`, `competitive-intel`)\n\n## Links\n- Repo digest: [shared-skills](/repos/shared-skills)\n- Repos index: [repos](/repos)\n- Architecture: [system of systems](/architecture/system-of-systems)\n"},{"id":"/about/documentation-model","kind":"page","entityType":"meta","title":"Documentation Model (Diátaxis)","route":"/about/documentation-model","sourcePath":"docs/documentation-model.md","slug":null,"frontmatter":{"title":"Documentation Model (Diátaxis)","type":"explanation","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Portal content follows the Diátaxis framework (https://diataxis.fr/), applied by the","headings":[{"depth":2,"text":"The four types","id":"the-four-types"},{"depth":2,"text":"Type of each portal surface","id":"type-of-each-portal-surface"},{"depth":2,"text":"Frontmatter contract","id":"frontmatter-contract"},{"depth":2,"text":"Writing principles (from documentation-writer)","id":"writing-principles-from-documentation-writer"},{"depth":2,"text":"Placeholders & unknowns","id":"placeholders-unknowns"}],"diagrams":0,"links":["update-conventions.md","information-architecture.md","glossary.md","glossary.md"],"body":"\n# Documentation Model\n\nPortal content follows the **Diátaxis** framework (https://diataxis.fr/), applied by the\n`documentation-writer` skill. Every page has exactly one *type*, and its type determines its shape,\ntone, and what it may contain. Mixing types is the most common documentation failure — keep them\nseparate.\n\n## The four types\n\n| Type | Orientation | Answers | Portal examples |\n|------|-------------|---------|-----------------|\n| **Tutorial** | Learning | \"Walk me through it\" | *(rare here)* Onboarding a new venture into the portal |\n| **How-to** | Task | \"How do I do X\" | [Update conventions](/about/update-conventions), \"add a repo\" recipes in CLAUDE.md |\n| **Reference** | Information | \"What is X exactly\" | [Information architecture](/about/information-architecture), repo registry, repo/venture digests, ADRs |\n| **Explanation** | Understanding | \"Why is it like this\" | This page, system-of-systems architecture narrative, [Glossary](/about/glossary) |\n\n## Type of each portal surface\n\n| Surface | Diátaxis type | Notes |\n|---------|---------------|-------|\n| Repo digest | Reference | Factual snapshot; no opinions, no how-to steps |\n| Venture digest | Reference (+ short Explanation intro) | Facts + a framing paragraph on the venture's purpose |\n| Architecture pages | Explanation (+ Reference diagrams) | Narrative *why*, with diagrams as reference |\n| ADR | Reference | Immutable record of a decision and its context |\n| Status dashboard / changelog / roadmap | Reference | Current facts, dated |\n| Update conventions | How-to | Recipes for maintainers |\n| Showcase (future) | Explanation / marketing | Persuasive, audience = public |\n\n## Frontmatter contract\n\nEvery content page starts with YAML frontmatter. The `type` field MUST be one of\n`tutorial | how-to | reference | explanation`.\n\n```yaml\n---\ntitle: \ntype: reference # diátaxis type\nstatus: draft | living | accepted | superseded | archived\nlast_reviewed: YYYY-MM-DD\nowner: \n---\n```\n\n## Writing principles (from documentation-writer)\n\n1. **Clarity** — simple, unambiguous language.\n2. **Accuracy** — every fact, stack name, and dependency must be correct or explicitly marked `Unknown`.\n3. **User-centric** — write for the audience of that page's type.\n4. **Consistency** — same terminology across pages; see the [Glossary](/about/glossary).\n\n## Placeholders & unknowns\n\nBecause much of the portal will later be machine-generated, unfinished content must be **explicit\nand greppable**:\n\n- `> **TODO:** …` for a maintainer action.\n- `` for content awaiting generation.\n- `Unknown` / `TBD` for facts not yet established — never guess.\n- `` … `` wraps regions the orchestrator will own.\n- `` … `` wraps regions humans own (the orchestrator must not overwrite).\n"},{"id":"/about/glossary","kind":"page","entityType":"meta","title":"Glossary","route":"/about/glossary","sourcePath":"docs/glossary.md","slug":null,"frontmatter":{"title":"Glossary","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Shared vocabulary for the portal. Use these terms consistently across all pages.","headings":[],"diagrams":0,"links":["../portal/operating-model/glossary.md"],"body":"\n# Glossary\n\n> **Scope note:** this page is the **portal-maintenance** vocabulary (how the portal is built). The\n> **authoritative ecosystem glossary** — with owner, related concepts, where-used, and first-class status per\n> term — is the [Portfolio Glossary](/operating-model/glossary). Where they overlap, the Portfolio\n> Glossary is canonical.\n\nShared vocabulary for the portal. Use these terms consistently across all pages.\n\n| Term | Definition |\n|------|------------|\n| **Portal** | This repository — the markdown-first system-of-systems layer. |\n| **Repo digest** | A one-page factual summary of a single source repository, living in `portal/repos/`. |\n| **Venture / system** | A grouping of one or more repos that together deliver a product, service, or capability. Documented in `portal/ventures/`. |\n| **Registry** | The canonical index of every repo, in `portal/registry/repo-registry.md`. |\n| **System of systems** | The whole ecosystem viewed as interacting ventures and repos, rather than any single app. |\n| **Showcase** | The future public-facing presentation layer (Phase C), in `showcase/`. |\n| **ADR** | Architecture Decision Record — an immutable record of a significant decision. |\n| **Orchestrator** | The future `portfolio-portal-orchestrator` skill that will automate digest and diagram generation. |\n| **Capability** | A distinct function a repo provides (e.g. \"auth\", \"vector search\", \"billing\"). Used to detect duplication across repos. |\n| **Digest** | Generic term for a summary page (repo digest or venture digest). |\n| **Layer** | One of the three explanation levels: repo-level docs, portfolio portal, public showcase. |\n| **Generated region** | A block wrapped in `` markers that the orchestrator owns. |\n| **Human region** | A block wrapped in `` markers that automation must preserve. |\n\n> **TODO:** Extend with venture-specific and domain-specific terms as the ecosystem is mapped.\n"},{"id":"/about/information-architecture","kind":"page","entityType":"meta","title":"Information Architecture & Navigation Model","route":"/about/information-architecture","sourcePath":"docs/information-architecture.md","slug":null,"frontmatter":{"title":"Information Architecture & Navigation Model","type":"reference","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"This page defines the page hierarchy, navigation, and routing model for the Portfolio Architecture","headings":[{"depth":2,"text":"Audiences & goals","id":"audiences-goals"},{"depth":2,"text":"The three IA layers","id":"the-three-ia-layers"},{"depth":2,"text":"Page hierarchy (ASCII tree)","id":"page-hierarchy-ascii-tree"},{"depth":2,"text":"Route / URL map","id":"route-url-map"},{"depth":2,"text":"Navigation model","id":"navigation-model"},{"depth":3,"text":"Primary (header) nav","id":"primary-header-nav"},{"depth":3,"text":"Section (sidebar) nav","id":"section-sidebar-nav"},{"depth":3,"text":"Footer nav","id":"footer-nav"},{"depth":3,"text":"Breadcrumbs","id":"breadcrumbs"},{"depth":2,"text":"Internal linking rules (portal-specific)","id":"internal-linking-rules-portal-specific"},{"depth":2,"text":"Change control for the IA","id":"change-control-for-the-ia"}],"diagrams":1,"links":["update-conventions.md"],"body":"\n# Information Architecture & Navigation Model\n\nThis page defines the page hierarchy, navigation, and routing model for the Portfolio Architecture\nPortal. It is the output of the `site-architecture` skill applied to a documentation/hybrid portal.\nIt governs both the current markdown structure and the eventual public showcase site.\n\n## Audiences & goals\n\n| Audience | What they need | Primary entry point |\n|----------|----------------|---------------------|\n| Azwaan (owner/maintainer) | Keep the system-of-systems map accurate | Portal home → current state |\n| AI agents (Claude / ChatGPT) | Machine-readable map of repos & ventures | `llms.txt` → registry |\n| Collaborators / contractors | Understand how a repo fits the whole | Repo digest → venture digest |\n| Public (future) | Grasp scale & sophistication of the ecosystem | Showcase (Phase C) |\n\n## The three IA layers\n\nThe portal maps onto the three-layer design principle. Navigation should never blur these layers.\n\n```mermaid\ngraph TD\n subgraph L3[\"Public Showcase (Phase C — later)\"]\n SHOW[Showcase Home]\n end\n subgraph L2[\"Portfolio Portal (this repo — system of systems)\"]\n HOME[Portal Home]\n REG[Repo Registry]\n VEN[Ventures]\n REPOS[Repos]\n ARCH[Architecture]\n STATE[Current State]\n DEC[Decisions / ADRs]\n end\n subgraph L1[\"Repo-level docs (in each source repo)\"]\n RD[README / docs / ADRs / CLAUDE.md]\n end\n\n HOME --> REG\n HOME --> VEN\n HOME --> ARCH\n HOME --> STATE\n HOME --> DEC\n REG --> REPOS\n VEN --> REPOS\n REPOS -.digest of.-> RD\n SHOW -.curated from.-> L2\n```\n\n## Page hierarchy (ASCII tree)\n\nRoutes are the eventual public/site routes; the current markdown file backing each node is shown in\nparentheses.\n\n```\nPortal Home (/) (portal/index.md)\n├── Portfolio Overview (/overview) (portal/portfolio-overview.md) ← executive briefing\n├── Ventures (/ventures) (portal/ventures/README.md)\n│ └── Venture digest (/ventures/{slug}) (portal/ventures/{slug}.md)\n├── Repos (/repos) (portal/repos/README.md)\n│ ├── Repo registry (/repos/registry) (portal/registry/repo-registry.md)\n│ └── Repo digest (/repos/{slug}) (portal/repos/{slug}.md)\n├── Capabilities (/capabilities) (portal/capabilities/README.md) ← Capability Registry\n│ └── Capability page (/capabilities/{slug}) (portal/capabilities/cap-{slug}.md)\n├── Operating Model (/operating-model) (portal/operating-model/README.md)\n│ ├── Knowledge Asset Lifecycle (portal/operating-model/knowledge-asset-lifecycle.md)\n│ ├── Concept Ownership Registry (portal/operating-model/concept-ownership.md)\n│ ├── Portfolio Glossary (authoritative) (portal/operating-model/glossary.md)\n│ ├── Context Architecture (portal/operating-model/context-architecture.md)\n│ ├── Operating Principles (portal/operating-model/operating-principles.md)\n│ └── AI Collaboration Model (portal/operating-model/ai-collaboration-model.md)\n├── Architecture Governance (/governance) (portal/governance/README.md)\n│ ├── Capability Decision Framework (portal/governance/capability-decision-framework.md)\n│ ├── Capability Decision Matrix (portal/governance/capability-decision-matrix.md)\n│ ├── Repository Lifecycle (portal/governance/repository-lifecycle.md)\n│ ├── Documentation Governance (portal/governance/documentation-governance.md)\n│ ├── AI Governance (portal/governance/ai-governance.md)\n│ └── Architecture Review Lifecycle (portal/governance/architecture-review-lifecycle.md)\n├── Architecture (/architecture) (portal/architecture/system-of-systems.md)\n│ ├── System context (layered) (# section: Mermaid)\n│ ├── Container / service map (# section: Mermaid)\n│ ├── Layer / system map (# section: Mermaid)\n│ ├── System dependency map (# section: Mermaid)\n│ ├── Intelligence Platform (/architecture/intelligence-platform) (portal/architecture/intelligence-platform.md)\n│ ├── Architecture Principles (/architecture/principles) (portal/architecture/principles.md)\n│ ├── Capability Reuse Map (/architecture/capability-reuse-map) (portal/architecture/capability-reuse-map.md)\n│ ├── Architecture Review (/architecture/architecture-review) (portal/architecture/architecture-review.md)\n│ ├── Architecture Risks (/architecture/architecture-risks) (portal/architecture/architecture-risks.md)\n│ ├── Strategic Opportunities (/architecture/strategic-opportunities) (portal/architecture/strategic-opportunities.md)\n│ ├── Architecture Evolution (/architecture/architecture-evolution) (portal/architecture/architecture-evolution.md)\n│ └── Review recommendations (/architecture/recommendations) (portal/architecture/recommendations.md)\n├── Current State (/state) (portal/current-state/status-dashboard.md)\n│ ├── Status dashboard (portal/current-state/status-dashboard.md)\n│ ├── Changelog (/state/changelog) (portal/current-state/changelog.md)\n│ └── Roadmap (/state/roadmap) (portal/current-state/roadmap.md)\n├── Decisions (/decisions) (portal/decisions/README.md)\n│ └── ADR (/decisions/{nnnn}) (portal/decisions/{nnnn}-*.md)\n├── Docs / About the portal (/about) (docs/*.md)\n│ ├── Information architecture (docs/information-architecture.md)\n│ ├── Documentation model (docs/documentation-model.md)\n│ ├── Update conventions (docs/update-conventions.md)\n│ └── Glossary (docs/glossary.md)\n└── Showcase (/showcase) [Phase C — placeholder] (showcase/README.md)\n```\n\nDepth stays within the 3-click rule: any repo digest, venture, diagram, or ADR is reachable within\n3 clicks of the portal home.\n\n## Route / URL map\n\n| Page | Route | Backing file | Nav location | Priority |\n|------|-------|--------------|--------------|----------|\n| Portal Home | `/` | `portal/index.md` | Header (logo) | High |\n| Portfolio Overview | `/overview` | `portal/portfolio-overview.md` | Header | High |\n| Ventures / Systems | `/ventures` | `portal/ventures/README.md` | Header | High |\n| Venture digest | `/ventures/{slug}` | `portal/ventures/{slug}.md` | Under Ventures | Medium |\n| Repos | `/repos` | `portal/repos/README.md` | Header | High |\n| Repo registry | `/repos/registry` | `portal/registry/repo-registry.md` | Under Repos | High |\n| Repo digest | `/repos/{slug}` | `portal/repos/{slug}.md` | Under Repos | Medium |\n| Capability Registry | `/capabilities` | `portal/capabilities/README.md` | Header | High |\n| Capability page | `/capabilities/{slug}` | `portal/capabilities/cap-{slug}.md` | Under Capabilities | Medium |\n| Operating Model | `/operating-model` | `portal/operating-model/README.md` | Header | High |\n| Operating Model pages | `/operating-model/{page}` | `portal/operating-model/*.md` | Under Operating Model | Medium |\n| Architecture Governance | `/governance` | `portal/governance/README.md` | Header | High |\n| Governance pages | `/governance/{page}` | `portal/governance/*.md` | Under Governance | Medium |\n| Architecture | `/architecture` | `portal/architecture/system-of-systems.md` | Header | High |\n| Current State | `/state` | `portal/current-state/status-dashboard.md` | Header | High |\n| Changelog | `/state/changelog` | `portal/current-state/changelog.md` | Under State | Medium |\n| Roadmap | `/state/roadmap` | `portal/current-state/roadmap.md` | Under State | Medium |\n| Decisions | `/decisions` | `portal/decisions/README.md` | Header | Medium |\n| ADR | `/decisions/{nnnn}` | `portal/decisions/{nnnn}-*.md` | Under Decisions | Low |\n| About the portal | `/about` | `docs/*` | Footer | Low |\n| Showcase | `/showcase` | `showcase/README.md` | — (Phase C) | Deferred |\n\nURL rules: lowercase, hyphenated slugs, no dates in paths, path mirrors hierarchy, slugs are stable\n(a repo/venture slug never changes once published — supersede via an ADR if it must).\n\n## Navigation model\n\n### Primary (header) nav\n`Portal Home` · `Overview` · `Capabilities` · `Repos` · `Ventures` · `Architecture` · `State` · `Decisions`\n(Capabilities and Repos are the two primary catalogue entry points.)\n\n### Section (sidebar) nav\n- Within **Repos**: registry first, then digests grouped by venture.\n- Within **Ventures**: venture list, each linking to its member repos.\n- Within **Decisions**: reverse-chronological ADR list.\n\n### Footer nav\n- **Portal**: Home, Registry, Architecture, State\n- **About**: IA, Documentation model, Update conventions, Glossary\n- **Meta**: CLAUDE.md, llms.txt, Orchestrator spec\n\n### Breadcrumbs\nMirror the route hierarchy, e.g. `Home > Repos > {repo}` and `Home > Ventures > {venture}`.\n\n## Internal linking rules (portal-specific)\n\n1. **No orphan digests** — every repo digest is linked from the registry and from at least one venture.\n2. **Bidirectional venture ↔ repo links** — a venture lists its repos; each repo names its venture.\n3. **Architecture pages link to the digests** of every node they draw, and vice versa.\n4. **ADRs backlink** to the pages/diagrams they affect; affected pages link forward to the ADR.\n5. Descriptive anchor text; never \"click here\".\n\n## Change control for the IA\n\nThe structure on this page is itself governed by ADRs. Changing the layer model, the top-level nav,\nor the routing scheme requires an ADR in [`portal/decisions/`](../portal/decisions/). Do not\nrestructure folders ad hoc — see [`docs/update-conventions.md`](/about/update-conventions).\n"},{"id":"/about/update-conventions","kind":"page","entityType":"meta","title":"Update Conventions","route":"/about/update-conventions","sourcePath":"docs/update-conventions.md","slug":null,"frontmatter":{"title":"Update Conventions","type":"how-to","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Recipes for keeping the portal accurate and internally consistent. These conventions are the","headings":[{"depth":2,"text":"Cadence","id":"cadence"},{"depth":2,"text":"Recipe: add a repo","id":"recipe-add-a-repo"},{"depth":2,"text":"Recipe: add a venture / system","id":"recipe-add-a-venture-system"},{"depth":2,"text":"Recipe: record a decision","id":"recipe-record-a-decision"},{"depth":2,"text":"Recipe: update a diagram","id":"recipe-update-a-diagram"},{"depth":2,"text":"Consistency invariants (must always hold)","id":"consistency-invariants-must-always-hold"},{"depth":2,"text":"Generated vs human-authored regions","id":"generated-vs-human-authored-regions"},{"depth":2,"text":"Definition of done","id":"definition-of-done"}],"diagrams":0,"links":["../templates/repo-digest.template.md","../portal/registry/repo-registry.md","../portal/architecture/system-of-systems.md","../templates/venture-digest.template.md","../templates/adr.template.md","../CLAUDE.md"],"body":"\n# Update Conventions\n\nRecipes for keeping the portal accurate and internally consistent. These conventions are the\ncontract that both human maintainers and the future `portfolio-portal-orchestrator` skill follow.\n\n## Cadence\n\n| Trigger | Update |\n|---------|--------|\n| A repo is created / renamed / archived | Repo digest + registry row + affected venture(s) + changelog |\n| A repo's stack or purpose changes materially | Its digest (`last_reviewed`) + registry row + changelog |\n| A new cross-repo relationship or dependency | Architecture diagrams + both digests + changelog |\n| A structural/portal decision | New ADR + changelog + any affected page backlinks |\n| A duplicated capability is noticed across repos | Note on both digests + a `duplication` flag + possible ADR |\n| Roadmap shifts | `current-state/roadmap.md` + changelog |\n| Monthly review | Re-verify `last_reviewed` dates; sweep for orphans & dead links |\n\n## Recipe: add a repo\n\n1. Copy [`templates/repo-digest.template.md`](../templates/repo-digest.template.md) →\n `portal/repos/.md`.\n2. Fill in every field; use `Unknown`/`TBD` where you don't yet know — do not guess.\n3. Add a row to [`portal/registry/repo-registry.md`](/registry/repo-registry).\n4. Link the repo from its venture digest (create the venture first if needed).\n5. If it introduces a new cross-repo edge, update the diagrams in\n [`portal/architecture/system-of-systems.md`](/architecture/system-of-systems).\n6. Add a changelog line and update the status dashboard counts.\n\n## Recipe: add a venture / system\n\n1. Copy [`templates/venture-digest.template.md`](../templates/venture-digest.template.md) →\n `portal/ventures/.md`.\n2. List member repos (each must have a digest + registry row).\n3. Add or update the **Venture map** diagram in the architecture page.\n4. Changelog line.\n\n## Recipe: record a decision\n\n1. Copy [`templates/adr.template.md`](../templates/adr.template.md) →\n `portal/decisions/NNNN-kebab-title.md` (next free zero-padded number).\n2. Set `status: proposed` → move to `accepted` when decided. Never edit an accepted ADR's decision;\n supersede it with a new ADR and set the old one to `superseded`.\n3. Backlink from every page the decision affects; forward-link from those pages to the ADR.\n4. Changelog line.\n\n## Recipe: update a diagram\n\n1. Edit the embedded Mermaid block in the relevant `portal/architecture/` page.\n2. Keep node IDs stable (rename labels, not IDs) so diffs stay readable.\n3. Ensure every node maps to a real digest and every digest that participates is drawn.\n4. Changelog line if the topology changed.\n\n## Consistency invariants (must always hold)\n\n- Every repo digest ⇄ exactly one registry row (no orphans, no duplicates).\n- Every venture ⇄ its member repos are mutually linked.\n- Every architecture node ⇄ a real digest.\n- No dead internal links; no silent blanks (use explicit placeholders).\n- `last_reviewed` on any page you touched is today's date.\n\n## Generated vs human-authored regions\n\nThe orchestrator will eventually own regions wrapped in `` markers and must\npreserve `` regions verbatim. Until the skill exists, humans may edit both, but should\nkeep hand-written prose inside `` so it survives the first automated run.\n\n## Definition of done\n\nSee the checklist at the end of [`CLAUDE.md`](/CLAUDE).\n"},{"id":"/about/website-implementation-plan","kind":"page","entityType":"meta","title":"Website Implementation Plan (Phase G — planning only)","route":"/about/website-implementation-plan","sourcePath":"docs/website-implementation-plan.md","slug":null,"frontmatter":{"title":"Website Implementation Plan (Phase G — planning only)","type":"explanation","status":"draft","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"A comprehensive, review-ready plan to transform the Portfolio Architecture Portal from a markdown knowledge","headings":[{"depth":2,"text":"0. Technology validation (Astro stack — confirmed, with one recommendation)","id":"0-technology-validation-astro-stack-confirmed-with-one-recommendation"},{"depth":2,"text":"1. Current State Assessment","id":"1-current-state-assessment"},{"depth":3,"text":"Current structure (evidence-based)","id":"current-structure-evidence-based"},{"depth":3,"text":"Strengths","id":"strengths"},{"depth":3,"text":"Weaknesses (for web presentation)","id":"weaknesses-for-web-presentation"},{"depth":3,"text":"Technical debt (site-relevant, not content defects)","id":"technical-debt-site-relevant-not-content-defects"},{"depth":3,"text":"Opportunities","id":"opportunities"},{"depth":3,"text":"Risks (summarised; full register in Section 10)","id":"risks-summarised-full-register-in-section-10"},{"depth":2,"text":"2. Proposed Architecture","id":"2-proposed-architecture"},{"depth":3,"text":"Repository placement (additive, non-disruptive)","id":"repository-placement-additive-non-disruptive"},{"depth":3,"text":"Content structure & routing model","id":"content-structure-routing-model"},{"depth":3,"text":"Astro project layout","id":"astro-project-layout"},{"depth":3,"text":"Component hierarchy","id":"component-hierarchy"},{"depth":3,"text":"Navigation model","id":"navigation-model"},{"depth":3,"text":"Search architecture","id":"search-architecture"},{"depth":3,"text":"Mermaid rendering strategy","id":"mermaid-rendering-strategy"},{"depth":3,"text":"Metadata strategy","id":"metadata-strategy"},{"depth":3,"text":"Deployment architecture","id":"deployment-architecture"},{"depth":2,"text":"3. Content Strategy","id":"3-content-strategy"},{"depth":3,"text":"Frontmatter","id":"frontmatter"},{"depth":3,"text":"Related pages","id":"related-pages"},{"depth":3,"text":"Navigation generation","id":"navigation-generation"},{"depth":3,"text":"Search indexing","id":"search-indexing"},{"depth":3,"text":"Diagram rendering","id":"diagram-rendering"},{"depth":3,"text":"Link rewriting (the one build-time transform)","id":"link-rewriting-the-one-build-time-transform"},{"depth":2,"text":"4. Migration Strategy","id":"4-migration-strategy"},{"depth":2,"text":"5. User Experience","id":"5-user-experience"},{"depth":3,"text":"Homepage (/)","id":"homepage"},{"depth":3,"text":"Navigation","id":"navigation"},{"depth":3,"text":"Page types & their experience","id":"page-types-their-experience"},{"depth":3,"text":"How users move through the site","id":"how-users-move-through-the-site"},{"depth":2,"text":"6. Design System","id":"6-design-system"},{"depth":3,"text":"Reference characteristics (adopted, not copied)","id":"reference-characteristics-adopted-not-copied"},{"depth":3,"text":"Typography","id":"typography"},{"depth":3,"text":"Colour strategy","id":"colour-strategy"},{"depth":3,"text":"Spacing, cards, navigation, responsiveness","id":"spacing-cards-navigation-responsiveness"},{"depth":3,"text":"Diagrams","id":"diagrams"},{"depth":3,"text":"Dark/light mode","id":"dark-light-mode"},{"depth":3,"text":"Accessibility (design-level)","id":"accessibility-design-level"},{"depth":2,"text":"7. Components","id":"7-components"},{"depth":2,"text":"8. Implementation Roadmap","id":"8-implementation-roadmap"},{"depth":2,"text":"9. Validation Strategy","id":"9-validation-strategy"},{"depth":2,"text":"10. Risks and Recommendations","id":"10-risks-and-recommendations"},{"depth":3,"text":"Top recommendations","id":"top-recommendations"},{"depth":2,"text":"Alignment with existing portal work (built upon, not duplicated)","id":"alignment-with-existing-portal-work-built-upon-not-duplicated"},{"depth":2,"text":"Post-approval next steps (NOT done in Phase G)","id":"post-approval-next-steps-not-done-in-phase-g"}],"diagrams":3,"links":["../portal/architecture/principles.md","information-architecture.md","../portal/governance/documentation-governance.md","../portal/architecture/architecture-risks.md","information-architecture.md","information-architecture.md","information-architecture.md","../portal/governance/architecture-review-lifecycle.md","../portal/governance/documentation-governance.md","../portal/registry/repo-registry.md","../portal/capabilities/README.md","../portal/portfolio-overview.md","../portal/architecture/principles.md","../portal/operating-model/README.md","../portal/governance/README.md","../portal/decisions/README.md","../portal/architecture/architecture-review.md","../portal/architecture/capability-reuse-map.md","../portal/architecture/system-of-systems.md","information-architecture.md"],"body":"\n# Website Implementation Plan (Phase G)\n\nA comprehensive, review-ready plan to transform the Portfolio Architecture Portal from a markdown knowledge\nbase into a modern, navigable **website** — while keeping the **markdown as the single source of truth**. This\ndocument is **planning only**: no existing files were modified, moved, renamed, or deleted; no code was\ngenerated; no content was rewritten. This is the *only* new file added in Phase G, and it is deliberately **not\nwired into navigation** (that is a post-approval step) to honour the \"no modifications\" constraint.\n\n> **Guiding principle:** the website is a **presentation layer** over the existing markdown. The markdown in\n> `portal/`, `docs/`, `ai/`, `templates/`, and the ADRs remains authoritative; the site *renders* it, never\n> replaces it. This is the portal's own [Principle 2 (definition vs. derivation)](/architecture/principles)\n> applied to itself — content is the definition, the built site is the derivation.\n\n---\n\n## 0. Technology validation (Astro stack — confirmed, with one recommendation)\n\nThe proposed stack — **Astro + Markdown/MDX + Mermaid + Cloudflare Pages + static search + SSG + optional\nReact** — is an excellent fit for a markdown-first documentation site. It is affirmed. One material\nrecommendation is added.\n\n| Requirement | Why the stack fits |\n|-------------|--------------------|\n| Markdown is source of truth | Astro 5 **Content Layer** loads markdown from arbitrary paths via a `glob()` loader — **files stay exactly where they are** (no moves). |\n| Static, fast, cheap | Astro SSG → static HTML; near-zero JS by default (\"islands\"). Ideal on Cloudflare Pages' free static hosting + global CDN. |\n| Search over markdown | **Pagefind** indexes the built HTML at build time — fully static, no server, no external service (aligns with \"knowledge referenced, never owned\"). |\n| 60 Mermaid diagrams, dark/light | Mermaid integrates at build-time (SVG) or client-side (theme-aware). Handled below. |\n| Optional interactivity | React (or Preact/vanilla) islands only where genuinely beneficial (search UI, relationship graph). |\n\n**Recommendation — evaluate Astro _Starlight_ as the base, not bespoke Astro.**\n[Starlight](https://starlight.astro.build) is Astro's official documentation framework. It provides, out of\nthe box, exactly what this portal needs and would otherwise be hand-built: responsive sidebar navigation,\n**Pagefind search**, dark/light mode, accessible components, \"edit this page\" links, table-of-contents,\nprev/next, and SEO metadata. It is still Astro — MDX, custom components, and content collections all work.\n\n| Option | Pros | Cons | Verdict |\n|--------|------|------|---------|\n| **A: Astro + Starlight (recommended)** | Nav, search, theming, a11y, TOC free; weeks of effort saved; still fully customisable | Opinionated layout; must map portal structure to Starlight's sidebar; some restyling to hit the target design | **Recommended** — start here |\n| B: Bespoke Astro | Total control over layout/design | Rebuild nav, search wiring, theming, a11y from scratch; slower; more maintenance | Fallback if the design demands a layout Starlight can't express |\n| C: Other frameworks (Next.js, Docusaurus, VitePress) | Each capable | Next.js = heavier/SSR-oriented, overkill for static; Docusaurus/VitePress are React/Vue-locked and less flexible than Astro's islands; none beat Astro for \"mostly static + occasional interactivity\" | Not recommended |\n\nThe rest of this plan is written to work under **either** A or B; where they differ, both paths are noted.\n\n---\n\n## 1. Current State Assessment\n\n### Current structure (evidence-based)\n- **75 markdown files.** `portal/` = 52, `docs/` = 4, `templates/` = 8, `ai/` = 3, `design/` = 2, `showcase/` = 2,\n `skills/` = 2, root = `README.md` + `CLAUDE.md` (+ `llms.txt`).\n- `portal/` sub-sections: `repos/`, `ventures/`, `capabilities/`, `architecture/`, `operating-model/`,\n `governance/`, `decisions/`, `current-state/`, `registry/`, plus `index.md`, `portfolio-overview.md`.\n- **All 56 `portal/`+`docs/` pages carry consistent YAML frontmatter** (`title`, `type`, `status`,\n `last_reviewed`, `owner`, plus type-specific keys: `slug`, `layer`, `providers`, `consumers`, `adr_number`, …).\n- **60 Mermaid diagrams across 40 files** (mostly `graph TD/LR`; one `quadrantChart` in `architecture-risks.md`).\n- `llms.txt` machine index; internal links are relative markdown paths; **0 broken internal links** (verified each phase).\n- Conventions: Diátaxis `type`, ``/`` region markers, kebab-case slugs, zero-padded ADR numbering, templates in `templates/`.\n\n### Strengths\n- **Exceptional content quality and consistency** — uniform frontmatter, templates, cross-linking, Diátaxis typing.\n- **Rich structured metadata** already present (layers, maturity, providers/consumers, ADR status) — directly usable to generate cards, badges, and filters *without new content*.\n- **Diagrams are inline Mermaid** (text) — versionable, diffable, and renderable to SVG.\n- **A machine index (`llms.txt`) and an explicit [Information Architecture](/about/information-architecture)** already define the nav model and routes — the site can derive navigation from these.\n- **Governance already exists** ([Documentation Governance](/governance/documentation-governance)) defining source-of-truth per artefact — the site build must respect it.\n\n### Weaknesses (for web presentation)\n- **No `description`/summary frontmatter field** for SEO meta and card subtitles (first paragraph can be used, but an optional field is cleaner).\n- **No explicit sidebar ordering** — order is currently implied by the IA doc, not machine-declared.\n- **Relative links are markdown-file paths** (`../repos/x.md`) — these must resolve to *routes* (`/repos/x`) at build; a link-rewrite step or Astro's markdown link handling is required.\n- **Section index pages are `README.md`** — fine, but routing must map `portal/x/README.md → /x/`.\n- **`design/brand-tokens.md` is a placeholder** (`TBD` values) — the design system must be defined (Section 6).\n- **One newer Mermaid type** (`quadrantChart`) needs a renderer that supports it.\n\n### Technical debt (site-relevant, not content defects)\n- Manual portal upkeep (already flagged as [Risk R8](/architecture/architecture-risks)) — the site build should add **automated validation** (links, frontmatter, Mermaid) to reduce it.\n- Two glossaries (`docs/glossary.md` scoped to portal-maintenance; `portal/operating-model/glossary.md` authoritative) — the site should present the authoritative one prominently and label the other.\n\n### Opportunities\n- Turn structured frontmatter into **interactive registries** (filter/sort capabilities, repos, ADRs).\n- Render the **layered architecture, dependency map, and reuse map** as first-class visual navigation.\n- **Search across the whole knowledge base** (Pagefind) — a major usability gain over browsing GitHub.\n- A polished site materially advances the deferred **public showcase** goal (Phase A/C) — scale & sophistication become visible.\n\n### Risks (summarised; full register in Section 10)\n- Link/route mismatch during rendering; Mermaid rendering at scale (60 diagrams) and theme-sync; frontmatter gaps for meta; keeping the build in sync with additive content conventions; scope creep into bespoke design.\n\n---\n\n## 2. Proposed Architecture\n\n### Repository placement (additive, non-disruptive)\nThe site lives in a **new top-level `site/` directory**; **all existing content stays in place**. The Astro\ncontent layer reads markdown from `../portal`, `../docs`, `../skills`, etc. via glob loaders.\n\n```\nportfolio-portal/ (unchanged root)\n├── portal/ docs/ ai/ templates/ skills/ showcase/ ← UNCHANGED source of truth\n├── llms.txt README.md CLAUDE.md ← UNCHANGED\n└── site/ ← NEW, additive (the website project)\n ├── astro.config.mjs\n ├── package.json\n ├── content.config.ts (glob loaders pointing at ../portal/**, ../docs/**)\n ├── public/ (favicon, static assets, og images)\n └── src/\n ├── content/ (collection *definitions* only; data loaded from ../portal)\n ├── components/ (cards, badges, diagram, graph — Section 7)\n ├── layouts/ (Base, DocPage, RegistryPage)\n ├── pages/ (route files or Starlight config)\n ├── lib/ (nav builder, link rewriter, frontmatter helpers)\n └── styles/ (design tokens, theme — Section 6)\n```\n\n> **Why `site/` as a sibling, not a rewrite:** it is purely additive (Migration Strategy, Section 4), keeps the\n> knowledge base pristine, and lets the site be deleted/rebuilt without touching content. It mirrors the\n> ecosystem's own \"definition vs derivation\" split.\n\n### Content structure & routing model\n\n| Source (unchanged) | Route | Page kind |\n|--------------------|-------|-----------|\n| `portal/index.md` | `/` (or `/portal`) | Portal home |\n| `portal/portfolio-overview.md` | `/overview` | Overview |\n| `portal/repos/.md` | `/repos/` | Repository page |\n| `portal/repos/README.md` | `/repos` | Repos index (interactive) |\n| `portal/capabilities/cap-.md` | `/capabilities/` | Capability page |\n| `portal/capabilities/README.md` | `/capabilities` | Capability Registry (interactive) |\n| `portal/ventures/.md` | `/ventures/` | Venture/system page |\n| `portal/architecture/*.md` | `/architecture/*` | Architecture pages |\n| `portal/operating-model/*.md` | `/operating-model/*` | Operating Model |\n| `portal/governance/*.md` | `/governance/*` | Governance |\n| `portal/decisions/NNNN-*.md` | `/decisions/NNNN-*` | ADR |\n| `docs/*.md` | `/about/*` | Portal meta-docs |\n\nRouting derives from the existing folder structure and the [Information Architecture](/about/information-architecture)\nroute map — **no new IA is invented**; the site adopts the documented one.\n\n### Astro project layout\n- **Content collections** (Astro 5 Content Layer): one collection per portal section, each a `glob()` loader\n over the existing directory, with a Zod schema that **mirrors current frontmatter** (all fields optional\n except `title`) so nothing needs rewriting.\n- **Dynamic routes**: `src/pages/[...slug].astro` (or Starlight's auto-routing) maps collection entries to routes.\n- **Layouts**: `BaseLayout` (head/meta/theme) → `DocLayout` (sidebar + TOC + content) → specialised\n `RegistryLayout` (interactive index pages).\n\n### Component hierarchy\n\n```mermaid\ngraph TD\n Base[BaseLayout
head · theme · skip-link] --> Doc[DocLayout
sidebar · TOC · breadcrumbs · prev/next]\n Base --> Registry[RegistryLayout
filterable grids]\n Doc --> MD[MarkdownContent]\n MD --> Mermaid[ArchitectureDiagram]\n MD --> Callout\n Registry --> CapCard[CapabilityCard]\n Registry --> RepoCard[RepositoryCard]\n Registry --> VenCard[VentureCard]\n Registry --> ADR[ADRSummary]\n CapCard --> Badge[StatusBadge / TechBadge]\n RepoCard --> Badge\n```\n\n### Navigation model\n- **Top nav (header):** Overview · Capabilities · Repos · Ventures · Architecture · Operating Model · Governance\n · Decisions — exactly the [documented header nav](/about/information-architecture).\n- **Left sidebar:** section tree derived from folders + an optional `sidebar` order/group frontmatter key\n (additive; falls back to alphabetical + README-first).\n- **Right TOC:** generated from page headings (Starlight/`rehype` autolink).\n- **Breadcrumbs:** mirror the route hierarchy (matches the IA breadcrumb rule).\n- **In-page cross-links:** existing markdown links, rewritten `*.md → route`.\n\n### Search architecture\n**Pagefind** (static, build-time): after Astro builds HTML, Pagefind indexes it and ships a tiny client bundle.\nZero infrastructure, works on Cloudflare Pages, respects the \"no external service\" preference. Search UI is a\nsmall island (modal, `/` to focus). Frontmatter (`type`, `layer`, `maturity`) can be emitted as Pagefind\nfilters for faceted search (e.g. \"capabilities that are operational\").\n\n### Mermaid rendering strategy\n- **Primary: client-side, theme-aware rendering** via a Mermaid integration (e.g. `astro-mermaid` or a small\n rehype step that leaves ` ```mermaid ` blocks for a client script). Rationale: 60 diagrams with a hard\n **dark/light** requirement — client-side re-renders on theme switch trivially, and supports newer types\n (`quadrantChart`).\n- **Optimization (optional, later): build-time SVG** (`rehype-mermaid` + headless Chromium) for zero-JS,\n faster first paint, and SSR-safe output — adopt if diagram-heavy pages need it. Note this adds a Playwright\n build dependency and must be verified against `quadrantChart`.\n- **Decision:** ship client-side first (fast to build, theme-correct), measure, then selectively pre-render.\n- Every diagram gets an accessible caption/`aria-label` (Section 9) and a horizontal-scroll container so wide\n graphs never break the layout.\n\n### Metadata strategy\n- **Per-page:** `title` + `description` (from frontmatter if present, else first paragraph) → ``,\n meta description, Open Graph/Twitter cards, canonical URL.\n- **Structured:** `type`, `status`, `last_reviewed`, `owner`, `layer`, `maturity` surfaced as visible\n page metadata (a \"page info\" strip) and as Pagefind filters.\n- **Site-level:** sitemap.xml (`@astrojs/sitemap`), robots.txt, a generated `llms.txt` parity check (the site\n can validate its routes against the existing `llms.txt`).\n- **OG images:** optional generated social cards per page (title + type + layer) — a Phase-4 nicety.\n\n### Deployment architecture\n\n```mermaid\ngraph LR\n DEV[git push to main] --> CF[Cloudflare Pages CI]\n CF --> BUILD[astro build + pagefind index]\n BUILD --> STATIC[Static assets]\n STATIC --> CDN[Cloudflare global CDN]\n PR[Pull request] -.preview deploy.-> PREVIEW[per-PR preview URL]\n CDN --> USER((Visitors))\n```\n\n- **Cloudflare Pages**, Git-connected: build on push to `main`; **preview deployments per PR** (a natural\n review gate that fits the portal's governance).\n- Static output only (no Workers needed for v1). Custom domain optional. Build command `npm run build`\n (runs `astro build` then `pagefind`), output dir `site/dist`.\n\n---\n\n## 3. Content Strategy\n\n**Files stay where they are.** The Astro content layer loads them in place via glob loaders — no content moves,\nrenames, or rewrites. This is the single most important content decision and it is fully supported by Astro 5.\n\n### Frontmatter\n- **No rewrite required.** The collection schema mirrors existing fields; everything except `title` is optional.\n- **Recommended additive (optional) fields**, applied lazily/only where useful, never in bulk:\n - `description` — one-line summary for meta + card subtitle (else derived from first paragraph).\n - `sidebar` — `{ order, group, label }` for deterministic nav (else folder + README-first + alphabetical).\n - `hidden: true` — exclude a page (e.g. templates) from the public site if desired.\n- Adding these is **purely additive** and can be done page-by-page over time; the site works without them.\n\n### Related pages\nGenerated from **existing signals**, not new content:\n- Same-section siblings (folder).\n- Frontmatter relationships (`providers`, `consumers`, `layer`, `system`) → \"related repos/capabilities\".\n- Outbound markdown links already present in each page.\n- ADRs referenced by a page ↔ pages referenced by an ADR (bidirectional, from link graph).\n\n### Navigation generation\nDerived from (a) folder structure, (b) the [Information Architecture](/about/information-architecture) route/nav\ntables, and (c) optional `sidebar` frontmatter. No hand-maintained nav file that can drift.\n\n### Search indexing\nPagefind indexes the built HTML (post-build). Frontmatter `type`/`layer`/`maturity` emitted as filters.\n`templates/` and any `hidden` pages excluded from the index.\n\n### Diagram rendering\n` ```mermaid ` fenced blocks are detected and rendered (client-side, theme-aware) — the existing blocks are used\n**as-is**. No diagram content is rewritten. Wide diagrams scroll within their container.\n\n### Link rewriting (the one build-time transform)\nA small rehype/remark step rewrites internal `*.md` links to routes (`../repos/x.md#sec → /repos/x#sec`) at\nbuild time. Source markdown is untouched on disk; the transform happens in the render pipeline only.\n\n---\n\n## 4. Migration Strategy\n\nEvery proposed change is **additive**; the knowledge base is not restructured. Ordered by necessity.\n\n| # | Change | What | Why | Benefits | Risks | Alternatives considered |\n|---|--------|------|-----|----------|-------|-------------------------|\n| M1 | **Add `site/` project** | New sibling dir with Astro app | Presentation layer without touching content | Clean separation; deletable/rebuildable | Repo now has app deps (`node_modules`, lockfile) | Separate repo (rejected: splits source of truth from presentation, harder sync) |\n| M2 | **Glob content loaders** | `content.config.ts` reads `../portal/**`, `../docs/**` | Files stay put | Zero content moves; no broken git history | Loader path fragility if folders move | Move content into `src/content/` (rejected: disruptive, violates \"prefer additive\") |\n| M3 | **Build-time link rewrite** | remark/rehype `.md`→route | Links must resolve as web routes | Existing links \"just work\" on the site | Edge cases (anchors, README index) need tests | Rewrite links in source (rejected: modifies content) |\n| M4 | **Optional additive frontmatter** | `description`, `sidebar`, `hidden` where useful | Better meta/nav | Cleaner cards & SEO | Inconsistent if half-applied | Derive everything from body (kept as fallback) |\n| M5 | **Define design tokens** | Fill `design/brand-tokens.md` + `site/src/styles` | Placeholder today | Real visual identity | Design bikeshedding | Use a theme's defaults (fallback for v1) |\n| M6 | **Add build validation** | link/frontmatter/Mermaid checks in CI | Reduce manual-upkeep debt (R8) | Broken links caught pre-deploy | CI time | Manual checks (status quo) |\n| M7 | **`.gitignore` additions** | ignore `site/node_modules`, `site/dist`, `.astro` | Keep repo clean | Standard hygiene | None | — |\n\n**Disruption assessment:** M1–M3, M6–M7 touch only the new `site/` dir and (M7) the existing `.gitignore` (a\none-line additive edit at implementation time, **not now**). M4–M5 are optional and incremental. **No content\nfile is moved, renamed, or rewritten.**\n\n---\n\n## 5. User Experience\n\n### Homepage (`/`)\nA confident landing that answers \"what is this ecosystem?\" in 10 seconds, then routes deeper. Sections:\nhero (the vision one-liner), the **layered architecture diagram** (interactive), quick-links to the two primary\nregistries (Capabilities, Repos), current phase/status, and \"start here\" cards (Overview, Operating Model,\nGovernance). Sourced from `portfolio-overview.md` + `index.md` — no new copy invented.\n\n### Navigation\nPersistent header (primary sections) + collapsible left sidebar (section tree) + right TOC + breadcrumbs +\nsearch (`/`). Mobile: header collapses to a menu; sidebar becomes a drawer.\n\n### Page types & their experience\n| Page | Experience |\n|------|------------|\n| **Architecture pages** | Long-form + prominent, theme-aware Mermaid; a \"diagram index\" for the multi-view pages (intelligence-platform, system-of-systems) |\n| **Capability pages** | Header with StatusBadge + owning/consuming repo chips; the 4-view diagrams (Website Assessment) as tabbed or sequential sections |\n| **Capability Registry** | **Interactive filterable grid** of CapabilityCards (filter by maturity/layer/owner) |\n| **Repository pages** | RepositoryCard header (lifecycle, maturity, languages, tech badges) + digest body |\n| **Repos Registry** | Filterable RepositoryCard grid + a table view toggle |\n| **Venture pages** | VentureCard header + member-repo links + system-map diagram |\n| **Governance pages** | Decision trees rendered as Mermaid; the Decision Matrix as a styled table with anchor links |\n| **Glossary** | Searchable term list (jump-to-letter); each term shows owner/related/first-class; links to concept pages |\n| **Operating Model** | Lifecycle diagrams front-and-centre; activity-type legend (human/AI/automated/future) as a reusable Legend component |\n| **ADRs** | ADRSummary header (status badge, supersedes/superseded-by links) + body; a decisions timeline |\n\n### How users move through the site\n```mermaid\ngraph LR\n HOME[Home] --> OV[Overview]\n HOME --> SEARCH[Search]\n OV --> CAP[Capability Registry] --> CAPX[Capability page] --> REPO[Repo page]\n OV --> ARCH[Architecture] --> DIAG[Dependency map] --> REPO\n REPO --> ADR[Related ADRs]\n ANY[Any page] --> GLOSS[Glossary term]\n ANY --> SEARCH\n```\nThree entry patterns: **browse** (nav/sidebar), **search** (Pagefind, faceted), and **follow relationships**\n(cards, related links, diagram nodes → pages).\n\n---\n\n## 6. Design System\n\nFill the existing `design/brand-tokens.md` placeholder and encode tokens in `site/src/styles`. The visual\nlanguage is **technical, editorial, and calm** — content-first, high signal-to-noise.\n\n### Reference characteristics (adopted, not copied)\n- **Stripe** — restrained colour, confident typographic hierarchy, generous whitespace, crisp tables.\n- **Vercel** — high-contrast minimalism, excellent dark mode, tight card grids.\n- **Cloudflare Docs** — dense-but-navigable docs IA, strong sidebar/TOC, code/diagram legibility.\n- **Microsoft Learn** — structured metadata strips, progressive disclosure, accessible components.\nWe adopt: *typographic hierarchy, whitespace discipline, dark-mode-first contrast, metadata strips, and\ndiagram legibility* — not any specific implementation or brand look.\n\n### Typography\n- A clean humanist **sans** for UI/headings (e.g. Inter/IBM Plex Sans class) and a legible body face; a mono\n for code/IDs/slugs. Self-hosted (no external font fetch, aligns with static/privacy goals).\n- Modular scale (~1.2), long-form measure ≤ 72ch, clear H1–H4 rhythm.\n\n### Colour strategy\n- **Neutral-dominant** palette with **one brand accent** + semantic status colours mapped to the portal's own\n vocabulary: ✅ operational (green), 🔶 partial/early (amber), ⏳ planned (grey-blue), ❌/risk (red),\n proposed (violet). These already exist as emoji markers in content — the design formalises them.\n- WCAG-checked (see Section 9); accent used sparingly for links/CTAs/active-nav.\n\n### Spacing, cards, navigation, responsiveness\n- 4/8px spacing scale; generous section spacing; sticky header + sidebar.\n- **Cards** are the core unit (capability/repo/venture/ADR) — consistent padding, badge row, title, one-line\n summary, footer links.\n- Responsive breakpoints: sidebar drawer < 1024px; single-column < 768px; tables/diagrams scroll horizontally\n in their own container (never break the page).\n\n### Diagrams\n- Mermaid theme variables bound to design tokens, with **two variants** (light/dark) that switch with the site\n theme; captions + accessible descriptions; max-width with horizontal scroll.\n\n### Dark/light mode\n- **Dark-mode-first**, both fully supported; respect `prefers-color-scheme`; a toggle persists choice; Mermaid\n re-renders on switch. (Starlight provides this; bespoke Astro must implement it.)\n\n### Accessibility (design-level)\n- AA contrast for body & UI; visible focus rings; skip-to-content; semantic landmarks; reduced-motion honoured.\n Full validation in Section 9.\n\n---\n\n## 7. Components\n\n| Component | Responsibility | Data source |\n|-----------|----------------|-------------|\n| **CapabilityCard** | Summarise a capability: name, one-liner, maturity badge, owning/consuming chips, link | capability frontmatter |\n| **RepositoryCard** | Summarise a repo: name, lifecycle + maturity badges, layer, tech badges, link | repo frontmatter |\n| **VentureCard** | Summarise a venture/system: name, lifecycle, member-repo count, layer | venture frontmatter |\n| **ArchitectureDiagram** | Render a Mermaid block: theme-aware, caption, a11y desc, scroll container, \"copy source\" | ` ```mermaid ` blocks |\n| **StatusBadge** | Map status/maturity/lifecycle → coloured pill (operational/partial/planned/…) | frontmatter fields |\n| **TechnologyBadge** | Small labelled chip for a technology (Astro, Supabase, Cloudflare…) | frontmatter/`Technologies` |\n| **PrincipleCard** | Numbered principle: title, source citation, \"ecosystem application\" | principles page |\n| **ADRSummary** | ADR header: number, title, status badge, date, supersedes/superseded-by | ADR frontmatter |\n| **Timeline** | Ordered events (ADR history; portal phases A–G; roadmap) | changelog/decisions |\n| **RelationshipGraph** | Interactive dependency/capability graph (nodes → pages) — optional React island over the Mermaid data | dependency map / frontmatter relationships |\n| **Legend** | Explain the ✅/🔶/⏳/❌ and human/AI/automated markers | static |\n| **PageInfo** | Metadata strip: type, status, last_reviewed, owner, layer | frontmatter |\n| **Breadcrumbs / TOC / SidebarNav / SearchModal** | Standard doc chrome | derived / Pagefind |\n| **Callout** | Note/warning/recommendation blocks (map the portal's `>` blockquotes + emoji) | markdown |\n\nComponents are **presentation-only** and **derive from existing frontmatter/content** — none require new\ncontent. Most are static; only `RelationshipGraph` and `SearchModal` are interactive islands (React/Preact or\nvanilla), used because they are genuinely better interactive.\n\n---\n\n## 8. Implementation Roadmap\n\nIncremental; the site is deployable and useful from Phase 1 onward.\n\n| Phase | Objective | Deliverables | Est. effort | Dependencies | Risks |\n|-------|-----------|--------------|-------------|--------------|-------|\n| **G1 — Skeleton & content pipeline** | Astro (Starlight) app renders all markdown in place | `site/` project; glob loaders; schemas mirroring frontmatter; link-rewrite; routes for every page; deploy to Cloudflare Pages (preview) | ~2–3 days | Approval; Node toolchain | Link-rewrite edge cases; loader paths |\n| **G2 — Navigation & search** | Full nav + working search | Header/sidebar/TOC/breadcrumbs from IA + folders; **Pagefind** search with filters | ~1–2 days | G1 | Sidebar ordering without `sidebar` frontmatter |\n| **G3 — Mermaid & diagrams** | All 60 diagrams render, theme-aware | ArchitectureDiagram component; dark/light Mermaid; scroll containers; `quadrantChart` verified | ~1–2 days | G1 | `quadrantChart` support; perf on diagram-heavy pages |\n| **G4 — Design system & components** | Target visual design + cards/badges | Tokens (fill `brand-tokens.md`); typography/colour/spacing; CapabilityCard/RepositoryCard/VentureCard/StatusBadge/TechBadge/ADRSummary/PageInfo | ~3–5 days | G1–G3 | Design scope creep |\n| **G5 — Interactive registries** | Filterable Capability/Repo registries | Registry pages with filter/sort; table/grid toggle; Timeline | ~2–3 days | G4 | Island complexity |\n| **G6 — Metadata, SEO, validation, polish** | Production quality | sitemap/robots/OG; a11y pass; Lighthouse; CI validation (links/frontmatter/Mermaid); optional OG images; optional RelationshipGraph | ~2–4 days | G1–G5 | A11y/perf fixes |\n\n**Sequencing rule:** the site stays functional after each phase (G1 already renders everything; later phases\nenhance). Effort is indicative for a single implementer; each phase ends with a review gate per the portal's own\n[Architecture Review Lifecycle](/governance/architecture-review-lifecycle).\n\n---\n\n## 9. Validation Strategy\n\n| Dimension | How success is verified |\n|-----------|-------------------------|\n| **Link validation** | Build fails on broken internal links; external-link check in CI; parity check of routes vs `llms.txt`. Reuse the existing link-check discipline (0 broken links today). |\n| **Mermaid rendering** | Automated check that every ` ```mermaid ` block renders without error (including `quadrantChart`); visual spot-check in light & dark. |\n| **Search** | Pagefind index built; smoke tests for known queries (e.g. \"Website Assessment\", \"ADR 0005\"); filters return correct sets. |\n| **Metadata** | Every page has `<title>` + description + canonical + OG; sitemap complete; PageInfo shows frontmatter. |\n| **Responsiveness** | Manual + automated viewport checks (320/768/1024/1440); no horizontal page scroll; diagrams/tables scroll in-container. |\n| **Accessibility** | axe/Pa11y in CI; AA contrast; keyboard nav; focus visible; skip-link; landmarks; reduced-motion; diagram alt text. |\n| **Performance** | Lighthouse ≥ 95 perf/SEO/best-practices on key pages; minimal JS; self-hosted fonts; image sizing. |\n| **Deployment** | Cloudflare Pages preview per PR; production build reproducible; rollback = redeploy previous. |\n| **Maintainability** | Adding a markdown page requires **zero site code** (auto-discovered); CI catches drift; docs for the build in `site/README`. |\n\n---\n\n## 10. Risks and Recommendations\n\n| Type | Risk | Mitigation |\n|------|------|------------|\n| **Architectural** | Site logic drifts from content conventions (frontmatter/regions), breaking auto-generation | Schema mirrors frontmatter with all-optional fields; CI validates frontmatter; document the contract in `site/README` |\n| **Architectural** | Coupling the site to exact folder paths (loaders) breaks if content moves | Centralise paths in `content.config.ts`; a moved folder is a deliberate, reviewed change |\n| **Implementation** | Markdown `.md` links don't resolve as routes | Build-time link-rewrite with a tested edge-case suite (anchors, README indices, cross-section) |\n| **Implementation** | 60 Mermaid diagrams: perf / theme / `quadrantChart` | Client-side theme-aware render first; measure; selectively pre-render; verify `quadrantChart` in G3 |\n| **Implementation** | Starlight's layout constrains the target design | Prototype the homepage + a capability page in G1/G4; fall back to bespoke Astro only if a real constraint is hit |\n| **Content** | Missing `description` weakens SEO/cards | Derive from first paragraph as fallback; add `description` opportunistically (never bulk-rewrite) |\n| **Content** | Two glossaries confuse users | Present the authoritative one prominently; label `docs/glossary.md` as portal-maintenance scope (already noted in-content) |\n| **Maintainability** | Node deps / build add surface to a markdown repo | Isolate in `site/`; pin versions; `.gitignore` build artefacts; keep the site deletable without content impact |\n| **Governance** | The site could become a second source of truth | Enforce **markdown = source of truth**; the site never stores content; this is a [Documentation Governance](/governance/documentation-governance) invariant |\n\n### Top recommendations\n1. **Adopt Astro Starlight** as the base (fastest path to nav/search/theming/a11y); keep bespoke Astro as the fallback.\n2. **Keep all content in place**; load via Astro 5 glob loaders — the plan's cornerstone.\n3. **Client-side, theme-aware Mermaid first**; optimise later.\n4. **Isolate everything in `site/`**; the only pre-implementation edit ever needed is one additive `.gitignore` line (deferred to implementation).\n5. **Add CI validation** (links/frontmatter/Mermaid/a11y) to convert manual upkeep (R8) into automated guardrails.\n6. **Formalise the design tokens** into the placeholder `design/brand-tokens.md` as the first design act.\n\n---\n\n## Alignment with existing portal work (built upon, not duplicated)\nThis plan consumes — and does not replace — the [Repository Registry](/registry/repo-registry),\n[Capability Registry](/capabilities), [Portfolio Overview](/overview),\n[Architecture Principles](/architecture/principles),\n[Operating Model](/operating-model),\n[Governance](/governance), the [ADRs](/decisions),\n[Architecture Review](/architecture/architecture-review),\n[Capability Reuse Map](/architecture/capability-reuse-map),\n[System Dependency Maps](/architecture/system-of-systems), the\n[Information Architecture](/about/information-architecture), and all 60 Mermaid diagrams. The website renders this\nknowledge; the markdown remains authoritative.\n\n## Post-approval next steps (NOT done in Phase G)\nOn approval: record an **ADR** (e.g. \"Adopt Astro/Starlight website as the portal presentation layer\"), add the\n`site/` project (Roadmap G1), and wire a \"Website\" entry into navigation and the changelog. None of these were\nperformed in this planning phase.\n\n---\n\n*Phase G deliverable — planning only. One new file added (`docs/website-implementation-plan.md`); no existing\nfile modified, moved, renamed, or deleted; no code generated; no content rewritten.*\n"},{"id":"/about/website-strategy-validation","kind":"page","entityType":"meta","title":"Website Strategy Validation (Phase G.5 — planning only)","route":"/about/website-strategy-validation","sourcePath":"docs/website-strategy-validation.md","slug":null,"frontmatter":{"title":"Website Strategy Validation (Phase G.5 — planning only)","type":"explanation","status":"draft","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"A final architectural review of the website strategy before implementation, evaluated against the portal's","headings":[{"depth":2,"text":"Part 1 — Technology recommendation (re-evaluated)","id":"part-1-technology-recommendation-re-evaluated"},{"depth":3,"text":"Evaluation against the real objectives","id":"evaluation-against-the-real-objectives"},{"depth":3,"text":"The maintainability counter-argument, mitigated","id":"the-maintainability-counter-argument-mitigated"},{"depth":3,"text":"Other alternatives (screened)","id":"other-alternatives-screened"},{"depth":3,"text":"Final recommendation — 🔧 REFINED: Custom Astro (reversing the Starlight default)","id":"final-recommendation-refined-custom-astro-reversing-the-starlight-default"},{"depth":2,"text":"Part 2 — User Journeys","id":"part-2-user-journeys"},{"depth":3,"text":"Primary audiences & journeys","id":"primary-audiences-journeys"},{"depth":3,"text":"What the journeys imply (validation)","id":"what-the-journeys-imply-validation"},{"depth":2,"text":"Part 3 — Interactive Architecture Explorer","id":"part-3-interactive-architecture-explorer"},{"depth":3,"text":"The relationship model (derived from existing metadata — no new content)","id":"the-relationship-model-derived-from-existing-metadata-no-new-content"},{"depth":3,"text":"How it should work (two complementary mechanisms)","id":"how-it-should-work-two-complementary-mechanisms"},{"depth":3,"text":"Visualisation recommendations (avoid over-engineering)","id":"visualisation-recommendations-avoid-over-engineering"},{"depth":2,"text":"Part 4 — Information Architecture review","id":"part-4-information-architecture-review"},{"depth":3,"text":"Findings","id":"findings"},{"depth":3,"text":"Recommended top-level nav (🔧 REFINED — materially simpler, purpose-first)","id":"recommended-top-level-nav-refined-materially-simpler-purpose-first"},{"depth":2,"text":"Part 5 — Homepage review","id":"part-5-homepage-review"},{"depth":3,"text":"Refined homepage (🔧 REFINED)","id":"refined-homepage-refined"},{"depth":2,"text":"Part 6 — Visual exploration (diagrams as primary navigation)","id":"part-6-visual-exploration-diagrams-as-primary-navigation"},{"depth":3,"text":"Recommendations","id":"recommendations"},{"depth":2,"text":"Part 7 — Metadata recommendations","id":"part-7-metadata-recommendations"},{"depth":2,"text":"Part 8 — Portfolio Intelligence readiness","id":"part-8-portfolio-intelligence-readiness"},{"depth":3,"text":"The one thing to design now: a build-time Content Graph","id":"the-one-thing-to-design-now-a-build-time-content-graph"},{"depth":3,"text":"Readiness per future capability","id":"readiness-per-future-capability"},{"depth":3,"text":"Design-now checklist (no implementation)","id":"design-now-checklist-no-implementation"},{"depth":2,"text":"Summary of decisions","id":"summary-of-decisions"},{"depth":3,"text":"✅ Approved (Phase-G plan stands)","id":"approved-phase-g-plan-stands"},{"depth":3,"text":"🔧 Refined (change, with reason)","id":"refined-change-with-reason"},{"depth":3,"text":"🟢 Optional-future (design-ready, build later)","id":"optional-future-design-ready-build-later"},{"depth":3,"text":"Roadmap impact (refines Phase G's G1–G6, does not replace it)","id":"roadmap-impact-refines-phase-g-s-g1-g6-does-not-replace-it"}],"diagrams":2,"links":["website-implementation-plan.md","information-architecture.md","../portal/decisions/0005-platform-services-and-consolidation.md","../skills/portfolio-portal-orchestrator/SPEC.md","../skills/portfolio-portal-orchestrator/SPEC.md"],"body":"\n# Website Strategy Validation (Phase G.5)\n\nA final architectural review of the website strategy **before implementation**, evaluated against the portal's\n*actual* purpose — an **architecture exploration tool, EA knowledge base, operating manual, portfolio showcase,\nand daily architecture-working environment** — not a conventional documentation site. This is **planning only**:\nno code, no Astro project, no file moves, no modification of existing documentation. It is one new additive file\nthat **refines the [Website Implementation Plan](/about/website-implementation-plan) by reference** — the plan is not\nedited; this document states what is approved, refined, or newly recommended.\n\nEvery recommendation is tagged:\n**✅ APPROVED** (keep as planned) · **🔧 REFINED** (change, with reason) · **🟢 OPTIONAL-FUTURE** (design-ready, build later).\n\n> **Headline outcome:** the clarified objective changes one major decision — the technology base — and adds a\n> **build-time content graph** as the architectural backbone for exploration and future Portfolio Intelligence.\n> Most of the Phase-G plan stands. Nothing is changed for the sake of change.\n\n---\n\n## Part 1 — Technology recommendation (re-evaluated)\n\nPhase G recommended **Astro Starlight**, optimising for a *documentation site*. The objective is now explicitly\na *platform*: exploration, interactive visualisation, premium presentation, dashboards, and future intelligence.\nThat reframing changes the recommendation.\n\n### Evaluation against the real objectives\n\n| Objective | Astro + Starlight | Custom Astro | Weight |\n|-----------|-------------------|--------------|--------|\n| Long-term flexibility | 🔶 Opinionated docs layout; fights non-doc surfaces | ✅ Total layout freedom | High |\n| Architectural exploration (graph, focus mode) | 🔶 Possible only as bolt-on custom routes | ✅ First-class | High |\n| Interactive visualisation / dashboards | 🔶 Not its model | ✅ Islands anywhere | High |\n| Premium, distinctive presentation | 🔶 Recognisably \"Starlight\"; heavy theming to escape | ✅ Own identity | High |\n| Daily working environment (dense, custom views) | 🔶 Doc-reading model | ✅ Build the views you need | High |\n| Markdown integration | ✅ Native | ✅ Native (content collections) | High |\n| Mermaid support | ✅ | ✅ (identical integration) | Med |\n| Search | ✅ Pagefind built-in | ✅ Pagefind (one integration) | Med |\n| Cloudflare deployment | ✅ | ✅ (identical) | Med |\n| Future AI-generated content | 🔶 Constrained to doc pages | ✅ Any route/endpoint | High |\n| Future interactive dashboards | ❌ Out of model | ✅ Native islands + JSON endpoints | High |\n| Future Portfolio Intelligence | 🔶 Bolt-on | ✅ Designed-in via content graph | High |\n| Maintainability | ✅ Chrome is free | 🔶 Rebuild chrome (mitigated below) | Med |\n| Time-to-first-deploy | ✅ Fastest | 🔶 Slower start | Low (one-time) |\n\nStarlight wins **maintainability** and **time-to-first-deploy** (both one-time/near-term). Custom Astro wins on\n**almost every dimension tied to the portal's long-term purpose**.\n\n### The maintainability counter-argument, mitigated\nStarlight's real value is the free doc chrome. In custom Astro it is recoverable with modest, well-supported effort:\n\n| Starlight freebie | Custom-Astro equivalent | Effort |\n|-------------------|-------------------------|--------|\n| Sidebar nav | Generate from content collections + folder + optional `sidebar` frontmatter | Low |\n| Search | `pagefind` integration | Low |\n| TOC | `rehype-autolink-headings` + a small component | Low |\n| Dark/light + persistence | ~40 lines + CSS tokens | Low |\n| Prev/next, breadcrumbs | Derive from the nav tree | Low |\n| Accessibility baseline | Semantic layout + axe in CI (needed either way) | Med |\n| MDX, sitemap, RSS | `@astrojs/mdx`, `@astrojs/sitemap` | Low |\n\nNet: custom Astro recovers ~80% of Starlight's chrome in a few days — a **one-time** cost — in exchange for the\nfreedom the platform objectives require **permanently**.\n\n### Other alternatives (screened)\n- **Next.js / React SPA:** heavier, SSR/client-oriented; overkill for a mostly-static knowledge base; worse\n markdown ergonomics than Astro. ❌\n- **VitePress / Docusaurus:** more doc-locked than Starlight; framework-coupled (Vue/React); less island\n flexibility. ❌\n- **Notion/Obsidian-publish/GitBook (hosted):** would make a hosted tool the source of truth, violating\n \"markdown = source of truth\" and Cloudflare-static goals. ❌\n\n### Final recommendation — 🔧 REFINED: **Custom Astro** (reversing the Starlight default)\nBuild on **custom Astro** (content collections + Pagefind + MDX + Mermaid + React islands + Cloudflare Pages).\nAstro remains correct — it is the *Starlight base* recommendation that changes. Reasoning: the portal's centre of\ngravity is **exploration, showcase, and a working environment**, not long-form reading; Starlight optimises the\nsubset (doc pages) and constrains the differentiators (explorer, platform homepage, dashboards, premium identity,\nintelligence UI). Astro keeps all of Starlight's underlying primitives while removing its layout ceiling.\n\n**Adopt from the Starlight approach anyway:** Pagefind search, content-collection modelling, and Starlight's\n*open-source components as reference patterns* for the doc-chrome we rebuild. If time-to-first-deploy ever\nbecomes paramount, a Starlight MVP is a valid stepping stone — but since intent is known, building custom now\navoids a later rewrite.\n\n> Everything else in the Phase-G plan (glob loaders, files-stay-in-place, Pagefind, client-side theme-aware\n> Mermaid, Cloudflare Pages, `site/` isolation, additive migration) remains **✅ APPROVED** and is *more* natural\n> under custom Astro than under Starlight.\n\n---\n\n## Part 2 — User Journeys\n\nDesign for audiences and their journeys, then validate nav/homepage against them.\n\n### Primary audiences & journeys\n\n| Audience | Why they arrived | Key questions | Ideal path | Prioritise | Actions |\n|----------|------------------|---------------|-----------|------------|---------|\n| **You (founder/architect)** — *daily working env* | Make/record an architecture decision; check health | \"What depends on X? What's stale? Where does this belong?\" | Home → Explorer (focus a node) → related ADRs → Decision Matrix → new ADR | The graph, decision framework, current-state, risks | Trace dependencies; run the decision matrix; draft an ADR; spot stale pages |\n| **Solution architects** | Evaluate the system design | \"How is this structured? Principles? Trade-offs?\" | Home → Overview → Architecture (layered) → dependency map → principles → ADRs | Layered model, dependency map, principles, review | Explore layers; read ADR rationale; follow reuse map |\n| **Software engineers** | Understand a repo/how to contribute | \"What is this repo? Its deps, stack, interfaces?\" | Search/Repos → repo page → related capabilities → source | Repo digest, tech badges, interfaces, dependencies | Jump to source; see consumers; read CLAUDE.md rules |\n| **AI engineers** | Understand the AI platform & collaboration model | \"How do skills/agents/intelligence fit? What's autonomous?\" | Overview → Intelligence Platform → AI Collaboration → capabilities | Runtime flows, skills, agent governance, Hermes/OpenClaw | Trace information flow; see AI authority boundaries |\n| **New collaborators** | Onboard fast | \"Where do I start? How does it all fit?\" | Home → Overview → Operating Model → Governance → a repo | Overview, operating model, glossary, governance | Read start-here; use glossary; find the contribution rules |\n| **Employers / recruiters** | Assess capability & sophistication | \"Is this person a serious architect? Evidence?\" | Home (scale + explorer) → Architecture Review → ADRs → a deep capability | Scale metrics, EA review, decision quality | Skim breadth; drill one deep example; see rigor |\n| **Clients** | Assess the offering (e.g. Website Assessment) | \"What can this do for me? Is it credible?\" | Home → Capabilities → Website Assessment → outcomes | Capability value, maturity, ventures served | Understand the product; see it's real (evidence) |\n| **Investors** | Assess scale, moat, commercialisation | \"How big/defensible? What's the platform thesis?\" | Home (vision + scale) → Overview → Strategic Opportunities → Evolution | Vision, layers, reuse leverage, commercialisation | Grasp the thesis; see the roadmap; gauge maturity honestly |\n| **Future contributors / AI agents** | Extend the ecosystem correctly | \"Where does a new thing belong? What are the rules?\" | Governance → Decision Matrix → templates → AI Governance | Decision framework, templates, governance, `llms.txt` | Place a new capability; follow templates; respect approvals |\n\n### What the journeys imply (validation)\n1. **Two dominant modes:** *explore relationships* (you, architects, AI engineers) and *assess quickly then\n drill* (employers, investors, clients). The homepage and nav must serve **both** — an explorer for the first,\n scale + curated deep-links for the second.\n2. **Search is a primary entry** for engineers — must be excellent and faceted.\n3. **Audience-aware entry** on the homepage (\"I'm an architect / engineer / investor …\") materially shortens\n paths — 🔧 **REFINED** into the homepage (Part 5).\n4. **Honesty is a feature** for investors/employers — the maturity/▢-labelling already in content is a\n credibility asset; surface it, don't hide it.\n\n---\n\n## Part 3 — Interactive Architecture Explorer\n\nThe portal should let users **move through relationships**, not just read linked pages.\n\n### The relationship model (derived from existing metadata — no new content)\nThe chain the brief describes already exists implicitly in frontmatter + links:\n\n```\nCapability ─ owns/consumed-by ─ Repositories ─ uses ─ Technologies\n │ │\n ├─ serves ─ Ventures ├─ decided-by ─ ADRs\n ├─ governed-by ─ Principles └─ documented-in ─ Diagrams\n └─ realised-in ─ Operating Model / Knowledge Assets\n```\n\nEdges come from: `providers`/`consumers`/`layer`/`system` frontmatter, the markdown link graph, and diagram\nnode IDs (**which were deliberately kept equal to slugs** — a key enabler).\n\n### How it should work (two complementary mechanisms)\n\n**A. Per-entity \"relationship rails\" (🔧 REFINED, primary).** Every page gains a structured side/end panel of\n*typed* related entities (Capabilities ▸ Repos ▸ Technologies ▸ Consumers ▸ Ventures ▸ Principles ▸ ADRs ▸\nDiagrams). Intuitive, low-risk, works without heavy graph UI, and is generated from the content graph (Part 8).\n\n**B. A global interactive graph — the \"Explorer\" (🟢 OPTIONAL-FUTURE, high value).** A dedicated `/explore`\nroute with a node-link graph:\n- **Focus mode:** click a node → recenter on it → show its immediate neighbourhood (avoids hairball).\n- **Filter by layer / maturity / type.**\n- Nodes link to their pages; edges are typed and labelled.\n- Fed by the same build-time JSON graph; rendered by a lightweight island.\n\n```mermaid\ngraph LR\n HOME[Home] --> EXP[\"/explore — global graph\"]\n EXP -->|focus node| NODE[Entity neighbourhood]\n NODE --> PAGE[Entity page]\n PAGE --> RAILS[Relationship rails]\n RAILS --> PAGE2[Another entity]\n ANY[Any page] --> RAILS\n```\n\n### Visualisation recommendations (avoid over-engineering)\n- **Do:** reuse existing Mermaid diagrams as *interactive* navigation (Part 6); build relationship rails from\n the content graph; add one focused `/explore` graph with focus+filter.\n- **Don't:** introduce a graph database, a 3D graph, or a bespoke query language. Derive edges at build time;\n keep the client light. Intuitive beats impressive.\n\n---\n\n## Part 4 — Information Architecture review\n\nChallenging the current nav (`Overview · Capabilities · Repos · Ventures · Architecture · Operating Model ·\nGovernance · Decisions` + About).\n\n### Findings\n| Issue | Assessment | Recommendation |\n|-------|-----------|----------------|\n| **Header has 8 top items** | Borderline (guideline ≤ 7); some are thin | 🔧 Group into fewer buckets (below) |\n| **`Ventures/Systems` is thin** (mostly placeholders) | Real but under-populated | 🔧 Keep the data; in nav, fold under **Explore/Architecture** until layer-5 is populated |\n| **`Architecture` is overloaded** (9 pages: system-of-systems, intelligence-platform, principles, reuse-map, review, risks, opportunities, evolution, recommendations) | Hard to scan | 🔧 Split visually into **Architecture** (structure) and **Review** (review/risks/opportunities/evolution) |\n| **Duplicated surfaces** | Capabilities appear in registry *and* reuse-map; glossary in two files | ✅ Acceptable (different purpose) — label clearly; authoritative glossary primary |\n| **Terminology: \"Repos\" vs \"Repositories\", \"Ventures\" vs \"Systems\"** | Minor inconsistency | 🔧 Standardise labels: **Repositories**, and **Ventures & Systems** |\n| **No \"Explore\" entry** | The portal's headline purpose isn't in the nav | 🔧 Add **Explore** as a primary entry |\n| **No audience entry** | Journeys show it helps | 🔧 Homepage audience chips (Part 5), not a nav item |\n\n### Recommended top-level nav (🔧 REFINED — materially simpler, purpose-first)\n`Explore · Overview · Capabilities · Repositories · Architecture · Operating & Governance · Decisions`\n- **Explore** → the graph + relationship-first entry (new front door for the platform purpose).\n- **Operating & Governance** merges the two meta-sections under one bucket (each keeps its landing page and\n sub-nav) — reduces header load without losing content.\n- **Ventures & Systems** moves under Architecture/Explore until populated (data unchanged).\n\n> This is a **navigation** refinement only — no content moves or renames; it changes how the *site* groups\n> existing pages. The [Information Architecture](/about/information-architecture) doc's routes are preserved.\n\n---\n\n## Part 5 — Homepage review\n\nThe Phase-G homepage (hero + layered diagram + registry links + status + start-here) is solid but reads a bit\n**documentation-like**. Against the \"entering a sophisticated AI platform\" bar:\n\n| Should communicate | Phase-G homepage | Refinement |\n|--------------------|------------------|------------|\n| What the platform is | ✅ Vision one-liner | Keep, tighten to one confident sentence |\n| Why it exists | ✅ | Keep |\n| **Scale of the ecosystem** | 🔶 Implicit | 🔧 Add a **live scale strip**: 169 skills · N capabilities · N repos · N ADRs · 60 diagrams · N principles (computed from the content graph) |\n| **How layers fit** | ✅ Layered diagram | 🔧 Make it the **interactive hero** — clickable layers → sections |\n| Why continue | 🔶 Start-here cards | 🔧 Add **audience chips** (\"Architect · Engineer · Investor · Client\") → tailored paths (Part 2) |\n\n### Refined homepage (🔧 REFINED)\n1. **Hero = the interactive layered architecture** (clickable, theme-aware), with the vision sentence.\n2. **Scale strip** (computed metrics) — instant \"this is substantial\".\n3. **Audience chips** — route by intent.\n4. **The two registries** (Capabilities, Repositories) as prominent cards.\n5. **Current phase / health** (from current-state) — signals it's alive and maintained.\n6. **Entry to `/explore`** — the platform's defining action.\n\nThe test: within 10 seconds a visitor should grasp *what it is, how big it is, how it fits*, and feel invited to\n**explore** — not to read a manual. Motion/depth should be restrained and purposeful (premium, not flashy).\n\n---\n\n## Part 6 — Visual exploration (diagrams as primary navigation)\n\nToday diagrams **illustrate** content. They should **drive** navigation. The decisive enabler already exists:\n**Mermaid node IDs were kept equal to entity slugs** across the portal, so nodes can map to routes mechanically.\n\n### Recommendations\n| Diagram | Make it… | Mechanism |\n|---------|----------|-----------|\n| **Layered architecture** | Clickable layers → section/registry filtered by layer | Node→route map; hero on homepage |\n| **System dependency map** | Interactive: click a node → its page + neighbourhood in `/explore` | Node ID = slug → route |\n| **Capability relationship graph** | Explorable graph (focus/filter) | Content-graph island |\n| **Venture composition** | Click a venture → its repos/capabilities | Node→route |\n| **Runtime information flows** | Click a stage → the owning system/capability | Node→route |\n\n**Implementation note (design-level):** add a build/render step that turns Mermaid nodes into links where a node\nID matches a known slug (Mermaid supports `click` bindings / post-render link injection). Diagrams that are just\nnarrative stay static. This is **low effort, high payoff** precisely because of the earlier slug-discipline.\n\n🔧 **REFINED:** treat \"interactive diagrams\" as a first-class site feature, not a nice-to-have; 🟢\n**OPTIONAL-FUTURE:** the full `/explore` graph.\n\n---\n\n## Part 7 — Metadata recommendations\n\nCurrent frontmatter (`title · type · status · last_reviewed · owner` + type-specific `slug · layer · providers ·\nconsumers · maturity · lifecycle · adr_number`) is strong. Recommended **additive** fields — only those with\nclear long-term value for automation & intelligence (Part 8). **All optional; no existing content rewritten.**\n\n| Field | Value | Why (long-term) | Priority |\n|-------|-------|-----------------|----------|\n| `id` | stable unique id (≈ slug) | Durable graph edges even if titles change | 🔧 High |\n| `related` | explicit list of ids | Typed relationship rails without inferring | 🔧 High |\n| `implementation_status` | implemented / partial / planned / vision | Structured (today it's prose) → drives health & filters | 🔧 High |\n| `confidence` | high / medium / low | Flags uncertain claims for review & intelligence | 🔧 Med |\n| `review_frequency` | e.g. 30d / 90d / 180d | With `last_reviewed` → **stale-doc detection** | 🔧 Med |\n| `source_repos` | repo slugs | Repo↔doc drift detection | 🔧 Med (repos have `repo_url`; generalise) |\n| `venture_relevance` | venture slugs | Venture-scoped views/filters | 🟢 Optional |\n| `description` | one line | SEO + card subtitle (from Phase G) | ✅ Approved |\n| `sidebar` | order/group | Deterministic nav (from Phase G) | ✅ Approved |\n\n**Guidance:** introduce these **lazily** (page-by-page, highest-value pages first), keep schema all-optional, and\nlet the site derive fallbacks. Encode them in the templates so *new* pages get them for free. `last_reviewed` +\n`review_frequency` + `implementation_status` + `confidence` are the four that unlock Portfolio Intelligence.\n\n---\n\n## Part 8 — Portfolio Intelligence readiness\n\nEnsure the website architecture is ready for future intelligence — **design now, build later** — to avoid\nexpensive refactoring.\n\n### The one thing to design now: a build-time **Content Graph**\nA JSON model of the whole portal, produced at build from frontmatter + links + diagram nodes:\n\n```mermaid\ngraph LR\n MD[Markdown + frontmatter] --> BUILD[Build step]\n LINKS[Link graph] --> BUILD\n DIAG[Mermaid node IDs] --> BUILD\n BUILD --> GRAPH[(content-graph.json<br/>entities + typed edges + metadata)]\n GRAPH --> SITE[Site: rails · explorer · scale strip]\n GRAPH --> ENDPOINT[Static JSON endpoints]\n ENDPOINT --> FUTURE[Future: dashboards · drift · health · AI · Hermes]\n```\n\nThe content graph is the **single backbone** the site *and* every future intelligence feature consume. Design it\nnow; it costs little and prevents a later rewrite.\n\n### Readiness per future capability\n| Future capability | What must exist now | Status if we do Part 7 + graph |\n|-------------------|---------------------|-------------------------------|\n| **Architecture drift detection** | Stable ids + `source_repos` + link graph | ✅ Ready |\n| **Stale documentation detection** | `last_reviewed` + `review_frequency` | ✅ Ready |\n| **Capability health** | `implementation_status` + `maturity` + `confidence` + edges | ✅ Ready |\n| **Repository health** | repo metadata + `source_repos` + registry rows | ✅ Ready |\n| **Recommendation engine (portfolio)** | The content graph + metadata | ✅ Ready |\n| **Hermes learning** | One-way, versioned outputs; graph as input | ✅ Ready (aligns with [ADR 0005](/decisions/0005-platform-services-and-consolidation) one-way feedback) |\n| **Autonomous portfolio analysis** | JSON endpoints + `GENERATED`/`HUMAN` regions (already present) + `llms.txt` | ✅ Ready |\n\n### Design-now checklist (no implementation)\n- [ ] **Content graph** as a build artefact + static JSON endpoints (Astro supports both).\n- [ ] **Additive metadata** (Part 7): `id`, `implementation_status`, `confidence`, `review_frequency`, `related`, `source_repos`.\n- [ ] Preserve `<!-- GENERATED -->`/`<!-- HUMAN -->` regions so the [orchestrator](/skills/portfolio-portal-orchestrator/SPEC) can write safely.\n- [ ] Keep **node ID = slug** discipline (already in place) so diagrams join the graph.\n- [ ] A per-entity **health schema** computable from metadata (staleness, gaps, drift) — *design the schema, don't build the checks*.\n- [ ] The site consumes the graph via components so intelligence features reuse the same data path.\n\nThis directly serves — and does not pre-empt — the existing\n[`portfolio-portal-orchestrator` spec](/skills/portfolio-portal-orchestrator/SPEC) and the operating model's\nfuture-autonomy vision.\n\n---\n\n## Summary of decisions\n\n### ✅ Approved (Phase-G plan stands)\nFiles stay in place (glob loaders) · Pagefind static search · client-side theme-aware Mermaid · Cloudflare\nPages · `site/` isolation · additive migration · content strategy · validation strategy · roadmap shape ·\n`description`/`sidebar` frontmatter.\n\n### 🔧 Refined (change, with reason)\n1. **Custom Astro** instead of Starlight (objectives = platform, not docs).\n2. **\"Explore\" as a primary nav entry**; simpler top-nav buckets; standardise labels; fold thin sections.\n3. **Homepage** = interactive layered hero + scale strip + audience chips + explore CTA (platform feel).\n4. **Diagrams as primary navigation** (clickable nodes → routes, via the slug discipline).\n5. **Relationship rails** on every entity page.\n6. **Additive intelligence metadata** (`id`, `implementation_status`, `confidence`, `review_frequency`, `related`, `source_repos`).\n\n### 🟢 Optional-future (design-ready, build later)\nGlobal `/explore` graph with focus+filter · content-graph JSON endpoints · dashboards · drift/health/stale\ndetection · venture-scoped views · generated OG images.\n\n### Roadmap impact (refines Phase G's G1–G6, does not replace it)\n- **G1** now stands up **custom Astro** (not Starlight) + rebuild minimal chrome; **add the content-graph build artefact early** (it underpins G2/G3/G5).\n- **G3** interactive Mermaid (node→route) is promoted from nice-to-have to core.\n- **G5** registries + **relationship rails** + optional `/explore`.\n- Metadata (Part 7) is applied **lazily** across all phases via templates.\n\n> Phase G.5 deliverable — validation & refinement only. One new file added\n> (`docs/website-strategy-validation.md`); no code, no Astro project, no file moves/renames, no existing\n> documentation modified.\n"},{"id":"/ai/AI-HANDOFF","kind":"page","entityType":"doc","title":"AI Handoff — Index","route":"/ai/AI-HANDOFF","sourcePath":"ai/AI-HANDOFF.md","slug":null,"frontmatter":{"title":"AI Handoff — Index","type":"how-to","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Shared context for any AI assistant working on this portal. Model-specific entry points:","headings":[{"depth":2,"text":"The one-minute briefing (read this first)","id":"the-one-minute-briefing-read-this-first"},{"depth":2,"text":"Hard constraints for any AI","id":"hard-constraints-for-any-ai"},{"depth":2,"text":"Where to start for common tasks","id":"where-to-start-for-common-tasks"},{"depth":2,"text":"Definition of done","id":"definition-of-done"}],"diagrams":0,"links":["claude.handoff.md","../CLAUDE.md","chatgpt.handoff.md","../portal/registry/repo-registry.md","../CLAUDE.md","../docs/update-conventions.md","../portal/current-state/changelog.md","../portal/current-state/status-dashboard.md","../docs/update-conventions.md#recipe-add-a-repo","../docs/update-conventions.md#recipe-add-a-venture--system","../portal/architecture/system-of-systems.md","../portal/decisions/README.md","../docs/information-architecture.md","../CLAUDE.md"],"body":"\n# AI Handoff — Index\n\nShared context for any AI assistant working on this portal. Model-specific entry points:\n\n- **Claude / Claude Code:** [`claude.handoff.md`](/ai/claude.handoff) (also read root [`CLAUDE.md`](/CLAUDE))\n- **ChatGPT / other assistants:** [`chatgpt.handoff.md`](/ai/chatgpt.handoff)\n\n## The one-minute briefing (read this first)\n\n- **What this repo is:** a markdown-first *system-of-systems* portal for Azwaan's AI venture\n ecosystem. Documentation and structure, not application code.\n- **Three layers, never blur them:** repo-level docs (in each repo) → portfolio portal (this repo)\n → public showcase (future).\n- **Source of truth:** [`portal/registry/repo-registry.md`](/registry/repo-registry)\n for repos; [`portal/ventures/`](../portal/ventures/) for ventures.\n- **Rules of the road:** [`CLAUDE.md`](/CLAUDE) and\n [`docs/update-conventions.md`](/about/update-conventions). These are binding.\n\n## Hard constraints for any AI\n\n1. **Templates only.** Never invent a page shape — copy from [`templates/`](../templates/).\n2. **No fabrication.** Unknown facts are `Unknown`/`TBD`, never guesses. This is a factual map.\n3. **Stay in your layer.** Don't build the public website (Phase C) or implement the orchestrator\n (spec only) unless explicitly asked.\n4. **Keep it consistent.** Registry ⇄ digests ⇄ diagrams must always agree; no orphans, no dead links.\n5. **Respect regions.** Preserve `<!-- HUMAN -->` blocks; only `<!-- GENERATED -->` blocks are\n automation-owned.\n6. **Record decisions.** Structural choices become ADRs in [`portal/decisions/`](../portal/decisions/).\n7. **Update current-state.** Any change updates the\n [changelog](/current-state/changelog) and, if counts change, the\n [status dashboard](/current-state/status-dashboard).\n\n## Where to start for common tasks\n\n| Task | Start here |\n|------|------------|\n| Add / update a repo | [update conventions → add a repo](/about/update-conventions#recipe-add-a-repo) |\n| Add / update a venture | [update conventions → add a venture](/about/update-conventions#recipe-add-a-venture--system) |\n| Update a diagram | [architecture](/architecture/system-of-systems) |\n| Record a decision | [decisions](/decisions) |\n| Understand the structure | [information architecture](/about/information-architecture) |\n\n## Definition of done\nThe checklist at the end of [`CLAUDE.md`](/CLAUDE) applies to every change.\n"},{"id":"/ai/chatgpt.handoff","kind":"page","entityType":"doc","title":"ChatGPT Handoff","route":"/ai/chatgpt.handoff","sourcePath":"ai/chatgpt.handoff.md","slug":null,"frontmatter":{"title":"ChatGPT Handoff","type":"how-to","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Entry point for ChatGPT (or any non-Claude assistant) working with this repo, whether editing","headings":[{"depth":2,"text":"If you only have a chat window (no file access)","id":"if-you-only-have-a-chat-window-no-file-access"},{"depth":2,"text":"Ground rules (same for every AI)","id":"ground-rules-same-for-every-ai"},{"depth":2,"text":"Output format expectations","id":"output-format-expectations"},{"depth":2,"text":"Boundaries","id":"boundaries"}],"diagrams":0,"links":["AI-HANDOFF.md","../CLAUDE.md","../docs/update-conventions.md"],"body":"\n# ChatGPT Handoff\n\nEntry point for **ChatGPT** (or any non-Claude assistant) working with this repo, whether editing\nfiles directly or being pasted context in a chat window. Read this plus the shared\n[`AI-HANDOFF.md`](/ai/AI-HANDOFF).\n\n## If you only have a chat window (no file access)\nWhen a user pastes portal content and asks for help, produce output that **drops cleanly into the\ntemplates** so a human can commit it without reshaping:\n\n1. Ask which template applies (repo digest, venture digest, ADR, diagram, current-state) — or infer\n from the request — and follow that template's structure and frontmatter exactly. Templates are in\n [`templates/`](../templates/).\n2. Keep the YAML frontmatter block intact (`title`, `type`, `status`, `last_reviewed`, `owner`, and\n any type-specific fields).\n3. Return Mermaid diagrams inside fenced ` ```mermaid ` blocks so they render on GitHub.\n4. Use `Unknown` / `TBD` for anything you cannot verify — **do not invent** stacks, dependencies,\n URLs, or statuses.\n\n## Ground rules (same for every AI)\n- **Three layers, never blur them:** repo-level docs → this portal (system of systems) → public\n showcase (future).\n- **Factual map, not marketing** — except the future showcase layer.\n- **Templates are canonical**; no freehand page shapes.\n- **Preserve `<!-- HUMAN -->` regions**; treat `<!-- GENERATED -->` regions as automation-owned.\n- **Consistency:** every repo digest needs a registry row; every venture and its repos link both\n ways; every diagram node maps to a digest.\n\n## Output format expectations\n- Markdown only, GitHub-flavored.\n- One page per response unless asked otherwise.\n- End with a short \"what a human should update next\" list (e.g., \"add the registry row\", \"bump the\n changelog\") so nothing is silently left inconsistent.\n\n## Boundaries\n- Do not produce public website code (Phase C) or implement the orchestrator (spec only) unless\n explicitly asked.\n- Defer visual/branding decisions to Phase C and the `design-system` skill.\n\nSee [`CLAUDE.md`](/CLAUDE) and [`docs/update-conventions.md`](/about/update-conventions) for\nthe full rules.\n"},{"id":"/ai/claude.handoff","kind":"page","entityType":"doc","title":"Claude Handoff","route":"/ai/claude.handoff","sourcePath":"ai/claude.handoff.md","slug":null,"frontmatter":{"title":"Claude Handoff","type":"how-to","status":"living","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Entry point for Claude / Claude Code working in this repo. Read this plus the root","headings":[{"depth":2,"text":"Operating context","id":"operating-context"},{"depth":2,"text":"How Claude should work here","id":"how-claude-should-work-here"},{"depth":2,"text":"Boundaries","id":"boundaries"},{"depth":2,"text":"Handing off to another agent","id":"handing-off-to-another-agent"}],"diagrams":0,"links":["../CLAUDE.md","AI-HANDOFF.md","../CLAUDE.md","../CLAUDE.md","../skills/portfolio-portal-orchestrator/SPEC.md"],"body":"\n# Claude Handoff\n\nEntry point for **Claude / Claude Code** working in this repo. Read this plus the root\n[`CLAUDE.md`](/CLAUDE) (the authoritative maintenance contract) and the shared\n[`AI-HANDOFF.md`](/ai/AI-HANDOFF).\n\n## Operating context\n- The primary maintenance rules live in [`CLAUDE.md`](/CLAUDE) — treat it as binding.\n- This repo is markdown-first; there is no build/test step in Phase A. \"Verification\" means\n internal consistency, not running code.\n- The `.claude/skills` library is available. Relevant skills for this portal:\n `site-architecture`, `documentation-writer`, `senior-architect`, `design-system`,\n `ui-design-system`, `landing-page-generator` (Phase C), `knowledge-ops` (hygiene),\n `create-llms` / `update-llms` (index), `dependency-auditor` (dependency facts).\n\n## How Claude should work here\n1. **Plan against the templates.** Every new page maps to a file in [`templates/`](../templates/).\n2. **Make consistent edits atomically.** When you add a repo, edit the digest, the registry, the\n owning venture, any affected diagram, and the changelog in the same change — not piecemeal.\n3. **Use explicit placeholders** (`> **TODO:**`, `<!-- PLACEHOLDER -->`, `Unknown`) — never silent\n gaps or invented facts.\n4. **Preserve `<!-- HUMAN -->` regions**; only touch `<!-- GENERATED -->` regions when acting as (or\n standing in for) the orchestrator.\n5. **Verify before finishing** against the Definition of Done in [`CLAUDE.md`](/CLAUDE):\n consistency, live diagrams, updated current-state, ADR if a decision was made.\n\n## Boundaries\n- Do **not** build the public showcase (Phase C) unless explicitly asked.\n- Do **not** implement the `portfolio-portal-orchestrator` — it is a spec only\n ([`skills/portfolio-portal-orchestrator/SPEC.md`](/skills/portfolio-portal-orchestrator/SPEC)).\n When maintaining pages by hand, mirror what that skill will produce so future automation is a\n drop-in.\n\n## Handing off to another agent\nLeave the repo internally consistent and note any open threads as `> **TODO:**` lines and/or a\nchangelog entry so ChatGPT or a future Claude session can pick up cleanly.\n"},{"id":"/design/brand-tokens","kind":"page","entityType":"doc","title":"Brand Tokens (placeholder)","route":"/design/brand-tokens","sourcePath":"design/brand-tokens.md","slug":null,"frontmatter":{"title":"Brand Tokens (placeholder)","type":"reference","status":"draft","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"values now. The table below is the intended shape only. --","headings":[],"diagrams":0,"links":[],"body":"\n# Brand Tokens — Placeholder\n\n<!-- PLACEHOLDER: To be generated in Phase C by the `design-system` skill. Do not hand-pick final\n values now. The table below is the intended shape only. -->\n\n| Token | Purpose | Value (TBD) |\n|-------|---------|-------------|\n| `--color-primary` | Primary brand color | TBD |\n| `--color-accent` | Accent / CTA | TBD |\n| `--color-fg` | Body text | TBD |\n| `--color-bg` | Background | TBD |\n| `--font-heading` | Heading typeface | TBD |\n| `--font-body` | Body typeface | TBD |\n| `--radius` | Corner radius scale | TBD |\n| `--space` | Spacing scale | TBD |\n\n> All colors must pass WCAG 2.2 AA (body text ≥ 4.5:1) once chosen.\n"},{"id":"/design/design-system","kind":"page","entityType":"doc","title":"Design System (placeholder)","route":"/design/design-system","sourcePath":"design/design-system.md","slug":null,"frontmatter":{"title":"Design System (placeholder)","type":"reference","status":"draft","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Phase A is markdown-first and renders on GitHub with no custom styling. Visual design only becomes","headings":[{"depth":2,"text":"What this will hold (Phase C)","id":"what-this-will-hold-phase-c"},{"depth":2,"text":"Why deferred","id":"why-deferred"}],"diagrams":0,"links":["brand-tokens.md"],"body":"\n# Design System — Placeholder\n\n> **Not active yet.** Reserved for Phase C visual consistency across the showcase (and any rendered\n> portal). Target skills: `design-system` (brand onboarding + WCAG-checked tokens) and\n> `ui-design-system` (design tokens, component docs, dev handoff).\n\n## What this will hold (Phase C)\n- Brand identity: primary/accent colors, heading & body fonts, design style.\n- Derived design tokens (see [`brand-tokens.md`](/design/brand-tokens)).\n- Component and layout conventions for the showcase.\n- WCAG 2.2 AA contrast validation results.\n\n## Why deferred\nPhase A is markdown-first and renders on GitHub with no custom styling. Visual design only becomes\nrelevant when the public showcase is built. Defining tokens now would be premature.\n\n> **TODO (Phase C):** Run the `design-system` onboarding wizard to capture brand identity and emit\n> tokens, then wire them into the showcase build.\n"},{"id":"/showcase","kind":"page","entityType":"doc","title":"Public Showcase (Phase C — placeholder)","route":"/showcase","sourcePath":"showcase/README.md","slug":null,"frontmatter":{"title":"Public Showcase (Phase C — placeholder)","type":"explanation","status":"draft","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"The showcase is the public-facing layer. Where the portal explains the system of systems for","headings":[{"depth":2,"text":"Role","id":"role"},{"depth":2,"text":"Inputs (curated from the portal, not authored fresh)","id":"inputs-curated-from-the-portal-not-authored-fresh"},{"depth":2,"text":"Planned build (Phase C)","id":"planned-build-phase-c"},{"depth":2,"text":"Do-not-do (for now)","id":"do-not-do-for-now"}],"diagrams":0,"links":["content/showcase-narrative.md","../portal/current-state/roadmap.md"],"body":"\n# Public Showcase — Placeholder\n\n> **Not built yet.** This directory reserves the third layer. Do **not** implement the public\n> website during Phase A. It is documented here only so its role and inputs are clear.\n\n## Role\n\nThe showcase is the **public-facing** layer. Where the portal explains the *system of systems* for\nmaintainers and agents, the showcase explains the **scale and sophistication** of Azwaan's AI\nventure ecosystem to an external audience (prospective partners, clients, hires, investors).\n\n## Inputs (curated from the portal, not authored fresh)\n\n- Venture digests → featured ventures\n- Repo registry counts → \"scale\" metrics\n- Architecture diagrams → sophistication visuals\n- Roadmap / current state → momentum narrative\n\n## Planned build (Phase C)\n\n- **Target skills:** `landing-page-generator` (page shell), `premium-frontend-ui` (polish),\n `design-system` / `ui-design-system` (brand tokens & consistency), `web-design-reviewer` (QA).\n- **Content source:** [`content/showcase-narrative.md`](/showcase/content/showcase-narrative).\n- The `portfolio-portal-orchestrator` skill will *prepare* showcase content from the portal; the\n build tooling is out of scope until Phase C.\n\n## Do-not-do (for now)\n- No framework scaffolding, no components, no deploy config.\n- No hand-written marketing copy beyond the narrative placeholder.\n\nSee the [roadmap](/current-state/roadmap) for phasing.\n"},{"id":"/showcase/content/showcase-narrative","kind":"page","entityType":"doc","title":"Showcase Narrative (placeholder)","route":"/showcase/content/showcase-narrative","sourcePath":"showcase/content/showcase-narrative.md","slug":null,"frontmatter":{"title":"Showcase Narrative (placeholder)","type":"explanation","status":"draft","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"outline for now — do not write final marketing copy yet. --","headings":[{"depth":2,"text":"Outline (to be filled in Phase C)","id":"outline-to-be-filled-in-phase-c"}],"diagrams":0,"links":[],"body":"\n# Showcase Narrative — Placeholder\n\n<!-- PLACEHOLDER: The public narrative will be curated from the portal in Phase C. Keep it as an\n outline for now — do not write final marketing copy yet. -->\n\n## Outline (to be filled in Phase C)\n\n1. **The thesis** — what Azwaan's AI venture ecosystem is and why it matters. *(TODO)*\n2. **Scale** — number of ventures, repos, capabilities; pulled from the registry. *(TODO)*\n3. **Sophistication** — architecture highlights and hard problems solved; from the diagrams. *(TODO)*\n4. **Featured ventures** — 2–4 flagship ventures with one-line outcomes. *(TODO)*\n5. **How it fits together** — a single simplified system-of-systems diagram. *(TODO)*\n6. **Call to action** — partner / hire / learn more. *(TODO)*\n\n> Source of truth is the portal. This file is only the staging ground for public copy.\n"},{"id":"/skills/portfolio-portal-orchestrator","kind":"page","entityType":"doc","title":"README","route":"/skills/portfolio-portal-orchestrator","sourcePath":"skills/portfolio-portal-orchestrator/README.md","slug":null,"frontmatter":{},"excerpt":"This folder reserves the future portfolio-portal-orchestrator skill that will automate maintenance","headings":[],"diagrams":0,"links":["SPEC.md","../../portal/current-state/roadmap.md"],"body":"# portfolio-portal-orchestrator (future skill)\n\n> **Placeholder — spec only. Not implemented.**\n\nThis folder reserves the future `portfolio-portal-orchestrator` skill that will automate maintenance\nof the Portfolio Architecture Portal (scan repos → digests → registry → venture maps → Mermaid\ndiagrams → dependency diffs → duplication flags → `llms.txt` → staged showcase content).\n\n- **Specification:** [`SPEC.md`](/skills/portfolio-portal-orchestrator/SPEC)\n- **Status:** Phase D on the [roadmap](/current-state/roadmap).\n- **Do not implement automation yet.** Until this skill exists, maintain the portal by hand using\n the templates and conventions the spec targets, so the eventual build is a drop-in.\n\n<!-- PLACEHOLDER: skill implementation (SKILL.md, scripts/) will live here in Phase D. -->\n"},{"id":"/skills/portfolio-portal-orchestrator/SPEC","kind":"page","entityType":"doc","title":"Specification — portfolio-portal-orchestrator (future skill)","route":"/skills/portfolio-portal-orchestrator/SPEC","sourcePath":"skills/portfolio-portal-orchestrator/SPEC.md","slug":null,"frontmatter":{"title":"Specification — portfolio-portal-orchestrator (future skill)","type":"reference","status":"draft","last_reviewed":"2026-07-05","owner":"Azwaan"},"excerpt":"Automate maintenance of the Portfolio Architecture Portal by scanning multiple source repositories","headings":[{"depth":2,"text":"1. Purpose","id":"1-purpose"},{"depth":2,"text":"2. Scope","id":"2-scope"},{"depth":3,"text":"In scope (eventual capabilities)","id":"in-scope-eventual-capabilities"},{"depth":3,"text":"Out of scope","id":"out-of-scope"},{"depth":2,"text":"3. Inputs","id":"3-inputs"},{"depth":2,"text":"4. Outputs","id":"4-outputs"},{"depth":2,"text":"5. Contracts & invariants (must hold after every run)","id":"5-contracts-invariants-must-hold-after-every-run"},{"depth":2,"text":"6. High-level flow","id":"6-high-level-flow"},{"depth":2,"text":"7. Capability duplication detection (approach sketch)","id":"7-capability-duplication-detection-approach-sketch"},{"depth":2,"text":"8. Dependency-change detection (approach sketch)","id":"8-dependency-change-detection-approach-sketch"},{"depth":2,"text":"9. Reuse of existing skills","id":"9-reuse-of-existing-skills"},{"depth":2,"text":"10. Non-goals / risks","id":"10-non-goals-risks"},{"depth":2,"text":"11. Acceptance criteria (for when it is built)","id":"11-acceptance-criteria-for-when-it-is-built"}],"diagrams":1,"links":["README.md","../../portal/current-state/roadmap.md"],"body":"\n# Specification: `portfolio-portal-orchestrator`\n\n> **Status: SPEC ONLY — not implemented.** This document specifies a future skill. No automation\n> exists yet. Until it does, the portal is maintained by hand using the same templates and\n> conventions this skill will target, so the eventual implementation is a drop-in.\n\n## 1. Purpose\n\nAutomate maintenance of the Portfolio Architecture Portal by scanning multiple source repositories\nand keeping the portal's *system-of-systems* layer accurate: repo digests, the unified registry,\nventure/system maps, architecture diagrams, dependency tracking, duplication detection, `llms.txt`,\nand staged content for the public showcase.\n\nIt operationalizes the three-layer principle: it reads **repo-level docs**, updates the **portfolio\nportal**, and prepares inputs for the **public showcase** — without blurring the layers.\n\n## 2. Scope\n\n### In scope (eventual capabilities)\n1. **Scan multiple repos** — take a list/globs of repo paths or URLs and enumerate them.\n2. **Read key sources per repo** — `CLAUDE.md`, `README`, `docs/**`, ADRs, manifest/lock files, and\n a bounded selection of source files (entry points, config, interface definitions).\n3. **Produce repo digests** — emit/update `portal/repos/<slug>.md` from the repo-digest template,\n writing only inside `<!-- GENERATED -->` regions.\n4. **Update the unified repo registry** — reconcile `portal/registry/repo-registry.md` rows with the\n set of digests (add, update, flag-removed).\n5. **Update venture/system maps** — refresh member-repo tables in venture digests and the venture\n map diagram.\n6. **Generate Mermaid architecture diagrams** — system context, container/service, venture, and\n cross-repo dependency graphs, with stable node IDs = slugs.\n7. **Detect changed dependencies** — diff each repo's dependency set against the last recorded set;\n surface additions, removals, and version changes.\n8. **Identify duplicated capabilities** — cluster the `Capabilities` lists across repos and flag\n overlaps for consolidation review.\n9. **Update `llms.txt`** — regenerate the machine-readable index from the registry.\n10. **Prepare showcase content** — stage curated facts (scale metrics, featured ventures,\n simplified diagram) into `showcase/content/` for the Phase C build. It stages content; it does\n **not** build the website.\n\n### Out of scope\n- Building or deploying the public website (that is Phase C tooling: `landing-page-generator` etc.).\n- Editing source repositories (read-only against them).\n- Overwriting `<!-- HUMAN -->` regions or any hand-authored prose.\n- Inventing facts — unknowns are written as `Unknown`/`TBD`.\n\n## 3. Inputs\n\n| Input | Description | Default |\n|-------|-------------|---------|\n| `repos` | List of repo paths/URLs or a manifest file | required |\n| `portal_root` | Path to this portal repo | `.` |\n| `source_read_budget` | Max files / bytes to read per repo for the \"selected source\" pass | conservative |\n| `mode` | `plan` (report changes only) or `apply` (write files) | `plan` |\n| `sections` | Subset of capabilities to run (e.g. `digests,registry,diagrams`) | all |\n\n## 4. Outputs\n\n- Updated files under `portal/` (`repos/`, `ventures/`, `registry/`, `architecture/`,\n `current-state/`), `llms.txt`, and staged `showcase/content/`.\n- A **run report**: what changed, dependency deltas, duplication flags, and any `Unknown`s that need\n a human.\n- Changelog entries appended to `portal/current-state/changelog.md`.\n\n## 5. Contracts & invariants (must hold after every run)\n\n- Registry ⇄ digests are 1:1 (no orphans, no duplicates).\n- Every diagram node ID resolves to a real digest slug.\n- Every venture lists only repos that have digests, and each such repo names its venture.\n- `<!-- GENERATED -->` regions are the only regions written; `<!-- HUMAN -->` regions are preserved\n byte-for-byte.\n- Slugs are stable across runs; a rename requires a superseding ADR, not a silent change.\n- No fabricated facts; `Unknown`/`TBD` where data is missing.\n- `plan` mode writes nothing; `apply` mode leaves the portal internally consistent or aborts.\n\n## 6. High-level flow\n\n```mermaid\ngraph TD\n IN[repos + portal_root] --> SCAN[Scan repos]\n SCAN --> READ[Read CLAUDE.md / README / docs / ADRs / manifests / selected source]\n READ --> DIG:::proc\n DIG[Build/refresh repo digests] --> REG[Reconcile registry]\n READ --> DEP[Diff dependencies]\n DIG --> DUP[Cluster capabilities → duplication flags]\n REG --> VEN[Update venture maps]\n VEN --> DIAG[Generate Mermaid diagrams]\n DEP --> REPORT\n DUP --> REPORT\n DIAG --> LLMS[Update llms.txt]\n LLMS --> SHOW[Stage showcase content]\n SHOW --> REPORT[Run report + changelog]\n classDef proc fill:#eee;\n```\n\n## 7. Capability duplication detection (approach sketch)\n\n- Normalize each repo's `Capabilities` entries (lowercase, canonical synonyms).\n- Group identical/near-identical capabilities across repos.\n- Emit a flag when ≥2 repos claim the same capability, with a suggested owner and a link to both\n digests. Surface in the run report and the status dashboard's \"duplicated capabilities\" count.\n\n## 8. Dependency-change detection (approach sketch)\n\n- Parse manifests/locks (npm, Python, Go, Rust, etc. — reuse `senior-architect` /\n `dependency-auditor` capabilities where possible).\n- Store the last-seen dependency set inside each digest's `<!-- GENERATED -->` dependency table.\n- On each run, diff and report added/removed/changed; never edit the source repo.\n\n## 9. Reuse of existing skills\n\n| Concern | Reuse |\n|---------|-------|\n| Diagram generation | `senior-architect` (Mermaid/PlantUML), `architecture_diagram_generator` |\n| Dependency parsing | `senior-architect` dependency analyzer, `dependency-auditor` |\n| Repo summarization | `codebase-onboarding` |\n| Doc structure | `documentation-writer` (Diátaxis) |\n| Index generation | `create-llms` / `update-llms` |\n| Hygiene / orphan checks | `knowledge-ops` |\n| Showcase build (downstream) | `landing-page-generator`, `design-system` |\n\nThe orchestrator's novelty is **multi-repo aggregation + a unified registry + cross-repo diagrams +\nduplication detection** — the gaps identified in the skills audit that no single existing skill covers.\n\n## 10. Non-goals / risks\n\n- **Not a CI system** — it is an on-demand skill; scheduling is external.\n- **Read budget matters** — reading \"selected source files\" must stay bounded to avoid cost blowups;\n prefer manifests, entry points, and interface files over whole trees.\n- **Human-in-the-loop** — duplication flags and `Unknown`s are surfaced for a human, not\n auto-resolved.\n\n## 11. Acceptance criteria (for when it is built)\n\n- Running in `plan` mode against a set of repos produces a correct change report and writes nothing.\n- Running in `apply` mode leaves all invariants in §5 satisfied.\n- Re-running with no repo changes is a no-op (idempotent).\n- `<!-- HUMAN -->` content is never modified.\n\n---\n\nSee [`README.md`](/skills/portfolio-portal-orchestrator) in this folder for status. Implementation is **Phase D** on the\n[roadmap](/current-state/roadmap).\n"},{"id":"/readme","kind":"page","entityType":"doc","title":"README","route":"/readme","sourcePath":"README.md","slug":null,"frontmatter":{},"excerpt":"A markdown-first architecture and showcase portal for Azwaan's AI venture ecosystem.","headings":[{"depth":2,"text":"The three layers","id":"the-three-layers"},{"depth":2,"text":"Repository map","id":"repository-map"},{"depth":2,"text":"Quick start for a human editor","id":"quick-start-for-a-human-editor"},{"depth":2,"text":"Status","id":"status"}],"diagrams":0,"links":["portal/portfolio-overview.md","CLAUDE.md","docs/information-architecture.md","templates/repo-digest.template.md","portal/registry/repo-registry.md","templates/venture-digest.template.md","portal/architecture/architecture-review.md","portal/architecture/architecture-risks.md","portal/architecture/strategic-opportunities.md","portal/architecture/architecture-evolution.md","portal/decisions/0005-platform-services-and-consolidation.md","portal/capabilities/README.md","skills/portfolio-portal-orchestrator/SPEC.md"],"body":"# Portfolio Architecture Portal\n\nA **markdown-first architecture and showcase portal** for Azwaan's AI venture ecosystem.\n\nThis repository is the single source of truth that explains the **system of systems** — how\nindividual repositories, ventures, and services fit together — and, eventually, feeds a public\nshowcase that communicates the scale and sophistication of the ecosystem.\n\n## The three layers\n\nThis portal deliberately separates three levels of explanation:\n\n| Layer | Question it answers | Where it lives |\n|-------|--------------------|----------------|\n| **Repo-level docs** | *What is this individual repo and how does it work?* | Inside each repo (README, docs, ADRs, CLAUDE.md) |\n| **Portfolio portal** *(this repo)* | *How do the repos, ventures, and services combine into a system of systems?* | [`portal/`](portal/) |\n| **Public showcase** | *How large and sophisticated is the venture ecosystem?* | [`showcase/`](showcase/) — later target, not built yet |\n\n> **Design principle**\n> Repo-level docs explain individual repos.\n> The portfolio portal explains the system of systems.\n> The public showcase explains the scale and sophistication of Azwaan's AI venture ecosystem.\n\n## Repository map\n\n```\nportfolio-portal/\n├── README.md # You are here\n├── CLAUDE.md # How this repo is maintained (read before editing)\n├── llms.txt # Machine-readable index of the portal\n├── docs/ # How the portal itself is structured & maintained\n│ ├── information-architecture.md # Page hierarchy + navigation model\n│ ├── documentation-model.md # Diátaxis model for portal content\n│ ├── update-conventions.md # When & how to update each page\n│ └── glossary.md # Shared vocabulary\n├── portal/ # THE SYSTEM-OF-SYSTEMS LAYER\n│ ├── index.md # Portal home / entry point\n│ ├── portfolio-overview.md # Executive briefing (read first)\n│ ├── capabilities/ # Capability Architecture — registry + capability pages\n│ ├── registry/repo-registry.md # Unified registry of all repos\n│ ├── repos/ # One digest per repo (e.g. shared-skills)\n│ ├── ventures/ # One digest per venture / system (layers)\n│ ├── architecture/ # System-of-systems, intelligence platform, principles, reuse map\n│ ├── current-state/ # Status dashboard, changelog, roadmap\n│ └── decisions/ # Decision log / ADRs\n├── showcase/ # PUBLIC SHOWCASE LAYER (later target)\n├── templates/ # Canonical markdown page templates\n├── design/ # Design-system + brand-token placeholders\n├── ai/ # AI handoff files (Claude & ChatGPT)\n└── skills/portfolio-portal-orchestrator/ # Spec for a future automation skill\n```\n\n## Quick start for a human editor\n\n1. Read the [`Portfolio Overview`](/overview) — the executive briefing for the whole ecosystem.\n2. Read [`CLAUDE.md`](/CLAUDE) — it explains the maintenance rules for both humans and AI agents.\n3. Skim [`docs/information-architecture.md`](/about/information-architecture) to understand the navigation model.\n3. To add a repo: copy [`templates/repo-digest.template.md`](templates/repo-digest.template.md) into\n [`portal/repos/`](portal/repos/) and add a row to\n [`portal/registry/repo-registry.md`](/registry/repo-registry).\n4. To add a venture: copy [`templates/venture-digest.template.md`](templates/venture-digest.template.md)\n into [`portal/ventures/`](portal/ventures/).\n5. Record any significant decision as an ADR in [`portal/decisions/`](portal/decisions/).\n\n## Status\n\n**Phase D — ecosystem architecture review.** With capability architecture in place, the portal now reviews\nitself: a holistic, evidence-first EA review — [Architecture Review](/architecture/architecture-review),\n[Risks](/architecture/architecture-risks),\n[Strategic Opportunities](/architecture/strategic-opportunities), and\n[Recommended Architecture Evolution](/architecture/architecture-evolution) — with a **proposed**\n[ADR 0005](/decisions/0005-platform-services-and-consolidation) introducing a Platform Services layer.\nRecommendations only; no architecture was modified. Earlier phases established the\n[Capability Architecture](/capabilities) (Phase C) and the four processed systems (Phases B).\nStill to come: adopting the review's direction, full digests for the layer-4 consumer repos, the public\nshowcase website, and the automation skill (spec only — see\n[`skills/portfolio-portal-orchestrator/SPEC.md`](/skills/portfolio-portal-orchestrator/SPEC)).\n"},{"id":"/CLAUDE","kind":"page","entityType":"doc","title":"CLAUDE","route":"/CLAUDE","sourcePath":"CLAUDE.md","slug":null,"frontmatter":{},"excerpt":"This file tells Claude (and any AI agent or human) how to work inside this repository. Read it","headings":[{"depth":2,"text":"1. What this repo is","id":"1-what-this-repo-is"},{"depth":2,"text":"2. Golden rules","id":"2-golden-rules"},{"depth":2,"text":"3. Where things go","id":"3-where-things-go"},{"depth":2,"text":"4. File & naming conventions","id":"4-file-naming-conventions"},{"depth":2,"text":"5. Update conventions (summary)","id":"5-update-conventions-summary"},{"depth":2,"text":"6. Working with the future orchestrator","id":"6-working-with-the-future-orchestrator"},{"depth":2,"text":"7. Diátaxis, IA & Principles","id":"7-di-taxis-ia-principles"},{"depth":2,"text":"8. Definition of done for any change","id":"8-definition-of-done-for-any-change"}],"diagrams":0,"links":["portal/registry/repo-registry.md","docs/update-conventions.md","skills/portfolio-portal-orchestrator/SPEC.md","docs/documentation-model.md","docs/information-architecture.md","portal/architecture/principles.md"],"body":"# CLAUDE.md — How to maintain the Portfolio Architecture Portal\n\nThis file tells Claude (and any AI agent or human) how to work inside this repository. Read it\nfully before creating or editing anything.\n\n## 1. What this repo is\n\nA **markdown-first** portal that documents Azwaan's AI venture ecosystem as a **system of\nsystems**. It is documentation and structure — not application code. There is no build step in\nPhase A. Everything is human-readable markdown plus Mermaid diagrams that render on GitHub.\n\nKeep these three layers distinct at all times:\n\n- **Repo-level docs** live in the individual repos, not here. This portal only holds *digests* of them.\n- **Portfolio portal** (`portal/`) explains how repos and ventures combine.\n- **Public showcase** (`showcase/`) is a later target; do not build the website yet.\n\n## 2. Golden rules\n\n1. **Markdown-first.** Prefer `.md` with embedded fenced ` ```mermaid ` diagrams over binary or\n HTML artifacts. GitHub must be able to render every page.\n2. **Templates are canonical.** Never invent a new page shape. Copy the matching file from\n [`templates/`](templates/) and fill it in. If a template is missing, add the template first.\n3. **One digest per repo, one digest per venture.** Digests are summaries — link back to the\n source repo for detail; do not duplicate full repo docs here.\n4. **The registry is the index of record.** Every repo digest MUST have a matching row in\n [`portal/registry/repo-registry.md`](/registry/repo-registry). No orphan digests.\n5. **Decisions get ADRs.** Any structural or cross-repo decision is recorded in\n [`portal/decisions/`](portal/decisions/) using the ADR template. ADRs are append-only and\n immutable once `Accepted` — supersede, never rewrite.\n6. **Keep current-state current.** When something changes, update\n [`portal/current-state/`](portal/current-state/) (status dashboard + changelog) in the same change.\n7. **Placeholders are explicit.** Mark unfinished content with `> **TODO:**` or `<!-- PLACEHOLDER -->`\n so gaps are visible and greppable. Never leave silent blanks.\n8. **Do not fabricate.** If a repo's stack, status, or dependency is unknown, write `Unknown` /\n `TBD`, not a guess. This portal is a factual map.\n\n## 3. Where things go\n\n| You want to… | Do this |\n|--------------|---------|\n| Add a repo | Copy `templates/repo-digest.template.md` → `portal/repos/<slug>.md`; add registry row |\n| Add a venture/system | Copy `templates/venture-digest.template.md` → `portal/ventures/<slug>.md` |\n| Add/replace a diagram | Edit the relevant page in `portal/architecture/` (embedded Mermaid) |\n| Record a decision | Copy `templates/adr.template.md` → `portal/decisions/NNNN-title.md` |\n| Log a change | Add an entry to `portal/current-state/changelog.md` |\n| Add a generic page | Copy `templates/page.template.md` |\n| Update the AI index | Edit `llms.txt` (keep it in sync with the registry) |\n\n## 4. File & naming conventions\n\n- **Slugs:** lowercase, hyphenated, stable. A repo's digest filename = its slug (e.g. `repos/auth-service.md`).\n- **ADRs:** `NNNN-kebab-title.md`, zero-padded 4-digit sequence, never reused.\n- **Frontmatter:** every portal content page starts with the YAML block defined in its template\n (`title`, `type`, `status`, `last_reviewed`, `owner`). Keep `last_reviewed` accurate (`YYYY-MM-DD`).\n- **Diagrams:** Mermaid, embedded in fenced blocks. Keep node IDs stable so diffs stay small.\n\n## 5. Update conventions (summary)\n\nFull detail in [`docs/update-conventions.md`](/about/update-conventions). In short:\n\n- Editing a repo digest → bump `last_reviewed`, sync the registry row, add a changelog line.\n- New cross-repo relationship → update the architecture diagrams + note in the changelog.\n- New decision → ADR + changelog line.\n- Every change should leave the portal internally consistent (no dangling links, no orphan pages).\n\n## 6. Working with the future orchestrator\n\nA skill named **`portfolio-portal-orchestrator`** is specified (not yet built) in\n[`skills/portfolio-portal-orchestrator/SPEC.md`](/skills/portfolio-portal-orchestrator/SPEC).\nWhen it exists it will *generate* many of these pages automatically from source repos. Until then,\nmaintain pages by hand **using the same templates the skill will target** — so the eventual\nautomation is a drop-in, not a rewrite. Do not hand-author anything the spec marks as\nmachine-generated in a way that would conflict with regeneration; keep generated and hand-written\nsections clearly separated (see the `<!-- GENERATED -->` / `<!-- HUMAN -->` markers in templates).\n\n## 7. Diátaxis, IA & Principles\n\nPortal content follows the Diátaxis model (see [`docs/documentation-model.md`](/about/documentation-model))\nand the information architecture in [`docs/information-architecture.md`](/about/information-architecture).\nRespect the page-type of whatever you edit — don't turn a reference page into a tutorial.\n\nSystems and documentation are governed by the ecosystem-wide\n[**Architecture Principles**](/architecture/principles) (10 principles, e.g. reproducibility &\nprovenance, knowledge referenced never owned, honest realization labelling). Cite them in digests/ADRs;\na change that violates one needs an ADR justifying the exception.\n\n## 8. Definition of done for any change\n\n- [ ] Used the correct template / respected page frontmatter\n- [ ] Registry and digests are consistent (no orphans, no dangling links)\n- [ ] Diagrams still render and reflect reality\n- [ ] `current-state` + `changelog` updated\n- [ ] Any decision captured as an ADR\n- [ ] `last_reviewed` dates bumped where touched\n"},{"id":"repo:inexisstudios","kind":"entity-stub","entityType":"repository","title":"inexisstudios","route":"/repos","slug":"inexisstudios","frontmatter":{"layer":"Applications & Agents"},"note":"registered; full digest pending"},{"id":"repo:leadplatform","kind":"entity-stub","entityType":"repository","title":"leadplatform","route":"/repos","slug":"leadplatform","frontmatter":{"layer":"Applications & Agents"},"note":"registered; full digest pending"},{"id":"repo:outreachagent","kind":"entity-stub","entityType":"repository","title":"outreachagent","route":"/repos","slug":"outreachagent","frontmatter":{"layer":"Applications & Agents"},"note":"registered; full digest pending"},{"id":"principle:1","kind":"principle","title":"Reproducibility & complete provenance","route":"/architecture/principles#1-reproducibility-complete-provenance","virtual":true},{"id":"principle:2","kind":"principle","title":"Definition vs. derivation (separate inputs from outputs)","route":"/architecture/principles#2-definition-vs-derivation-separate-inputs-from-outputs","virtual":true},{"id":"principle:3","kind":"principle","title":"Knowledge is referenced, never owned","route":"/architecture/principles#3-knowledge-is-referenced-never-owned","virtual":true},{"id":"principle:4","kind":"principle","title":"Stage is state, not location","route":"/architecture/principles#4-stage-is-state-not-location","virtual":true},{"id":"principle:5","kind":"principle","title":"Composable, opt-in services","route":"/architecture/principles#5-composable-opt-in-services","virtual":true},{"id":"principle:6","kind":"principle","title":"Measurement / evaluation is first-class","route":"/architecture/principles#6-measurement-evaluation-is-first-class","virtual":true},{"id":"principle:7","kind":"principle","title":"No speculative abstraction (the four-part test)","route":"/architecture/principles#7-no-speculative-abstraction-the-four-part-test","virtual":true},{"id":"principle:8","kind":"principle","title":"Honest realization labelling (implemented vs planned vs vision)","route":"/architecture/principles#8-honest-realization-labelling-implemented-vs-planned-vs-vision","virtual":true},{"id":"principle:9","kind":"principle","title":"Layered leverage (capability flows upward)","route":"/architecture/principles#9-layered-leverage-capability-flows-upward","virtual":true},{"id":"principle:10","kind":"principle","title":"Phase-gated, reviewable change","route":"/architecture/principles#10-phase-gated-reviewable-change","virtual":true},{"id":"principle:11","kind":"principle","title":"Deterministic rules decide; AI explains","route":"/architecture/principles#11-deterministic-rules-decide-ai-explains","virtual":true},{"id":"principle:12","kind":"principle","title":"Capabilities are first-class and repo-independent","route":"/architecture/principles#12-capabilities-are-first-class-and-repo-independent","virtual":true},{"id":"op-principle:O1","kind":"operating-principle","title":"Humans own capture, review, and approval","route":"/operating-model/operating-principles#o1-humans-own-capture-review-and-approval","virtual":true},{"id":"op-principle:O2","kind":"operating-principle","title":"Nothing is ever auto-sent","route":"/operating-model/operating-principles#o2-nothing-is-ever-auto-sent","virtual":true},{"id":"op-principle:O3","kind":"operating-principle","title":"Deterministic first; AI explains, never decides","route":"/operating-model/operating-principles#o3-deterministic-first-ai-explains-never-decides","virtual":true},{"id":"op-principle:O4","kind":"operating-principle","title":"Capture first","route":"/operating-model/operating-principles#o4-capture-first","virtual":true},{"id":"op-principle:O5","kind":"operating-principle","title":"Maturity is a human quality gate","route":"/operating-model/operating-principles#o5-maturity-is-a-human-quality-gate","virtual":true},{"id":"op-principle:O6","kind":"operating-principle","title":"Immutable, versioned contracts; consumers pin versions","route":"/operating-model/operating-principles#o6-immutable-versioned-contracts-consumers-pin-versions","virtual":true},{"id":"op-principle:O7","kind":"operating-principle","title":"Evidence-first; record uncertainty","route":"/operating-model/operating-principles#o7-evidence-first-record-uncertainty","virtual":true},{"id":"op-principle:O8","kind":"operating-principle","title":"Phase-gated change with architecture review","route":"/operating-model/operating-principles#o8-phase-gated-change-with-architecture-review","virtual":true},{"id":"op-principle:O9","kind":"operating-principle","title":"One-way feedback (never mutate a consumed artefact)","route":"/operating-model/operating-principles#o9-one-way-feedback-never-mutate-a-consumed-artefact","virtual":true},{"id":"term:skill","kind":"glossary-term","title":"Skill","route":"/operating-model/glossary#skill","virtual":true},{"id":"term:knowledge-estate","kind":"glossary-term","title":"Knowledge Estate","route":"/operating-model/glossary#knowledge-estate","virtual":true},{"id":"term:knowledge-asset","kind":"glossary-term","title":"Knowledge Asset","route":"/operating-model/glossary#knowledge-asset","virtual":true},{"id":"term:asset-maturity-state","kind":"glossary-term","title":"Asset maturity state","route":"/operating-model/glossary#asset-maturity-state","virtual":true},{"id":"term:scope-dimension","kind":"glossary-term","title":"Scope dimension","route":"/operating-model/glossary#scope-dimension","virtual":true},{"id":"term:pack-intelligence-pack","kind":"glossary-term","title":"Pack (Intelligence Pack)","route":"/operating-model/glossary#pack-intelligence-pack","virtual":true},{"id":"term:intelligence-product","kind":"glossary-term","title":"Intelligence Product","route":"/operating-model/glossary#intelligence-product","virtual":true},{"id":"term:consumer-skill","kind":"glossary-term","title":"Consumer skill","route":"/operating-model/glossary#consumer-skill","virtual":true},{"id":"term:builder-skill","kind":"glossary-term","title":"Builder skill","route":"/operating-model/glossary#builder-skill","virtual":true},{"id":"term:finding","kind":"glossary-term","title":"Finding","route":"/operating-model/glossary#finding","virtual":true},{"id":"term:recommendation","kind":"glossary-term","title":"Recommendation","route":"/operating-model/glossary#recommendation","virtual":true},{"id":"term:website-assessment","kind":"glossary-term","title":"Website Assessment","route":"/operating-model/glossary#website-assessment","virtual":true},{"id":"term:score-assessment","kind":"glossary-term","title":"Score (assessment)","route":"/operating-model/glossary#score-assessment","virtual":true},{"id":"term:site-maturity-level","kind":"glossary-term","title":"Site maturity level","route":"/operating-model/glossary#site-maturity-level","virtual":true},{"id":"term:opportunity-score","kind":"glossary-term","title":"Opportunity Score","route":"/operating-model/glossary#opportunity-score","virtual":true},{"id":"term:commercial-opportunity-profile-cop","kind":"glossary-term","title":"Commercial Opportunity Profile (COP)","route":"/operating-model/glossary#commercial-opportunity-profile-cop","virtual":true},{"id":"term:signal","kind":"glossary-term","title":"Signal","route":"/operating-model/glossary#signal","virtual":true},{"id":"term:observed-asset-observation","kind":"glossary-term","title":"Observed asset / Observation","route":"/operating-model/glossary#observed-asset-observation","virtual":true},{"id":"term:journey-intelligence","kind":"glossary-term","title":"Journey Intelligence","route":"/operating-model/glossary#journey-intelligence","virtual":true},{"id":"term:run","kind":"glossary-term","title":"Run","route":"/operating-model/glossary#run","virtual":true},{"id":"term:case-business-reference-asset-benchmark","kind":"glossary-term","title":"Case / Business / Reference asset / Benchmark","route":"/operating-model/glossary#case-business-reference-asset-benchmark","virtual":true},{"id":"term:capability","kind":"glossary-term","title":"Capability","route":"/operating-model/glossary#capability","virtual":true},{"id":"term:venture-system","kind":"glossary-term","title":"Venture / System","route":"/operating-model/glossary#venture-system","virtual":true},{"id":"term:layer","kind":"glossary-term","title":"Layer","route":"/operating-model/glossary#layer","virtual":true},{"id":"term:digest","kind":"glossary-term","title":"Digest","route":"/operating-model/glossary#digest","virtual":true},{"id":"term:adr","kind":"glossary-term","title":"ADR","route":"/operating-model/glossary#adr","virtual":true},{"id":"term:domain-brief","kind":"glossary-term","title":"Domain Brief","route":"/operating-model/glossary#domain-brief","virtual":true},{"id":"term:review-package","kind":"glossary-term","title":"Review Package","route":"/operating-model/glossary#review-package","virtual":true},{"id":"term:maturity","kind":"glossary-term","title":"\"Maturity\"","route":"/operating-model/glossary#maturity","virtual":true},{"id":"term:pack-vs-intelligence-product","kind":"glossary-term","title":"\"Pack\" vs \"Intelligence Product\"","route":"/operating-model/glossary#pack-vs-intelligence-product","virtual":true},{"id":"term:observation-vs-observed-asset","kind":"glossary-term","title":"\"Observation\" vs \"Observed asset\"","route":"/operating-model/glossary#observation-vs-observed-asset","virtual":true},{"id":"term:venture-vs-system","kind":"glossary-term","title":"\"Venture\" vs \"System\"","route":"/operating-model/glossary#venture-vs-system","virtual":true},{"id":"layer:intelligence-products","kind":"layer","title":"Intelligence Products","route":"/overview","virtual":true},{"id":"layer:intelligence-platform","kind":"layer","title":"Intelligence Platform","route":"/overview","virtual":true},{"id":"layer:shared-skills","kind":"layer","title":"Shared Skills","route":"/overview","virtual":true},{"id":"layer:applications-agents","kind":"layer","title":"Applications & Agents","route":"/overview","virtual":true},{"id":"tech:markdown","kind":"technology","title":"Markdown","route":"/repos","virtual":true},{"id":"tech:python","kind":"technology","title":"Python","route":"/repos","virtual":true},{"id":"tech:ts","kind":"technology","title":"TS","route":"/repos","virtual":true},{"id":"tech:shell","kind":"technology","title":"Shell","route":"/repos","virtual":true},{"id":"tech:typescript","kind":"technology","title":"TypeScript","route":"/repos","virtual":true},{"id":"tech:sql-supabase","kind":"technology","title":"SQL (Supabase)","route":"/repos","virtual":true},{"id":"tech:js","kind":"technology","title":"JS","route":"/repos","virtual":true},{"id":"tech:yaml","kind":"technology","title":"YAML","route":"/repos","virtual":true},{"id":"tech:docker","kind":"technology","title":"Docker","route":"/repos","virtual":true},{"id":"tech:php-wp","kind":"technology","title":"PHP (WP)","route":"/repos","virtual":true},{"id":"tech:markdown-packs","kind":"technology","title":"Markdown (packs)","route":"/repos","virtual":true},{"id":"tech:skill-md","kind":"technology","title":"SKILL.md","route":"/repos","virtual":true},{"id":"tech:tanstack-start","kind":"technology","title":"TanStack Start","route":"/repos","virtual":true},{"id":"tech:react-19","kind":"technology","title":"React 19","route":"/repos","virtual":true},{"id":"tech:cloudflare-pages","kind":"technology","title":"Cloudflare Pages","route":"/repos","virtual":true},{"id":"tech:d1","kind":"technology","title":"D1","route":"/repos","virtual":true},{"id":"tech:r2","kind":"technology","title":"R2","route":"/repos","virtual":true},{"id":"tech:playwright","kind":"technology","title":"Playwright","route":"/repos","virtual":true},{"id":"tech:typescript-next-js","kind":"technology","title":"TypeScript (Next.js)","route":"/repos","virtual":true},{"id":"tech:cloudflare-worker","kind":"technology","title":"Cloudflare Worker","route":"/repos","virtual":true}],"edges":[{"from":"/architecture/architecture-evolution","to":"/architecture/architecture-review","type":"references"},{"from":"/architecture/architecture-evolution","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/architecture/architecture-evolution","to":"/architecture/strategic-opportunities","type":"references"},{"from":"/architecture/architecture-evolution","to":"/architecture/architecture-risks","type":"references"},{"from":"/architecture/architecture-evolution","to":"/overview","type":"references"},{"from":"/architecture/architecture-evolution","to":"/architecture/principles","type":"references"},{"from":"/architecture/architecture-review","to":"/architecture/architecture-risks","type":"references"},{"from":"/architecture/architecture-review","to":"/architecture/strategic-opportunities","type":"references"},{"from":"/architecture/architecture-review","to":"/architecture/architecture-evolution","type":"references"},{"from":"/architecture/architecture-review","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/architecture/architecture-review","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/architecture/architecture-review","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/architecture/architecture-review","to":"/capabilities/cap-reusable-ai-skills","type":"references"},{"from":"/architecture/architecture-review","to":"/capabilities/cap-knowledge-intelligence","type":"references"},{"from":"/architecture/architecture-review","to":"/capabilities/cap-intelligence-productization","type":"references"},{"from":"/architecture/architecture-review","to":"/capabilities/cap-reproducible-evaluation","type":"references"},{"from":"/architecture/architecture-review","to":"/capabilities/cap-commercial-opportunity","type":"references"},{"from":"/architecture/architecture-review","to":"/capabilities/cap-architecture-governance","type":"references"},{"from":"/architecture/architecture-review","to":"/repos/intelproducts","type":"references"},{"from":"/architecture/architecture-review","to":"/repos/shared-skills","type":"references"},{"from":"/architecture/architecture-review","to":"/architecture/recommendations","type":"references"},{"from":"/architecture/architecture-review","to":"/repos/personalops","type":"references"},{"from":"/architecture/architecture-review","to":"/architecture/intelligence-platform","type":"references","anchor":"4--runtime-information-flow"},{"from":"/architecture/architecture-review","to":"/architecture/principles","type":"references"},{"from":"/architecture/architecture-review","to":"/architecture/system-of-systems","type":"references"},{"from":"/architecture/architecture-risks","to":"/architecture/architecture-review","type":"references"},{"from":"/architecture/architecture-risks","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/architecture/architecture-risks","to":"/architecture/strategic-opportunities","type":"references"},{"from":"/architecture/architecture-risks","to":"/architecture/architecture-evolution","type":"references"},{"from":"/architecture/architecture-risks","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/capabilities","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/capabilities/cap-reusable-ai-skills","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/capabilities/cap-knowledge-intelligence","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/capabilities/cap-intelligence-productization","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/capabilities/cap-reproducible-evaluation","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/capabilities/cap-commercial-opportunity","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/capabilities/cap-architecture-governance","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/architecture/recommendations","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/decisions/0004-capability-architecture","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/architecture/architecture-review","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/architecture/architecture-risks","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/architecture/strategic-opportunities","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/architecture/architecture-evolution","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/architecture/system-of-systems","type":"references"},{"from":"/architecture/capability-reuse-map","to":"/architecture/principles","type":"references"},{"from":"/architecture/intelligence-platform","to":"/overview","type":"references"},{"from":"/architecture/intelligence-platform","to":"/architecture/principles","type":"references"},{"from":"/architecture/intelligence-platform","to":"/repos/shared-skills","type":"references"},{"from":"/architecture/intelligence-platform","to":"/repos/personalops","type":"references"},{"from":"/architecture/intelligence-platform","to":"/repos/intelproducts","type":"references"},{"from":"/architecture/intelligence-platform","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/architecture/intelligence-platform","to":"/ventures/intelligence-platform","type":"references"},{"from":"/architecture/intelligence-platform","to":"/architecture/system-of-systems","type":"references"},{"from":"/architecture/intelligence-platform","to":"/decisions/0003-intelligence-platform-layer-model","type":"references"},{"from":"/architecture/principles","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/architecture/principles","to":"/CLAUDE","type":"references"},{"from":"/architecture/principles","to":"/decisions/0002-layered-ecosystem-and-digest-standard","type":"references"},{"from":"/architecture/principles","to":"/repos/shared-skills","type":"references"},{"from":"/architecture/principles","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/architecture/principles","to":"/overview","type":"references"},{"from":"/architecture/principles","to":"/decisions/0004-capability-architecture","type":"references"},{"from":"/architecture/principles","to":"/capabilities","type":"references"},{"from":"/architecture/principles","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/architecture/principles","to":"/architecture/system-of-systems","type":"references"},{"from":"/architecture/principles","to":"/architecture/intelligence-platform","type":"references"},{"from":"/architecture/recommendations","to":"/architecture/system-of-systems","type":"references","anchor":"4-system-dependency-map-cross-repo"},{"from":"/architecture/recommendations","to":"/about/update-conventions","type":"references"},{"from":"/architecture/recommendations","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/architecture/strategic-opportunities","to":"/architecture/architecture-review","type":"references"},{"from":"/architecture/strategic-opportunities","to":"/architecture/principles","type":"references"},{"from":"/architecture/strategic-opportunities","to":"/architecture/architecture-risks","type":"references"},{"from":"/architecture/strategic-opportunities","to":"/architecture/architecture-evolution","type":"references"},{"from":"/architecture/strategic-opportunities","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/architecture/strategic-opportunities","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/architecture/system-of-systems","to":"/architecture/intelligence-platform","type":"references"},{"from":"/architecture/system-of-systems","to":"/overview","type":"references"},{"from":"/architecture/system-of-systems","to":"/architecture/principles","type":"references"},{"from":"/architecture/system-of-systems","to":"/repos/shared-skills","type":"references"},{"from":"/architecture/system-of-systems","to":"/repos/personalops","type":"references"},{"from":"/architecture/system-of-systems","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/architecture/system-of-systems","to":"/repos/intelproducts","type":"references"},{"from":"/architecture/system-of-systems","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/architecture/system-of-systems","to":"/ventures/intelligence-platform","type":"references"},{"from":"/architecture/system-of-systems","to":"/ventures/shared-skills","type":"references"},{"from":"/architecture/system-of-systems","to":"/readme","type":"references"},{"from":"/architecture/system-of-systems","to":"/capabilities","type":"references"},{"from":"/architecture/system-of-systems","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/architecture/system-of-systems","to":"/architecture/recommendations","type":"references"},{"from":"/architecture/system-of-systems","to":"/registry/repo-registry","type":"references"},{"from":"/architecture/system-of-systems","to":"/current-state/status-dashboard","type":"references"},{"from":"/architecture/system-of-systems","to":"/decisions","type":"references"},{"from":"/capabilities","to":"/registry/repo-registry","type":"references"},{"from":"/capabilities","to":"/capabilities/cap-reusable-ai-skills","type":"references"},{"from":"/capabilities","to":"/capabilities/cap-knowledge-intelligence","type":"references"},{"from":"/capabilities","to":"/capabilities/cap-intelligence-productization","type":"references"},{"from":"/capabilities","to":"/capabilities/cap-reproducible-evaluation","type":"references"},{"from":"/capabilities","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/capabilities","to":"/capabilities/cap-commercial-opportunity","type":"references"},{"from":"/capabilities","to":"/capabilities/cap-architecture-governance","type":"references"},{"from":"/capabilities","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/capabilities","to":"/overview","type":"references"},{"from":"/capabilities","to":"/architecture/principles","type":"references"},{"from":"/ventures/shared-skills","to":"/capabilities/cap-architecture-governance","type":"implements"},{"from":"/capabilities/cap-architecture-governance","to":"/ventures/shared-skills","type":"providedBy"},{"from":"/capabilities/cap-architecture-governance","to":"layer:shared-skills","type":"inLayer","inferred":true},{"from":"/capabilities/cap-architecture-governance","to":"/readme","type":"references"},{"from":"/capabilities/cap-architecture-governance","to":"/repos/shared-skills","type":"references"},{"from":"/capabilities/cap-architecture-governance","to":"/capabilities/cap-reusable-ai-skills","type":"relatedCapability"},{"from":"/capabilities/cap-architecture-governance","to":"/overview","type":"references"},{"from":"/capabilities/cap-architecture-governance","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/capabilities/cap-architecture-governance","to":"/capabilities","type":"references"},{"from":"/capabilities/cap-architecture-governance","to":"/architecture/capability-reuse-map","type":"references"},{"from":"repo:outreachagent","to":"/capabilities/cap-commercial-opportunity","type":"implements"},{"from":"/capabilities/cap-commercial-opportunity","to":"repo:outreachagent","type":"providedBy"},{"from":"/repos/intelproducts","to":"/capabilities/cap-commercial-opportunity","type":"implements"},{"from":"/capabilities/cap-commercial-opportunity","to":"/repos/intelproducts","type":"providedBy"},{"from":"repo:outreachagent","to":"/capabilities/cap-commercial-opportunity","type":"consumes"},{"from":"/capabilities/cap-commercial-opportunity","to":"repo:outreachagent","type":"consumedBy"},{"from":"/capabilities/cap-commercial-opportunity","to":"layer:applications-agents","type":"inLayer","inferred":true},{"from":"/capabilities/cap-commercial-opportunity","to":"layer:intelligence-products","type":"inLayer","inferred":true},{"from":"/capabilities/cap-commercial-opportunity","to":"/repos/intelproducts","type":"references"},{"from":"/capabilities/cap-commercial-opportunity","to":"/capabilities/cap-website-assessment","type":"relatedCapability"},{"from":"/capabilities/cap-commercial-opportunity","to":"/capabilities/cap-intelligence-productization","type":"relatedCapability"},{"from":"/capabilities/cap-commercial-opportunity","to":"/capabilities/cap-reusable-ai-skills","type":"relatedCapability"},{"from":"/capabilities/cap-commercial-opportunity","to":"/capabilities","type":"references"},{"from":"/capabilities/cap-commercial-opportunity","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/repos/intelproducts","to":"/capabilities/cap-intelligence-productization","type":"implements"},{"from":"/capabilities/cap-intelligence-productization","to":"/repos/intelproducts","type":"providedBy"},{"from":"/repos/personalops","to":"/capabilities/cap-intelligence-productization","type":"implements"},{"from":"/capabilities/cap-intelligence-productization","to":"/repos/personalops","type":"providedBy"},{"from":"repo:leadplatform","to":"/capabilities/cap-intelligence-productization","type":"consumes"},{"from":"/capabilities/cap-intelligence-productization","to":"repo:leadplatform","type":"consumedBy"},{"from":"repo:outreachagent","to":"/capabilities/cap-intelligence-productization","type":"consumes"},{"from":"/capabilities/cap-intelligence-productization","to":"repo:outreachagent","type":"consumedBy"},{"from":"/capabilities/cap-intelligence-productization","to":"layer:intelligence-products","type":"inLayer","inferred":true},{"from":"/capabilities/cap-intelligence-productization","to":"layer:intelligence-platform","type":"inLayer","inferred":true},{"from":"/capabilities/cap-intelligence-productization","to":"/repos/intelproducts","type":"references"},{"from":"/capabilities/cap-intelligence-productization","to":"/repos/personalops","type":"references"},{"from":"/capabilities/cap-intelligence-productization","to":"/architecture/principles","type":"references"},{"from":"/capabilities/cap-intelligence-productization","to":"/capabilities/cap-knowledge-intelligence","type":"relatedCapability"},{"from":"/capabilities/cap-intelligence-productization","to":"/capabilities/cap-reusable-ai-skills","type":"relatedCapability"},{"from":"/capabilities/cap-intelligence-productization","to":"/architecture/intelligence-platform","type":"references"},{"from":"/capabilities/cap-intelligence-productization","to":"/capabilities","type":"references"},{"from":"/capabilities/cap-intelligence-productization","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/repos/personalops","to":"/capabilities/cap-knowledge-intelligence","type":"implements"},{"from":"/capabilities/cap-knowledge-intelligence","to":"/repos/personalops","type":"providedBy"},{"from":"/repos/personalops","to":"/capabilities/cap-knowledge-intelligence","type":"consumes"},{"from":"/capabilities/cap-knowledge-intelligence","to":"/repos/personalops","type":"consumedBy"},{"from":"/repos/intelproducts","to":"/capabilities/cap-knowledge-intelligence","type":"consumes"},{"from":"/capabilities/cap-knowledge-intelligence","to":"/repos/intelproducts","type":"consumedBy"},{"from":"repo:outreachagent","to":"/capabilities/cap-knowledge-intelligence","type":"consumes"},{"from":"/capabilities/cap-knowledge-intelligence","to":"repo:outreachagent","type":"consumedBy"},{"from":"repo:leadplatform","to":"/capabilities/cap-knowledge-intelligence","type":"consumes"},{"from":"/capabilities/cap-knowledge-intelligence","to":"repo:leadplatform","type":"consumedBy"},{"from":"/capabilities/cap-knowledge-intelligence","to":"layer:intelligence-platform","type":"inLayer","inferred":true},{"from":"/capabilities/cap-knowledge-intelligence","to":"/repos/personalops","type":"references"},{"from":"/capabilities/cap-knowledge-intelligence","to":"/repos/intelproducts","type":"references"},{"from":"/capabilities/cap-knowledge-intelligence","to":"/capabilities/cap-reusable-ai-skills","type":"relatedCapability"},{"from":"/capabilities/cap-knowledge-intelligence","to":"/architecture/intelligence-platform","type":"references"},{"from":"/capabilities/cap-knowledge-intelligence","to":"/capabilities","type":"references"},{"from":"/capabilities/cap-knowledge-intelligence","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/repos/website-intelligence-lab","to":"/capabilities/cap-reproducible-evaluation","type":"implements"},{"from":"/capabilities/cap-reproducible-evaluation","to":"/repos/website-intelligence-lab","type":"providedBy"},{"from":"repo:inexisstudios","to":"/capabilities/cap-reproducible-evaluation","type":"consumes"},{"from":"/capabilities/cap-reproducible-evaluation","to":"repo:inexisstudios","type":"consumedBy"},{"from":"/capabilities/cap-reproducible-evaluation","to":"layer:intelligence-platform","type":"inLayer","inferred":true},{"from":"/capabilities/cap-reproducible-evaluation","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/capabilities/cap-reproducible-evaluation","to":"/capabilities/cap-reusable-ai-skills","type":"relatedCapability"},{"from":"/capabilities/cap-reproducible-evaluation","to":"/architecture/intelligence-platform","type":"references"},{"from":"/capabilities/cap-reproducible-evaluation","to":"/architecture/principles","type":"references"},{"from":"/capabilities/cap-reproducible-evaluation","to":"/capabilities","type":"references"},{"from":"/capabilities/cap-reproducible-evaluation","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/ventures/shared-skills","to":"/capabilities/cap-reusable-ai-skills","type":"implements"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/ventures/shared-skills","type":"providedBy"},{"from":"/repos/personalops","to":"/capabilities/cap-reusable-ai-skills","type":"consumes"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/repos/personalops","type":"consumedBy"},{"from":"/repos/website-intelligence-lab","to":"/capabilities/cap-reusable-ai-skills","type":"consumes"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/repos/website-intelligence-lab","type":"consumedBy"},{"from":"/repos/intelproducts","to":"/capabilities/cap-reusable-ai-skills","type":"consumes"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/repos/intelproducts","type":"consumedBy"},{"from":"repo:leadplatform","to":"/capabilities/cap-reusable-ai-skills","type":"consumes"},{"from":"/capabilities/cap-reusable-ai-skills","to":"repo:leadplatform","type":"consumedBy"},{"from":"repo:outreachagent","to":"/capabilities/cap-reusable-ai-skills","type":"consumes"},{"from":"/capabilities/cap-reusable-ai-skills","to":"repo:outreachagent","type":"consumedBy"},{"from":"/capabilities/cap-reusable-ai-skills","to":"layer:shared-skills","type":"inLayer","inferred":true},{"from":"/capabilities/cap-reusable-ai-skills","to":"/repos/shared-skills","type":"references"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/readme","type":"references"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/repos/personalops","type":"references"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/repos/intelproducts","type":"references"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/ventures/shared-skills","type":"references"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/capabilities","type":"references"},{"from":"/capabilities/cap-reusable-ai-skills","to":"/architecture/capability-reuse-map","type":"references"},{"from":"repo:inexisstudios","to":"/capabilities/cap-website-assessment","type":"implements"},{"from":"/capabilities/cap-website-assessment","to":"repo:inexisstudios","type":"providedBy"},{"from":"/repos/intelproducts","to":"/capabilities/cap-website-assessment","type":"implements"},{"from":"/capabilities/cap-website-assessment","to":"/repos/intelproducts","type":"providedBy"},{"from":"/repos/personalops","to":"/capabilities/cap-website-assessment","type":"implements"},{"from":"/capabilities/cap-website-assessment","to":"/repos/personalops","type":"providedBy"},{"from":"/repos/website-intelligence-lab","to":"/capabilities/cap-website-assessment","type":"implements"},{"from":"/capabilities/cap-website-assessment","to":"/repos/website-intelligence-lab","type":"providedBy"},{"from":"repo:outreachagent","to":"/capabilities/cap-website-assessment","type":"consumes"},{"from":"/capabilities/cap-website-assessment","to":"repo:outreachagent","type":"consumedBy"},{"from":"repo:leadplatform","to":"/capabilities/cap-website-assessment","type":"consumes"},{"from":"/capabilities/cap-website-assessment","to":"repo:leadplatform","type":"consumedBy"},{"from":"/capabilities/cap-website-assessment","to":"layer:applications-agents","type":"inLayer","inferred":true},{"from":"/capabilities/cap-website-assessment","to":"layer:intelligence-products","type":"inLayer","inferred":true},{"from":"/capabilities/cap-website-assessment","to":"layer:intelligence-platform","type":"inLayer","inferred":true},{"from":"/capabilities/cap-website-assessment","to":"/architecture/principles","type":"references"},{"from":"/capabilities/cap-website-assessment","to":"/repos/intelproducts","type":"references"},{"from":"/capabilities/cap-website-assessment","to":"/repos/personalops","type":"references"},{"from":"/capabilities/cap-website-assessment","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/capabilities/cap-website-assessment","to":"/capabilities/cap-intelligence-productization","type":"relatedCapability"},{"from":"/capabilities/cap-website-assessment","to":"/capabilities/cap-reusable-ai-skills","type":"relatedCapability"},{"from":"/capabilities/cap-website-assessment","to":"/capabilities/cap-knowledge-intelligence","type":"relatedCapability"},{"from":"/capabilities/cap-website-assessment","to":"/capabilities/cap-reproducible-evaluation","type":"relatedCapability"},{"from":"/capabilities/cap-website-assessment","to":"/capabilities/cap-commercial-opportunity","type":"relatedCapability"},{"from":"/capabilities/cap-website-assessment","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/capabilities/cap-website-assessment","to":"/overview","type":"references"},{"from":"/capabilities/cap-website-assessment","to":"/architecture/intelligence-platform","type":"references"},{"from":"/capabilities/cap-website-assessment","to":"/decisions/0004-capability-architecture","type":"references"},{"from":"/current-state/changelog","to":"/decisions/0007-portfolio-graph-and-custom-astro","type":"references"},{"from":"/current-state/changelog","to":"/governance","type":"references"},{"from":"/current-state/changelog","to":"/governance/capability-decision-framework","type":"references"},{"from":"/current-state/changelog","to":"/governance/capability-decision-matrix","type":"references"},{"from":"/current-state/changelog","to":"/governance/repository-lifecycle","type":"references"},{"from":"/current-state/changelog","to":"/governance/documentation-governance","type":"references"},{"from":"/current-state/changelog","to":"/governance/ai-governance","type":"references"},{"from":"/current-state/changelog","to":"/governance/architecture-review-lifecycle","type":"references"},{"from":"/current-state/changelog","to":"/decisions/0006-architecture-governance-framework","type":"references"},{"from":"/current-state/changelog","to":"/operating-model","type":"references"},{"from":"/current-state/changelog","to":"/operating-model/knowledge-asset-lifecycle","type":"references"},{"from":"/current-state/changelog","to":"/operating-model/concept-ownership","type":"references"},{"from":"/current-state/changelog","to":"/operating-model/glossary","type":"references"},{"from":"/current-state/changelog","to":"/operating-model/context-architecture","type":"references"},{"from":"/current-state/changelog","to":"/operating-model/operating-principles","type":"references"},{"from":"/current-state/changelog","to":"/operating-model/ai-collaboration-model","type":"references"},{"from":"/current-state/changelog","to":"/architecture/architecture-review","type":"references"},{"from":"/current-state/changelog","to":"/architecture/architecture-risks","type":"references"},{"from":"/current-state/changelog","to":"/architecture/strategic-opportunities","type":"references"},{"from":"/current-state/changelog","to":"/architecture/architecture-evolution","type":"references"},{"from":"/current-state/changelog","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/current-state/changelog","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/current-state/changelog","to":"/capabilities","type":"references"},{"from":"/current-state/changelog","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/current-state/changelog","to":"/decisions/0004-capability-architecture","type":"references"},{"from":"/current-state/changelog","to":"/architecture/intelligence-platform","type":"references"},{"from":"/current-state/changelog","to":"/repos/personalops","type":"references"},{"from":"/current-state/changelog","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/current-state/changelog","to":"/repos/intelproducts","type":"references"},{"from":"/current-state/changelog","to":"/ventures/intelligence-platform","type":"references"},{"from":"/current-state/changelog","to":"/architecture/principles","type":"references"},{"from":"/current-state/changelog","to":"/decisions/0003-intelligence-platform-layer-model","type":"references"},{"from":"/current-state/changelog","to":"/repos/shared-skills","type":"references"},{"from":"/current-state/changelog","to":"/ventures/shared-skills","type":"references"},{"from":"/current-state/changelog","to":"/overview","type":"references"},{"from":"/current-state/changelog","to":"/decisions/0002-layered-ecosystem-and-digest-standard","type":"references"},{"from":"/current-state/changelog","to":"/architecture/recommendations","type":"references"},{"from":"/current-state/changelog","to":"/decisions/0001-record-architecture-decisions","type":"references"},{"from":"/current-state/roadmap","to":"/repos/shared-skills","type":"references"},{"from":"/current-state/roadmap","to":"/ventures/shared-skills","type":"references"},{"from":"/current-state/roadmap","to":"/overview","type":"references"},{"from":"/current-state/roadmap","to":"/decisions/0002-layered-ecosystem-and-digest-standard","type":"references"},{"from":"/current-state/roadmap","to":"/architecture/system-of-systems","type":"references"},{"from":"/current-state/roadmap","to":"/architecture/recommendations","type":"references"},{"from":"/current-state/status-dashboard","to":"/current-state/changelog","type":"references"},{"from":"/current-state/status-dashboard","to":"/current-state/roadmap","type":"references"},{"from":"/current-state/status-dashboard","to":"/governance","type":"references"},{"from":"/current-state/status-dashboard","to":"/governance/capability-decision-framework","type":"references"},{"from":"/current-state/status-dashboard","to":"/governance/capability-decision-matrix","type":"references"},{"from":"/current-state/status-dashboard","to":"/governance/repository-lifecycle","type":"references"},{"from":"/current-state/status-dashboard","to":"/governance/documentation-governance","type":"references"},{"from":"/current-state/status-dashboard","to":"/governance/ai-governance","type":"references"},{"from":"/current-state/status-dashboard","to":"/governance/architecture-review-lifecycle","type":"references"},{"from":"/current-state/status-dashboard","to":"/decisions/0006-architecture-governance-framework","type":"references"},{"from":"/current-state/status-dashboard","to":"/operating-model/knowledge-asset-lifecycle","type":"references"},{"from":"/current-state/status-dashboard","to":"/operating-model/concept-ownership","type":"references"},{"from":"/current-state/status-dashboard","to":"/operating-model/glossary","type":"references"},{"from":"/current-state/status-dashboard","to":"/operating-model/context-architecture","type":"references"},{"from":"/current-state/status-dashboard","to":"/operating-model/operating-principles","type":"references"},{"from":"/current-state/status-dashboard","to":"/operating-model/ai-collaboration-model","type":"references"},{"from":"/current-state/status-dashboard","to":"/architecture/architecture-review","type":"references"},{"from":"/current-state/status-dashboard","to":"/architecture/architecture-risks","type":"references"},{"from":"/current-state/status-dashboard","to":"/architecture/strategic-opportunities","type":"references"},{"from":"/current-state/status-dashboard","to":"/architecture/architecture-evolution","type":"references"},{"from":"/current-state/status-dashboard","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/current-state/status-dashboard","to":"/decisions/0004-capability-architecture","type":"references"},{"from":"/current-state/status-dashboard","to":"/architecture/principles","type":"references"},{"from":"/decisions/0001-record-architecture-decisions","to":"/CLAUDE","type":"relatesTo"},{"from":"/decisions/0001-record-architecture-decisions","to":"/about/update-conventions","type":"relatesTo"},{"from":"/decisions/0002-layered-ecosystem-and-digest-standard","to":"/repos/shared-skills","type":"relatesTo"},{"from":"/decisions/0002-layered-ecosystem-and-digest-standard","to":"/overview","type":"relatesTo"},{"from":"/decisions/0002-layered-ecosystem-and-digest-standard","to":"/architecture/system-of-systems","type":"relatesTo"},{"from":"/decisions/0002-layered-ecosystem-and-digest-standard","to":"/registry/repo-registry","type":"relatesTo"},{"from":"/decisions/0002-layered-ecosystem-and-digest-standard","to":"/about/information-architecture","type":"relatesTo"},{"from":"/decisions/0002-layered-ecosystem-and-digest-standard","to":"/CLAUDE","type":"relatesTo"},{"from":"/decisions/0002-layered-ecosystem-and-digest-standard","to":"/about/update-conventions","type":"relatesTo"},{"from":"/decisions/0003-intelligence-platform-layer-model","to":"/architecture/intelligence-platform","type":"relatesTo"},{"from":"/decisions/0003-intelligence-platform-layer-model","to":"/overview","type":"relatesTo"},{"from":"/decisions/0003-intelligence-platform-layer-model","to":"/architecture/system-of-systems","type":"relatesTo"},{"from":"/decisions/0003-intelligence-platform-layer-model","to":"/registry/repo-registry","type":"relatesTo"},{"from":"/decisions/0003-intelligence-platform-layer-model","to":"/current-state/status-dashboard","type":"relatesTo"},{"from":"/decisions/0003-intelligence-platform-layer-model","to":"/architecture/principles","type":"relatesTo"},{"from":"/decisions/0003-intelligence-platform-layer-model","to":"/CLAUDE","type":"relatesTo"},{"from":"/decisions/0004-capability-architecture","to":"/architecture/capability-reuse-map","type":"relatesTo"},{"from":"/decisions/0004-capability-architecture","to":"/capabilities","type":"relatesTo"},{"from":"/decisions/0004-capability-architecture","to":"/overview","type":"relatesTo"},{"from":"/decisions/0004-capability-architecture","to":"/architecture/principles","type":"relatesTo"},{"from":"/decisions/0004-capability-architecture","to":"/CLAUDE","type":"relatesTo"},{"from":"/decisions/0005-platform-services-and-consolidation","to":"/architecture/architecture-review","type":"relatesTo"},{"from":"/decisions/0005-platform-services-and-consolidation","to":"/decisions/0002-layered-ecosystem-and-digest-standard","type":"relatesTo"},{"from":"/decisions/0005-platform-services-and-consolidation","to":"/decisions/0003-intelligence-platform-layer-model","type":"relatesTo"},{"from":"/decisions/0005-platform-services-and-consolidation","to":"/overview","type":"relatesTo"},{"from":"/decisions/0005-platform-services-and-consolidation","to":"/architecture/system-of-systems","type":"relatesTo"},{"from":"/decisions/0005-platform-services-and-consolidation","to":"/capabilities","type":"relatesTo"},{"from":"/decisions/0005-platform-services-and-consolidation","to":"/architecture/architecture-risks","type":"relatesTo"},{"from":"/decisions/0005-platform-services-and-consolidation","to":"/architecture/strategic-opportunities","type":"relatesTo"},{"from":"/decisions/0005-platform-services-and-consolidation","to":"/architecture/architecture-evolution","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/decisions/0001-record-architecture-decisions","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/decisions/0004-capability-architecture","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/governance","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/governance/capability-decision-framework","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/governance/capability-decision-matrix","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/governance/repository-lifecycle","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/governance/documentation-governance","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/governance/ai-governance","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/governance/architecture-review-lifecycle","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/overview","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/operating-model","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/decisions/0005-platform-services-and-consolidation","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/operating-model/operating-principles","type":"relatesTo"},{"from":"/decisions/0006-architecture-governance-framework","to":"/architecture/principles","type":"relatesTo"},{"from":"/decisions/0007-portfolio-graph-and-custom-astro","to":"/about/website-implementation-plan","type":"relatesTo"},{"from":"/decisions/0007-portfolio-graph-and-custom-astro","to":"/about/website-strategy-validation","type":"relatesTo"},{"from":"/decisions","to":"/about/update-conventions","type":"references","anchor":"recipe-record-a-decision"},{"from":"/decisions","to":"/decisions/0001-record-architecture-decisions","type":"references"},{"from":"/decisions","to":"/decisions/0002-layered-ecosystem-and-digest-standard","type":"references"},{"from":"/decisions","to":"/decisions/0003-intelligence-platform-layer-model","type":"references"},{"from":"/decisions","to":"/decisions/0004-capability-architecture","type":"references"},{"from":"/decisions","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/decisions","to":"/decisions/0006-architecture-governance-framework","type":"references"},{"from":"/decisions","to":"/decisions/0007-portfolio-graph-and-custom-astro","type":"references"},{"from":"/governance","to":"/operating-model","type":"references"},{"from":"/governance","to":"/governance/capability-decision-framework","type":"references"},{"from":"/governance","to":"/governance/capability-decision-matrix","type":"references"},{"from":"/governance","to":"/governance/repository-lifecycle","type":"references"},{"from":"/governance","to":"/governance/documentation-governance","type":"references"},{"from":"/governance","to":"/governance/ai-governance","type":"references"},{"from":"/governance","to":"/governance/architecture-review-lifecycle","type":"references"},{"from":"/governance","to":"/decisions","type":"references"},{"from":"/governance","to":"/architecture/principles","type":"references"},{"from":"/governance","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/governance","to":"/operating-model/operating-principles","type":"references"},{"from":"/governance","to":"/decisions/0001-record-architecture-decisions","type":"references"},{"from":"/governance","to":"/operating-model/concept-ownership","type":"references"},{"from":"/governance","to":"/capabilities/cap-architecture-governance","type":"references"},{"from":"/governance","to":"/CLAUDE","type":"references"},{"from":"/governance","to":"/about/update-conventions","type":"references"},{"from":"/governance","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/governance","to":"/decisions/0006-architecture-governance-framework","type":"references"},{"from":"/governance/ai-governance","to":"/operating-model/ai-collaboration-model","type":"references"},{"from":"/governance/ai-governance","to":"/operating-model/operating-principles","type":"references"},{"from":"/governance/ai-governance","to":"/ai/chatgpt.handoff","type":"references"},{"from":"/governance/ai-governance","to":"/architecture/principles","type":"references"},{"from":"/governance/ai-governance","to":"/governance","type":"references","anchor":"2--architectural-decision-making-process"},{"from":"/governance/ai-governance","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/governance/ai-governance","to":"/ai/AI-HANDOFF","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/architecture/principles","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/governance/ai-governance","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/architecture/architecture-review","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/governance","type":"references","anchor":"2--architectural-decision-making-process"},{"from":"/governance/architecture-review-lifecycle","to":"/governance/capability-decision-matrix","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/operating-model/concept-ownership","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/architecture/system-of-systems","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/architecture/architecture-risks","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/architecture/strategic-opportunities","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/architecture/architecture-evolution","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/governance/repository-lifecycle","type":"references"},{"from":"/governance/architecture-review-lifecycle","to":"/CLAUDE","type":"references"},{"from":"/governance/capability-decision-framework","to":"/governance/capability-decision-matrix","type":"references"},{"from":"/governance/capability-decision-framework","to":"/governance","type":"references","anchor":"2--architectural-decision-making-process"},{"from":"/governance/capability-decision-framework","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/governance/capability-decision-framework","to":"/architecture/architecture-review","type":"references"},{"from":"/governance/capability-decision-framework","to":"/decisions/0003-intelligence-platform-layer-model","type":"references"},{"from":"/governance/capability-decision-framework","to":"/architecture/principles","type":"references"},{"from":"/governance/capability-decision-framework","to":"/governance/repository-lifecycle","type":"references"},{"from":"/governance/capability-decision-framework","to":"/architecture/system-of-systems","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/governance/capability-decision-framework","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/architecture/principles","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/capabilities/cap-reusable-ai-skills","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/capabilities/cap-knowledge-intelligence","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/capabilities/cap-intelligence-productization","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/overview","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/capabilities/cap-architecture-governance","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/capabilities/cap-reproducible-evaluation","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/decisions/0003-intelligence-platform-layer-model","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/architecture/architecture-review","type":"references","anchor":"5--capability-reuse"},{"from":"/governance/capability-decision-matrix","to":"/operating-model/concept-ownership","type":"references"},{"from":"/governance/capability-decision-matrix","to":"/governance","type":"references","anchor":"2--architectural-decision-making-process"},{"from":"/governance/capability-decision-matrix","to":"/governance/architecture-review-lifecycle","type":"references"},{"from":"/governance/documentation-governance","to":"/about/update-conventions","type":"references"},{"from":"/governance/documentation-governance","to":"/about/documentation-model","type":"references"},{"from":"/governance/documentation-governance","to":"/CLAUDE","type":"references"},{"from":"/governance/documentation-governance","to":"/architecture/principles","type":"references"},{"from":"/governance/documentation-governance","to":"/architecture/architecture-risks","type":"references"},{"from":"/governance/documentation-governance","to":"/governance/ai-governance","type":"references"},{"from":"/governance/documentation-governance","to":"/governance","type":"references"},{"from":"/governance/documentation-governance","to":"/operating-model/context-architecture","type":"references"},{"from":"/governance/repository-lifecycle","to":"/registry/repo-registry","type":"references"},{"from":"/governance/repository-lifecycle","to":"/decisions/0002-layered-ecosystem-and-digest-standard","type":"references"},{"from":"/governance/repository-lifecycle","to":"/governance","type":"references","anchor":"2--architectural-decision-making-process"},{"from":"/governance/repository-lifecycle","to":"/governance/capability-decision-matrix","type":"references"},{"from":"/governance/repository-lifecycle","to":"/architecture/principles","type":"references"},{"from":"/governance/repository-lifecycle","to":"/architecture/system-of-systems","type":"references"},{"from":"/governance/repository-lifecycle","to":"/governance/architecture-review-lifecycle","type":"references"},{"from":"/governance/repository-lifecycle","to":"/about/update-conventions","type":"references"},{"from":"/governance/repository-lifecycle","to":"/current-state/status-dashboard","type":"references"},{"from":"/","to":"/overview","type":"references"},{"from":"/","to":"/readme","type":"references"},{"from":"/","to":"/CLAUDE","type":"references"},{"from":"/","to":"/capabilities","type":"references"},{"from":"/","to":"/operating-model","type":"references"},{"from":"/","to":"/governance","type":"references"},{"from":"/","to":"/registry/repo-registry","type":"references"},{"from":"/","to":"/ventures","type":"references"},{"from":"/","to":"/repos","type":"references"},{"from":"/","to":"/architecture/system-of-systems","type":"references"},{"from":"/","to":"/architecture/intelligence-platform","type":"references"},{"from":"/","to":"/architecture/principles","type":"references"},{"from":"/","to":"/architecture/architecture-review","type":"references"},{"from":"/","to":"/architecture/architecture-risks","type":"references"},{"from":"/","to":"/architecture/strategic-opportunities","type":"references"},{"from":"/","to":"/architecture/architecture-evolution","type":"references"},{"from":"/","to":"/current-state/status-dashboard","type":"references"},{"from":"/","to":"/decisions","type":"references"},{"from":"/operating-model","to":"/architecture/system-of-systems","type":"references"},{"from":"/operating-model","to":"/capabilities","type":"references"},{"from":"/operating-model","to":"/operating-model/knowledge-asset-lifecycle","type":"references"},{"from":"/operating-model","to":"/operating-model/concept-ownership","type":"references"},{"from":"/operating-model","to":"/operating-model/glossary","type":"references"},{"from":"/operating-model","to":"/operating-model/context-architecture","type":"references"},{"from":"/operating-model","to":"/operating-model/operating-principles","type":"references"},{"from":"/operating-model","to":"/operating-model/ai-collaboration-model","type":"references"},{"from":"/operating-model","to":"/capabilities/cap-knowledge-intelligence","type":"references"},{"from":"/operating-model","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/operating-model","to":"/repos/personalops","type":"references"},{"from":"/operating-model","to":"/capabilities/cap-intelligence-productization","type":"references"},{"from":"/operating-model","to":"/capabilities/cap-commercial-opportunity","type":"references"},{"from":"/operating-model","to":"/architecture/intelligence-platform","type":"references"},{"from":"/operating-model","to":"/architecture/principles","type":"references"},{"from":"/operating-model","to":"/governance","type":"references"},{"from":"/operating-model","to":"/decisions","type":"references"},{"from":"/operating-model","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/operating-model","to":"/architecture/architecture-risks","type":"references"},{"from":"/operating-model","to":"/overview","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/operating-model/context-architecture","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/operating-model/operating-principles","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/ai/claude.handoff","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/ai/chatgpt.handoff","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/capabilities/cap-reusable-ai-skills","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/architecture/intelligence-platform","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/ai/AI-HANDOFF","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/architecture/architecture-risks","type":"references"},{"from":"/operating-model/ai-collaboration-model","to":"/operating-model","type":"references"},{"from":"/operating-model/concept-ownership","to":"/capabilities/cap-reusable-ai-skills","type":"references"},{"from":"/operating-model/concept-ownership","to":"/capabilities/cap-knowledge-intelligence","type":"references"},{"from":"/operating-model/concept-ownership","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/operating-model/concept-ownership","to":"/capabilities/cap-intelligence-productization","type":"references"},{"from":"/operating-model/concept-ownership","to":"/capabilities/cap-reproducible-evaluation","type":"references"},{"from":"/operating-model/concept-ownership","to":"/capabilities","type":"references"},{"from":"/operating-model/concept-ownership","to":"/capabilities/cap-commercial-opportunity","type":"references"},{"from":"/operating-model/concept-ownership","to":"/capabilities/cap-architecture-governance","type":"references"},{"from":"/operating-model/concept-ownership","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/operating-model/concept-ownership","to":"/operating-model/glossary","type":"references"},{"from":"/operating-model/concept-ownership","to":"/operating-model/knowledge-asset-lifecycle","type":"references"},{"from":"/operating-model/concept-ownership","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/operating-model/concept-ownership","to":"/architecture/architecture-review","type":"references","anchor":"1--capability-ownership"},{"from":"/operating-model/context-architecture","to":"/capabilities","type":"references"},{"from":"/operating-model/context-architecture","to":"/architecture/intelligence-platform","type":"references"},{"from":"/operating-model/context-architecture","to":"/overview","type":"references"},{"from":"/operating-model/context-architecture","to":"/architecture/system-of-systems","type":"references"},{"from":"/operating-model/context-architecture","to":"/ai/AI-HANDOFF","type":"references"},{"from":"/operating-model/context-architecture","to":"/operating-model","type":"references"},{"from":"/operating-model/context-architecture","to":"/operating-model/concept-ownership","type":"references"},{"from":"/operating-model/context-architecture","to":"/operating-model/glossary","type":"references"},{"from":"/operating-model/context-architecture","to":"/operating-model/ai-collaboration-model","type":"references"},{"from":"/operating-model/glossary","to":"/about/glossary","type":"references"},{"from":"/operating-model/glossary","to":"/operating-model/concept-ownership","type":"references"},{"from":"/operating-model/glossary","to":"/operating-model/knowledge-asset-lifecycle","type":"references"},{"from":"/operating-model/knowledge-asset-lifecycle","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/operating-model/knowledge-asset-lifecycle","to":"/capabilities","type":"references"},{"from":"/operating-model/knowledge-asset-lifecycle","to":"/architecture/architecture-review","type":"references"},{"from":"/operating-model/knowledge-asset-lifecycle","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/operating-model/knowledge-asset-lifecycle","to":"/operating-model","type":"references"},{"from":"/operating-model/knowledge-asset-lifecycle","to":"/operating-model/concept-ownership","type":"references"},{"from":"/operating-model/knowledge-asset-lifecycle","to":"/operating-model/glossary","type":"references"},{"from":"/operating-model/knowledge-asset-lifecycle","to":"/architecture/intelligence-platform","type":"references","anchor":"4--runtime-information-flow"},{"from":"/operating-model/operating-principles","to":"/architecture/principles","type":"references"},{"from":"/operating-model/operating-principles","to":"/operating-model/ai-collaboration-model","type":"references"},{"from":"/operating-model/operating-principles","to":"/operating-model","type":"references"},{"from":"/overview","to":"/","type":"references"},{"from":"/overview","to":"/architecture/principles","type":"references"},{"from":"/overview","to":"/repos/shared-skills","type":"references"},{"from":"/overview","to":"/repos/personalops","type":"references"},{"from":"/overview","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/overview","to":"/repos/intelproducts","type":"references"},{"from":"/overview","to":"/capabilities","type":"references"},{"from":"/overview","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/overview","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/overview","to":"/decisions/0004-capability-architecture","type":"references"},{"from":"/overview","to":"/governance","type":"references"},{"from":"/overview","to":"/governance/capability-decision-framework","type":"references"},{"from":"/overview","to":"/governance/capability-decision-matrix","type":"references"},{"from":"/overview","to":"/governance/repository-lifecycle","type":"references"},{"from":"/overview","to":"/governance/documentation-governance","type":"references"},{"from":"/overview","to":"/governance/ai-governance","type":"references"},{"from":"/overview","to":"/governance/architecture-review-lifecycle","type":"references"},{"from":"/overview","to":"/decisions/0006-architecture-governance-framework","type":"references"},{"from":"/overview","to":"/operating-model","type":"references"},{"from":"/overview","to":"/operating-model/knowledge-asset-lifecycle","type":"references"},{"from":"/overview","to":"/operating-model/concept-ownership","type":"references"},{"from":"/overview","to":"/operating-model/glossary","type":"references"},{"from":"/overview","to":"/operating-model/context-architecture","type":"references"},{"from":"/overview","to":"/operating-model/operating-principles","type":"references"},{"from":"/overview","to":"/operating-model/ai-collaboration-model","type":"references"},{"from":"/overview","to":"/architecture/architecture-review","type":"references"},{"from":"/overview","to":"/architecture/architecture-risks","type":"references"},{"from":"/overview","to":"/architecture/strategic-opportunities","type":"references"},{"from":"/overview","to":"/architecture/architecture-evolution","type":"references"},{"from":"/overview","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/overview","to":"/architecture/intelligence-platform","type":"references","anchor":"4--runtime-information-flow"},{"from":"/overview","to":"/readme","type":"references"},{"from":"/overview","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/overview","to":"/architecture/system-of-systems","type":"references"},{"from":"/registry/repo-registry","to":"/ventures/shared-skills","type":"references"},{"from":"/registry/repo-registry","to":"/repos/shared-skills","type":"references"},{"from":"/registry/repo-registry","to":"/ventures/intelligence-platform","type":"references"},{"from":"/registry/repo-registry","to":"/repos/personalops","type":"references"},{"from":"/registry/repo-registry","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/registry/repo-registry","to":"/repos/intelproducts","type":"references"},{"from":"/registry/repo-registry","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/registry/repo-registry","to":"/about/update-conventions","type":"references"},{"from":"/repos","to":"/registry/repo-registry","type":"references"},{"from":"/repos","to":"/about/update-conventions","type":"references","anchor":"recipe-add-a-repo"},{"from":"/repos","to":"/repos/shared-skills","type":"references"},{"from":"/repos","to":"/repos/personalops","type":"references"},{"from":"/repos","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/repos","to":"/repos/intelproducts","type":"references"},{"from":"/repos","to":"/capabilities/cap-website-assessment","type":"references"},{"from":"/repos","to":"/capabilities","type":"references"},{"from":"/repos","to":"/decisions/0004-capability-architecture","type":"references"},{"from":"/repos","to":"/readme","type":"references"},{"from":"/repos/intelproducts","to":"layer:intelligence-products","type":"belongsToLayer"},{"from":"/repos/intelproducts","to":"tech:markdown-packs","type":"usesTechnology"},{"from":"tech:markdown-packs","to":"/repos/intelproducts","type":"supportsRepository"},{"from":"/repos/intelproducts","to":"tech:skill-md","type":"usesTechnology"},{"from":"tech:skill-md","to":"/repos/intelproducts","type":"supportsRepository"},{"from":"/repos/intelproducts","to":"/repos/personalops","type":"references"},{"from":"/repos/intelproducts","to":"/ventures/intelligence-platform","type":"references","anchor":"layer-3--intelligence-products"},{"from":"/repos/intelproducts","to":"/repos/shared-skills","type":"references"},{"from":"/repos/intelproducts","to":"/decisions/0003-intelligence-platform-layer-model","type":"references"},{"from":"/repos/intelproducts","to":"/architecture/intelligence-platform","type":"references"},{"from":"/repos/intelproducts","to":"/overview","type":"references"},{"from":"/repos/intelproducts","to":"/registry/repo-registry","type":"references"},{"from":"/repos/personalops","to":"layer:intelligence-platform","type":"belongsToLayer"},{"from":"/repos/personalops","to":"/ventures/intelligence-platform","type":"inSystem"},{"from":"/ventures/intelligence-platform","to":"/repos/personalops","type":"hasMember"},{"from":"/repos/personalops","to":"tech:typescript","type":"usesTechnology"},{"from":"tech:typescript","to":"/repos/personalops","type":"supportsRepository"},{"from":"/repos/personalops","to":"tech:sql-supabase","type":"usesTechnology"},{"from":"tech:sql-supabase","to":"/repos/personalops","type":"supportsRepository"},{"from":"/repos/personalops","to":"tech:js","type":"usesTechnology"},{"from":"tech:js","to":"/repos/personalops","type":"supportsRepository"},{"from":"/repos/personalops","to":"/architecture/intelligence-platform","type":"references"},{"from":"/repos/personalops","to":"/ventures/intelligence-platform","type":"references"},{"from":"/repos/personalops","to":"/repos/intelproducts","type":"references"},{"from":"/repos/personalops","to":"/repos/shared-skills","type":"references"},{"from":"/repos/personalops","to":"/decisions/0003-intelligence-platform-layer-model","type":"references"},{"from":"/repos/personalops","to":"/architecture/principles","type":"references"},{"from":"/repos/personalops","to":"/overview","type":"references"},{"from":"/repos/personalops","to":"/registry/repo-registry","type":"references"},{"from":"/repos/shared-skills","to":"layer:shared-skills","type":"belongsToLayer"},{"from":"/repos/shared-skills","to":"/ventures/shared-skills","type":"inSystem"},{"from":"/ventures/shared-skills","to":"/repos/shared-skills","type":"hasMember"},{"from":"/repos/shared-skills","to":"tech:markdown","type":"usesTechnology"},{"from":"tech:markdown","to":"/repos/shared-skills","type":"supportsRepository"},{"from":"/repos/shared-skills","to":"tech:python","type":"usesTechnology"},{"from":"tech:python","to":"/repos/shared-skills","type":"supportsRepository"},{"from":"/repos/shared-skills","to":"tech:ts","type":"usesTechnology"},{"from":"tech:ts","to":"/repos/shared-skills","type":"supportsRepository"},{"from":"/repos/shared-skills","to":"tech:shell","type":"usesTechnology"},{"from":"tech:shell","to":"/repos/shared-skills","type":"supportsRepository"},{"from":"/repos/shared-skills","to":"/ventures/shared-skills","type":"references"},{"from":"/repos/shared-skills","to":"/overview","type":"references"},{"from":"/repos/shared-skills","to":"/decisions/0002-layered-ecosystem-and-digest-standard","type":"references"},{"from":"/repos/shared-skills","to":"/current-state/roadmap","type":"references"},{"from":"/repos/shared-skills","to":"/architecture/system-of-systems","type":"references"},{"from":"/repos/shared-skills","to":"/registry/repo-registry","type":"references"},{"from":"/repos/shared-skills","to":"/architecture/recommendations","type":"references"},{"from":"/repos/website-intelligence-lab","to":"layer:intelligence-platform","type":"belongsToLayer"},{"from":"/repos/website-intelligence-lab","to":"/ventures/intelligence-platform","type":"inSystem"},{"from":"/ventures/intelligence-platform","to":"/repos/website-intelligence-lab","type":"hasMember"},{"from":"/repos/website-intelligence-lab","to":"tech:yaml","type":"usesTechnology"},{"from":"tech:yaml","to":"/repos/website-intelligence-lab","type":"supportsRepository"},{"from":"/repos/website-intelligence-lab","to":"tech:shell","type":"usesTechnology"},{"from":"tech:shell","to":"/repos/website-intelligence-lab","type":"supportsRepository"},{"from":"/repos/website-intelligence-lab","to":"tech:docker","type":"usesTechnology"},{"from":"tech:docker","to":"/repos/website-intelligence-lab","type":"supportsRepository"},{"from":"/repos/website-intelligence-lab","to":"tech:php-wp","type":"usesTechnology"},{"from":"tech:php-wp","to":"/repos/website-intelligence-lab","type":"supportsRepository"},{"from":"/repos/website-intelligence-lab","to":"/architecture/intelligence-platform","type":"references"},{"from":"/repos/website-intelligence-lab","to":"/ventures/intelligence-platform","type":"references"},{"from":"/repos/website-intelligence-lab","to":"/repos/shared-skills","type":"references"},{"from":"/repos/website-intelligence-lab","to":"/architecture/principles","type":"references"},{"from":"/repos/website-intelligence-lab","to":"/overview","type":"references"},{"from":"/repos/website-intelligence-lab","to":"/registry/repo-registry","type":"references"},{"from":"/ventures","to":"/overview","type":"references"},{"from":"/ventures","to":"/architecture/system-of-systems","type":"references"},{"from":"/ventures","to":"/about/update-conventions","type":"references","anchor":"recipe-add-a-venture--system"},{"from":"/ventures","to":"/ventures/shared-skills","type":"references"},{"from":"/ventures","to":"/ventures/intelligence-platform","type":"references"},{"from":"/ventures/intelligence-platform","to":"layer:intelligence-platform","type":"inLayer"},{"from":"/ventures/intelligence-platform","to":"/architecture/intelligence-platform","type":"references"},{"from":"/ventures/intelligence-platform","to":"/repos/personalops","type":"references"},{"from":"/ventures/intelligence-platform","to":"/repos/website-intelligence-lab","type":"references"},{"from":"/ventures/intelligence-platform","to":"/repos/intelproducts","type":"references"},{"from":"/ventures/intelligence-platform","to":"/repos/shared-skills","type":"references"},{"from":"/ventures/intelligence-platform","to":"/current-state/status-dashboard","type":"references"},{"from":"/ventures/intelligence-platform","to":"/decisions/0003-intelligence-platform-layer-model","type":"references"},{"from":"/ventures/intelligence-platform","to":"/architecture/principles","type":"references"},{"from":"/ventures/shared-skills","to":"layer:shared-skills","type":"inLayer"},{"from":"/ventures/shared-skills","to":"/repos/shared-skills","type":"references"},{"from":"/ventures/shared-skills","to":"/overview","type":"references"},{"from":"/ventures/shared-skills","to":"/current-state/status-dashboard","type":"references"},{"from":"/ventures/shared-skills","to":"/current-state/roadmap","type":"references"},{"from":"/ventures/shared-skills","to":"/decisions/0002-layered-ecosystem-and-digest-standard","type":"references"},{"from":"/ventures/shared-skills","to":"/architecture/recommendations","type":"references"},{"from":"/ventures/shared-skills","to":"/repos","type":"references"},{"from":"/ventures/shared-skills","to":"/architecture/system-of-systems","type":"references"},{"from":"/about/documentation-model","to":"/about/update-conventions","type":"references"},{"from":"/about/documentation-model","to":"/about/information-architecture","type":"references"},{"from":"/about/documentation-model","to":"/about/glossary","type":"references"},{"from":"/about/glossary","to":"/operating-model/glossary","type":"references"},{"from":"/about/information-architecture","to":"/about/update-conventions","type":"references"},{"from":"/about/update-conventions","to":"/registry/repo-registry","type":"references"},{"from":"/about/update-conventions","to":"/architecture/system-of-systems","type":"references"},{"from":"/about/update-conventions","to":"/CLAUDE","type":"references"},{"from":"/about/website-implementation-plan","to":"/architecture/principles","type":"references"},{"from":"/about/website-implementation-plan","to":"/about/information-architecture","type":"references"},{"from":"/about/website-implementation-plan","to":"/governance/documentation-governance","type":"references"},{"from":"/about/website-implementation-plan","to":"/architecture/architecture-risks","type":"references"},{"from":"/about/website-implementation-plan","to":"/governance/architecture-review-lifecycle","type":"references"},{"from":"/about/website-implementation-plan","to":"/registry/repo-registry","type":"references"},{"from":"/about/website-implementation-plan","to":"/capabilities","type":"references"},{"from":"/about/website-implementation-plan","to":"/overview","type":"references"},{"from":"/about/website-implementation-plan","to":"/operating-model","type":"references"},{"from":"/about/website-implementation-plan","to":"/governance","type":"references"},{"from":"/about/website-implementation-plan","to":"/decisions","type":"references"},{"from":"/about/website-implementation-plan","to":"/architecture/architecture-review","type":"references"},{"from":"/about/website-implementation-plan","to":"/architecture/capability-reuse-map","type":"references"},{"from":"/about/website-implementation-plan","to":"/architecture/system-of-systems","type":"references"},{"from":"/about/website-strategy-validation","to":"/about/website-implementation-plan","type":"references"},{"from":"/about/website-strategy-validation","to":"/about/information-architecture","type":"references"},{"from":"/about/website-strategy-validation","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/about/website-strategy-validation","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/ai/AI-HANDOFF","to":"/ai/claude.handoff","type":"references"},{"from":"/ai/AI-HANDOFF","to":"/CLAUDE","type":"references"},{"from":"/ai/AI-HANDOFF","to":"/ai/chatgpt.handoff","type":"references"},{"from":"/ai/AI-HANDOFF","to":"/registry/repo-registry","type":"references"},{"from":"/ai/AI-HANDOFF","to":"/about/update-conventions","type":"references"},{"from":"/ai/AI-HANDOFF","to":"/current-state/changelog","type":"references"},{"from":"/ai/AI-HANDOFF","to":"/current-state/status-dashboard","type":"references"},{"from":"/ai/AI-HANDOFF","to":"/architecture/system-of-systems","type":"references"},{"from":"/ai/AI-HANDOFF","to":"/decisions","type":"references"},{"from":"/ai/AI-HANDOFF","to":"/about/information-architecture","type":"references"},{"from":"/ai/chatgpt.handoff","to":"/ai/AI-HANDOFF","type":"references"},{"from":"/ai/chatgpt.handoff","to":"/CLAUDE","type":"references"},{"from":"/ai/chatgpt.handoff","to":"/about/update-conventions","type":"references"},{"from":"/ai/claude.handoff","to":"/CLAUDE","type":"references"},{"from":"/ai/claude.handoff","to":"/ai/AI-HANDOFF","type":"references"},{"from":"/ai/claude.handoff","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/design/design-system","to":"/design/brand-tokens","type":"references"},{"from":"/showcase","to":"/showcase/content/showcase-narrative","type":"references"},{"from":"/showcase","to":"/current-state/roadmap","type":"references"},{"from":"/skills/portfolio-portal-orchestrator","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/skills/portfolio-portal-orchestrator","to":"/current-state/roadmap","type":"references"},{"from":"/skills/portfolio-portal-orchestrator/SPEC","to":"/skills/portfolio-portal-orchestrator","type":"references"},{"from":"/skills/portfolio-portal-orchestrator/SPEC","to":"/current-state/roadmap","type":"references"},{"from":"/readme","to":"/overview","type":"references"},{"from":"/readme","to":"/CLAUDE","type":"references"},{"from":"/readme","to":"/about/information-architecture","type":"references"},{"from":"/readme","to":"/registry/repo-registry","type":"references"},{"from":"/readme","to":"/architecture/architecture-review","type":"references"},{"from":"/readme","to":"/architecture/architecture-risks","type":"references"},{"from":"/readme","to":"/architecture/strategic-opportunities","type":"references"},{"from":"/readme","to":"/architecture/architecture-evolution","type":"references"},{"from":"/readme","to":"/decisions/0005-platform-services-and-consolidation","type":"references"},{"from":"/readme","to":"/capabilities","type":"references"},{"from":"/readme","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/CLAUDE","to":"/registry/repo-registry","type":"references"},{"from":"/CLAUDE","to":"/about/update-conventions","type":"references"},{"from":"/CLAUDE","to":"/skills/portfolio-portal-orchestrator/SPEC","type":"references"},{"from":"/CLAUDE","to":"/about/documentation-model","type":"references"},{"from":"/CLAUDE","to":"/about/information-architecture","type":"references"},{"from":"/CLAUDE","to":"/architecture/principles","type":"references"},{"from":"repo:inexisstudios","to":"layer:applications-agents","type":"belongsToLayer"},{"from":"repo:inexisstudios","to":"tech:tanstack-start","type":"usesTechnology"},{"from":"tech:tanstack-start","to":"repo:inexisstudios","type":"supportsRepository"},{"from":"repo:inexisstudios","to":"tech:react-19","type":"usesTechnology"},{"from":"tech:react-19","to":"repo:inexisstudios","type":"supportsRepository"},{"from":"repo:inexisstudios","to":"tech:ts","type":"usesTechnology"},{"from":"tech:ts","to":"repo:inexisstudios","type":"supportsRepository"},{"from":"repo:inexisstudios","to":"tech:cloudflare-pages","type":"usesTechnology"},{"from":"tech:cloudflare-pages","to":"repo:inexisstudios","type":"supportsRepository"},{"from":"repo:inexisstudios","to":"tech:d1","type":"usesTechnology"},{"from":"tech:d1","to":"repo:inexisstudios","type":"supportsRepository"},{"from":"repo:inexisstudios","to":"tech:r2","type":"usesTechnology"},{"from":"tech:r2","to":"repo:inexisstudios","type":"supportsRepository"},{"from":"repo:inexisstudios","to":"tech:playwright","type":"usesTechnology"},{"from":"tech:playwright","to":"repo:inexisstudios","type":"supportsRepository"},{"from":"repo:leadplatform","to":"layer:applications-agents","type":"belongsToLayer"},{"from":"repo:leadplatform","to":"tech:typescript-next-js","type":"usesTechnology"},{"from":"tech:typescript-next-js","to":"repo:leadplatform","type":"supportsRepository"},{"from":"repo:leadplatform","to":"tech:cloudflare-worker","type":"usesTechnology"},{"from":"tech:cloudflare-worker","to":"repo:leadplatform","type":"supportsRepository"},{"from":"repo:leadplatform","to":"tech:d1","type":"usesTechnology"},{"from":"tech:d1","to":"repo:leadplatform","type":"supportsRepository"},{"from":"repo:outreachagent","to":"layer:applications-agents","type":"belongsToLayer"},{"from":"repo:outreachagent","to":"tech:typescript","type":"usesTechnology"},{"from":"tech:typescript","to":"repo:outreachagent","type":"supportsRepository"}]}