Portfolio Overview — Executive Briefing

Read this first. It answers one question: what is this platform, and why was it designed this way? The rest of the portal is the detailed reference. Maturity is labelled honestly throughout — implemented, partial/planned, or vision (Architecture Principle 8).

The page has two halves. The Timeless Architecture explains the design and the reasoning behind it — it changes rarely. The Current State records what is built today — it changes often. Read the first half to understand the platform; read the second to see how far it has been realised.

The Timeless Architecture

The problem

The founder runs several AI-driven ventures at once — Inexis Digital, Inexis Consulting, Inbound Lanka, and City Retreats. Built the obvious way, each venture becomes its own application with its own copy of the same knowledge, the same AI logic, and the same integrations. The intelligence that makes one venture work has to be rebuilt for the next. Improvements don’t travel. Effort doesn’t compound. The portfolio grows linearly — one unit of work per one unit of value — and quickly hits a ceiling a single founder cannot pass.

The architectural question is therefore not “how do we build these applications?” but “how do we build them so that every venture makes the next one cheaper?”

The vision

Purpose. Build a compounding, multi-venture AI ecosystem where reusable intelligence flows from a shared foundation up into products, applications, and customer-facing ventures — so each improvement at the base multiplies value across everything above it.

The design rests on four architectural decisions. Each is a deliberate answer to “how do we make effort compound?” — and each is stated here with the reason it matters, not just the mechanism.

• Reusable intelligence over project-specific intelligence. Intelligence is built once, at the base, and consumed by everything above it. Why it matters: project-specific intelligence is spent the moment it ships — it improves one venture and stops. Reusable intelligence is an asset: improve it once and every venture that consumes it improves at the same time. This is the ecosystem’s point of maximum leverage (Principle 9).

• Capabilities separated from applications. A capability (e.g. Website Assessment) is documented and versioned independently of the repositories that implement it. Why it matters: when the capability is bound to one application, it can only ever serve that application. Separated, the same capability composes into many products and ventures without being rebuilt — and the architecture can reason about what the ecosystem can do apart from where the code happens to live (ADR 0004).

• Immutable, versioned products over shared prompts. The platform publishes intelligence as versioned, immutable packs, not as prompts or snippets passed around between projects. Why it matters: a shared prompt drifts — every consumer ends up with a slightly different copy and no one can reproduce a result. A pinned pack version is a contract: a consumer knows exactly which intelligence it ran against, results are reproducible, and the producer can improve the next version without breaking the last (Principle 1 — reproducibility & provenance).

• Shared platform services over duplicated capability. Where the same service would otherwise be re-implemented in every venture repo, the architecture pulls it into a shared layer. Why it matters: duplication is the thing that stops effort compounding — it multiplies maintenance and lets implementations diverge. A shared service is built and hardened once (proposed Platform Services layer, ADR 0005).

Together these turn a portfolio of ventures into a system of systems: not five applications, but one compounding platform that five ventures draw from.

The architecture in one picture

Before any repository names, this is the whole ecosystem as a single idea — value transforming as it rises:

graph TD
  K["Knowledge"]:::k --> C["Capabilities"]:::s
  C --> I["Intelligence"]:::s
  I --> P["Products"]:::s
  P --> A["Applications"]:::s
  A --> V["Ventures"]:::v
  V --> O["Customer outcomes"]:::o
  classDef k fill:#f2f3f7,stroke:#c9cdda,color:#333;
  classDef s fill:#e6f4ea,stroke:#1f7a3d,color:#333;
  classDef v fill:#eef0f4,stroke:#8079ff,color:#333;
  classDef o fill:#eaf2ff,stroke:#3b6fd4,color:#333;

Read it as a sentence: knowledge is turned into reusable capabilities; capabilities produce structured intelligence; intelligence is published as versioned products; products power applications; applications are composed into ventures; ventures deliver customer outcomes — and the outcomes feed new knowledge back in. Every other diagram in this portal is an expansion of one segment of this picture; none of them replaces it. This is the conceptual anchor for the whole ecosystem.

The layered platform

The same idea, expressed as the architectural stack the ecosystem is actually organised into. Each layer consumes the layer below and serves the layer above; the shared foundation is used laterally by every layer, which is why it is the point of maximum leverage.

graph TD
    L6[6 · Customer-facing Solutions] --> OUT((Customers / Market))
    L5[5 · Ventures<br/>Inexis Digital · Consulting · Inbound Lanka · City Retreats] --> L6
    L4[4 · Applications & Agents] --> L5
    L3[3 · Intelligence Products<br/>versioned, immutable packs] --> L4
    L2[2 · Intelligence Platform<br/>capture → approve → structure] --> L3
    L1[1 · Shared Skills<br/>reusable AI capability] --> L2
    SRC((Sources · knowledge · signals)) --> L2
    L1 -. reusable capability .-> L2 & L3 & L4 & L5 & L6

Read top-to-bottom it is a structure; read bottom-to-top it is a flow — knowledge becoming intelligence becoming products becoming applications becoming ventures becoming customer value. (How far each layer is built today is in The Current State below — this section is about the design, not the status.)

How information flows

The lifecycle of a single unit of information as it moves through the stack — the runtime view of the picture above (detailed in the Intelligence Platform architecture):

