Operating Model living owner: Azwaan reviewed: 2026-07-05

Context Architecture

The ecosystem operates across five levels of context. Each level answers a different question, has a different owner, changes at a different rate, and has a distinct source of truth. Getting context placement right is what lets humans and AI agents act correctly at the right altitude. Evidence-first.

The five levels

graph TD
    BC["🏢 Business Context<br/>ventures, market, strategy, outcomes"] --> POC
    POC["🗺️ Portfolio Context<br/>system of systems, layers, capabilities"] --> PLC
    PLC["🧠 Platform Context<br/>a platform's architecture & lifecycle"] --> CC
    CC["🔧 Capability Context<br/>a reusable capability's contract"] --> RC
    RC["📦 Repository Context<br/>one repo: CLAUDE.md, README, ADRs"]

    RC -. rolls up to .-> CC -. rolls up to .-> PLC -. rolls up to .-> POC -. rolls up to .-> BC

Context flows down as intent/strategy and rolls up as evidence: a repository’s facts roll up into a capability’s contract, which rolls up into a platform view, the portfolio map, and the business strategy; conversely, business strategy sets direction that constrains platforms, capabilities, and repos.

Level detail

1 · Repository Context

  • Purpose: everything needed to work correctly inside one repository.
  • Scope: a single repo — its purpose, domain model, conventions, decisions.
  • Consumers: contributors and AI agents editing that repo.
  • Update frequency: with the code (frequent).
  • Source of truth: the repo’s own CLAUDE.md, README, docs/, and ADRs (e.g. WIL’s philosophy/ADRs, FIP’s design package).

2 · Capability Context

  • Purpose: how a reusable capability works, independent of any repo — its contract, owners, consumers.
  • Scope: one capability (may span repos, e.g. Website Assessment across 4).
  • Consumers: teams/agents composing or consuming the capability.
  • Update frequency: when the capability’s contract or maturity changes (occasional).
  • Source of truth: the Capability Registry + capability pages.

3 · Platform Context

  • Purpose: a platform’s internal architecture and lifecycle (executive → runtime).
  • Scope: one platform/system (e.g. the Intelligence Platform).
  • Consumers: architects, platform builders, AI agents reasoning about the platform.
  • Update frequency: per architectural change (occasional).
  • Source of truth: the platform architecture pages + system digests.

4 · Portfolio Context

  • Purpose: the system of systems — how repos, capabilities, layers, and dependencies fit together.
  • Scope: the whole ecosystem’s architecture.
  • Consumers: the architect (founder), new collaborators, AI context (llms.txt).
  • Update frequency: per phase / significant change.
  • Source of truth: the Portfolio Overview, system dependency map, registries, llms.txt.

5 · Business Context

  • Purpose: why the ecosystem exists — ventures, market, strategy, commercial outcomes.
  • Scope: the founder’s five venture areas and their goals.
  • Consumers: the founder; investors/partners; strategy.
  • Update frequency: slow (strategic).
  • Source of truth: the Portfolio Overview vision/strategy + venture digests; some business facts live in venture systems outside the processed repos (uncertainty recorded).

Context flow rules

Direction What flows Example
Down (intent) Strategy → platform priorities → capability requirements → repo work Business decides “AI website replacements” → assessment capability → engine repo
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
Sideways (contracts) Capabilities expose contracts consumed by peers Pack contract consumed by engine + apps

AI context (cross-cutting)

Context is not only for humans. The ecosystem exposes machine-readable context so AI agents act at the right level:

  • llms.txt — portfolio-level machine index.
  • Repo CLAUDE.md + portal AI handoff files — repo & portal working rules.
  • Capability pages & digests — structured, linkable context for retrieval.
  • (Future) the retrieval service + orchestrator would let agents pull the exact context level they need on demand.

Anti-patterns to avoid (recommendations)

  • Context at the wrong level — putting cross-repo capability facts inside one repo’s CLAUDE.md (they belong in the capability page).
  • Duplicated context — copying business strategy into every repo; link up instead.
  • Stale roll-up — repo changes not reflected in the capability/portfolio level (the orchestrator would fix this).