Portfolio Portal
ADR accepted owner: Azwaan reviewed: 2026-07-05

ADR 0003: Model the Intelligence Platform as a multi-system layer

  • Status: accepted
  • Date: 2026-07-05
  • Deciders: Azwaan
  • Tags: structure, layering, intelligence-platform

Context

Processing the “Intelligence Platform” revealed it is not a single repository. Evidence across the source repos shows three distinct systems and a clear producer/consumer split:

  • PersonalOps / Founder Intelligence Platform (FIP) — the knowledge intelligence platform + Intelligence Dashboard that produces intelligence.
  • intelproducts — the published intelligence packs, “kept separate from the platform that produces them.”
  • website-intelligence-lab — a sibling, non-dependent website-engine evaluation platform.

Several subsystem names supplied in the request did not map cleanly to reality: Hermes and OpenClaw are planned/not-built, recommendations are split (output in outreachagent; full engine spec in the out-of-scope inexisstudios), and “estate generation” does not exist as a subsystem. A modelling decision was needed to represent this honestly in the portal.

Decision

We will:

  1. Model the Intelligence Platform as layer 2, an assembly of sibling systems (personalops, website-intelligence-lab), documented as a platform at architecture/intelligence-platform.md with four architecture views (executive, container, component, runtime).
  2. Model Intelligence Products (intelproducts) as layer 3 — the versioned, immutable output contract produced by layer 2 and consumed downstream (producer/consumer split).
  3. Record every named subsystem with an explicit implemented / planned / not-found status, and never document a capability (e.g. “estate generation”, Hermes) as if it exists.
  4. Register the real downstream consumers (leadplatform, outreachagent) as layer-4 systems, marked not yet fully processed.

Options considered

Option Pros Cons
A (chosen): multi-system layer + product contract, honest status Matches evidence; separates producer from product; safe for automation More pages/relationships to maintain
B: one “Intelligence Platform” repo digest Simple False — conflates three systems; misrepresents architecture
C: document the requested subsystems as-described Fast Would fabricate Hermes/OpenClaw/estate-generation as real

Consequences

  • Positive: the portal reflects the real architecture; downstream consumers and the producer/consumer contract are explicit; honest maturity supports planning.
  • Negative / trade-offs: more systems and cross-links to keep consistent; layer 2/3 boundary (intelproducts) needs a clear note wherever it appears.
  • Follow-ups / affected pages: portfolio-overview, system-of-systems, registry, status dashboard, Architecture Principles, and full digests for leadplatform / outreachagent when they are processed.

Compliance / review

Enforced by the Definition of Done in CLAUDE.md and Principle 8 (honest realization labelling) in the Architecture Principles. Revisit if the systems merge or the layer boundaries change.