graph LR
    S[Sources<br/>knowledge · captures · signals] --> P[Intelligence Platform<br/>capture → approve → structure]
    P --> Pr[Intelligence Products<br/>versioned, immutable packs]
    Pr --> A[Applications & Agents<br/>pin packs → act → recommend]
    A --> C[Ventures & Customers<br/>proposals · outreach · deliverables]
    C -->|outcomes / usage signals| S
    SK[[Shared Skills]] -. capability at every step .-> P & Pr & A & C

Note the closing edge: customer outcomes return as new signals. The platform is not a one-way pipeline — it is a loop, so the intelligence at the base gets better the more the ventures at the top are used. That feedback is what makes the compounding real rather than aspirational.

Website Assessment — the architecture in one example

One capability demonstrates almost every idea on this page, so it is worth following end to end. Website Assessment takes industry knowledge about what drives customer enquiries in a trade and turns it into a scored, evidence-backed conversation with a prospect.

graph TD
  IK["Industry knowledge"]:::src
  subgraph L2["Layer 2 · Platform"]
    KI["Knowledge Intelligence"]:::d
  end
  subgraph L3["Layer 3 · Product"]
    IP["Assessment package"]:::d
  end
  subgraph L4["Layer 4 · Apps"]
    ENG["Assessment engine"]:::d
    COP["Opportunity profile"]:::d
    OUT["Outreach email"]:::d
    PROP["Website proposal"]:::d
  end
  subgraph L5["Layer 5 · Venture"]
    CUST["Inexis Digital customer"]:::v
  end
  IK --> KI --> IP --> ENG --> COP --> OUT --> PROP --> CUST
  classDef src fill:#f2f3f7,stroke:#c9cdda,color:#333;
  classDef d fill:#e6f4ea,stroke:#1f7a3d,color:#333;
  classDef v fill:#eef0f4,stroke:#8079ff,color:#333;

It touches every idea at once:

• Layered architecture — the one capability crosses Layers 2 → 5, exactly the stack above.
• Intelligence product — the assessment knowledge is published as a versioned pack, not embedded in the engine; the engine pins a pack version and is reproducible against it.
• Reusable capability — the same capability is consumed by more than one application (outreachagent, and declared by leadplatform), not rebuilt per consumer.
• Deterministic processing — the engine scores by rules, not opinion; AI explains the score, and a human approves the resulting opportunity profile before any outreach is sent.
• Venture composition — Inexis Digital doesn’t contain this logic; it composes the engine, the pack, and the outreach agent into a lead-generation wedge.

If you understand this one journey, you understand the architecture. It is composed from four repositories (inexisstudios engine + intelproducts pack + FIP authoring + the evaluation lab) — the detail is in the capability digest.

The Current State

Everything above is the design. Everything below is how far it is built today — it evolves, and is labelled honestly. Live operational numbers come straight from the deterministic Portfolio Health engine and the Status Dashboard.

Repositories

Nine repositories realise the layers. This is a summary — the authoritative index is the Repository Registry, and each row links to its digest.

The ventures themselves (Inexis Digital, Consulting, Inbound Lanka, City Retreats) are real businesses but are not yet registered as repositories — they appear in the model as Layer 5 composition points, not code.

Maturity today

Maturity is mixed and labelled honestly (Principle 8) — the foundations are real, the upper layers are partial or planned.

• Real foundations. Shared Skills is operational (it built this portal). Intelligence Products work as a contract — packs are published and already consumed by downstream apps.
• Partial platform. The Founder Intelligence Platform is design-complete with a built Phase-0 foundation and a working dashboard; the Website Intelligence Lab has live infrastructure with its core evaluation loop still pending.
• Honest gaps. Named-but-unbuilt elements — the Hermes learning loop and OpenClaw integration — are marked planned; one requested concept, “estate generation,” does not exist and is recorded as such rather than invented.

The full per-system maturity table and rationale live on the Status Dashboard; computed health scores are in Portfolio Health.

Technology landscape

Architecturally, the stack is markdown-native intelligence (skills, packs, and the knowledge estate are all markdown) running on Anthropic Claude for AI, Supabase/Postgres for the platform’s canonical store, a TanStack/React application tier, and Cloudflare (Workers, Pages, D1, R2) for edge and infrastructure. The choices are evidenced, not aspirational. The full technology inventory with per-item evidence is on the Technologies page.

Strategic direction

The next 6–12 months are about building upward — completing the layers whose foundations already exist:

• Complete the platform loop — build FIP’s capture-to-retrieval phases and the lab’s evaluation loop.
• Grow the products — expand pack domains; add the Hermes learning loop once outcome data exists.
• Harden the applications — mature leadplatform and outreachagent into reliable revenue engines.
• Automate the portal — implement the portfolio-portal-orchestrator so the portal maintains itself.

The detailed roadmap is on the Roadmap page. For how the portal itself was built, see Portal Evolution.

The idea

Strip away the repositories and the maturity labels, and one idea remains.

Knowledge compounds. It is captured once and reused everywhere. Capabilities compound — separated from applications, they serve many. Intelligence compounds — published as versioned products, it improves for every consumer at once. And so ventures stop being applications and become compositions — assembled from a shared, improving base rather than rebuilt from nothing.

That is what makes this different from a collection of AI projects. A collection grows by addition; this grows by multiplication. The architecture is not a diagram of the system — the architecture is the operating model.

Go deeper: the guided Architecture Story walks this reasoning chapter by chapter; the Intelligence Platform architecture and the system-of-systems architecture give the full technical picture; and the Architecture Principles govern it all.