Architecture & Docs Governance
Document the system of systems and govern its architecture: repository digests, capability architecture,
This is not a list of projects. It is one architecture — a system of systems — designed so that reusable intelligence compounds from a shared foundation up to the ventures that serve customers. Follow the ten chapters below to understand not just what was built, but why it is shaped this way. Every claim is grounded in the portal's documented evidence.
Begin the journey ↓A founder operating several ventures accumulates intelligence constantly — from client projects, research, and operational experiments. The platform's own design records the core problem plainly: without structure, that intelligence is “locked inside documents that are hard to query, easy to forget, and inaccessible to AI assistants.”
Left unaddressed, that problem shows up in six concrete ways — each one documented across this portal:
Scattered across repositories, docs, and tools; no single connected view.
Assistants can't see the whole system, so each conversation starts cold.
The same competence is rebuilt per project instead of reused.
Reusable intelligence buried inside one venture's codebase.
Design decisions spread across many places, hard to reason about.
Insights die unprocessed; the organisation forgets what it learned.
graph LR
subgraph Without["Independent AI projects"]
A[Repo A]:::iso
B[Repo B]:::iso
D[Docs]:::iso
C["AI chat<br/>(context lost)"]:::iso
K[Knowledge<br/>trapped]:::iso
end
Without --> Q["Hard to query · easy to forget · can't compound"]
classDef iso fill:#eef0f4,stroke:#c9cdda,stroke-dasharray:4 3,color:#333;The answer is not another app. It is an architecture where competence is built once and reused everywhere — so improving one thing at the base multiplies value across everything above it.
The ecosystem is deliberately organised around six architectural commitments:
graph TD F[Shared foundation<br/>reusable capability] --> I[Structured intelligence] I --> P[Versioned products] P --> S[Platform services] S --> V[Modular ventures] V --> C[Customer value] G["Governance + deterministic core"]:::g -.governs.-> I & P & S & V classDef g fill:#eceefe,stroke:#8079ff,color:#333;
The ecosystem is a stack. Each layer consumes the one below and serves the one above; the shared foundation is consumed laterally by all. Open any layer to see the real systems inside it.
graph TD L6["6 · Customer Experiences"]:::v --> OUT((Customers)) L5["5 · Ventures"]:::v --> L6 L4b["4 · Platform Services · proposed"]:::p --> L5 L4["4 · Applications & Agents"]:::r --> L5 L3["3 · Intelligence Products"]:::r --> L4 L2["2 · Intelligence Platform"]:::r --> L3 L1["1 · Shared Skills"]:::ok --> L2 L1 -. reusable capability .-> L2 & L3 & L4 L4 -.-> L4b classDef ok fill:#e6f4ea,stroke:#1f7a3d,color:#333; classDef r fill:#fbf0d3,stroke:#9a6700,color:#333; classDef p fill:#eceefe,stroke:#8079ff,stroke-dasharray:4 3,color:#333; classDef v fill:#eef0f4,stroke:#c9cdda,color:#333;
Each realised layer, its responsibility, and what it exchanges:
| Layer | Purpose | Inputs | Outputs | Consumers |
|---|---|---|---|---|
| Shared Skills | Reusable AI competence | Intent | Invoked capability | Every layer |
| Intelligence Platform | Turn knowledge into structured intelligence | Knowledge, signals | Knowledge assets | Products |
| Intelligence Products | Publish versioned packs | Approved intelligence | Immutable packs | Apps & agents |
| Applications & Agents | Act on intelligence | Packs + evidence | Assessments, outreach, briefs | Ventures |
| Platform Services proposed | Reusable services across ventures | — | — | Ventures |
| Ventures / Customer | Deliver outcomes | App output | Customer value | The market |
Follow one thread all the way up. Raw knowledge is progressively refined — extracted, structured, productised — until an application turns it into something a customer receives.
graph LR K[Knowledge] --> E[Extraction] E --> S[Structuring] S --> I[Intelligence] I --> P[Products] P --> A[Applications] A --> O[Customer outcomes] O -. feedback · planned .-> I classDef d fill:#e6f4ea,stroke:#1f7a3d,color:#333; class K,E,S,I,P,A,O d;
Feedback from outcomes is designed to return into the platform as new intelligence — a loop that is planned, not yet built.
Beneath the technologies, the same design decisions appear again and again. These patterns — not any single tool — are what make the ecosystem coherent.
Reusable capabilities are documented and owned independently of the repositories that implement them, so the same capability can serve many ventures.
Intelligence is published once as versioned, immutable packs that consumers pin — not re-implemented per app.
Rules decide and score; an LLM only explains the result from structured facts. It never forms the opinion.
Cross-venture capabilities are meant to live as services, not be trapped inside a single venture repo.
Documentation records what the evidence supports; unknowns are labelled, never invented. Health is computed, not estimated.
No knowledge asset becomes canonical, and nothing customer-facing is sent, without a human decision.
These are the ecosystem's reusable building blocks — documented independently of the repositories that implement them, so each can serve many ventures at once.
Document the system of systems and govern its architecture: repository digests, capability architecture,
Turn a website assessment into a Commercial Opportunity Profile (COP) — a structured decision on whether a
Package the platform's intelligence into versioned, immutable, machine-consumable packs that downstream
Turn a multi-venture founder's scattered knowledge into a queryable, AI-accessible, scoped asset library:
Provide an immutable, fully-provenanced experiment & benchmark harness so engines (assessment, migration,
Package domain expertise into modular, invocable Agent Skills so competence is built once and reused
Assess a service business's website — crawl it, score it against an industry intelligence pack, and
The architecture is easiest to grasp by watching real capabilities travel through the layers. Here are three — each crossing several layers on its way to value.
graph LR KA["Intelligence Platform<br/>industry knowledge"] --> PK["Products<br/>assessment pack"] PK --> ENG["Applications<br/>assessment engine (crawl → score)"] ENG --> COP["Applications<br/>Commercial Opportunity Profile"] COP --> OUT["Venture<br/>Inexis Digital outreach"] classDef d fill:#e6f4ea,stroke:#1f7a3d,color:#333; class KA,PK,ENG,COP,OUT d;
Industry knowledge becomes a versioned pack; the engine applies it to a real website and scores it deterministically; the result becomes a structured opportunity profile; a human approves before any outreach. Rules decide, AI explains, a human sends.
graph LR
SRC["Knowledge estate"] --> CAP["Capture"]
CAP --> REV{"Human review"}
REV -->|approve| ASSET["Knowledge assets<br/>scoped · maturity-gated"]
ASSET --> RET["Retrieval / products"]
classDef d fill:#e6f4ea,stroke:#1f7a3d,color:#333; class SRC,CAP,ASSET,RET d;graph LR PACK["Products<br/>proposal pack"] --> SKILL["Shared Skills<br/>proposal-generator"] SKILL --> APP["Applications<br/>leadplatform / outreach"] APP --> DRAFT["Draft proposal<br/>(human reviews)"] classDef d fill:#e6f4ea,stroke:#1f7a3d,color:#333; class PACK,SKILL,APP,DRAFT d;
The founder operates several venture areas — Inexis Digital, Inexis Consulting, Inbound Lanka, City Retreats, and cross-cutting work. Crucially, they are not independent software products: each is a composition of the same reusable capabilities.
graph TD CAP1["Reusable AI Skills"]:::c --> V1["Inexis Digital"] CAP2["Website Assessment"]:::c --> V1 CAP3["Intelligence Productization"]:::c --> V1 CAP1 --> V2["Inexis Consulting"] CAP3 --> V2 CAP1 --> V3["Inbound Lanka"] CAP4["Knowledge Intelligence"]:::c --> V1 & V2 & V3 classDef c fill:#e6f4ea,stroke:#1f7a3d,color:#333;
Because capabilities are shared, a new venture is closer to a composition than a fresh build — which is exactly why multiple ventures can exist without duplicating architecture. The systems that realise this today:
the Intelligence Platform (L2) produces intelligence and Intelligence Products (L3) publish it, this layer
reusable, versioned intelligence. It is not a single repository but an assembly of sibling systems, plus
The Shared Skills layer is the foundational capability layer of the ecosystem: a single curated
Technologies are chosen for the architectural job they do, not for their own sake. Grouped by responsibility, the choices tell a consistent story: static-first, deterministic-first, contract-driven.
The graph and the deterministic Health engine are the foundation for more. What follows is labelled honestly — implemented, in progress, or planned — and no planned capability is presented as built.
Future Portfolio Intelligence and Hermes will interpret the deterministic outputs you have just toured — not replace them. That is the whole point of building the model first.
That's the architecture — one coherent system, not a collection of projects.