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).