AI Infrastructure Architecture & Responsibility Map

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

One request · explicit handoffs · evidence returned

The route changes with the work. The identity, contracts, and return path stay explicit.

Only the layers a request needs have to run. This view shows the complete path so every boundary can be inspected.

result + evidence return to the work surface

Your request and the context you choose to share

Objective, sources, policy, and accountable owner

Pinned context, constraints, and declared output

A useful result with the reasons and sources that support it

Decision-ready output, owner, approvals, and record

Typed output, weave trace, permits, and execution receipt

The products do not hide what they depend on

Only relationships asserted by the current product and open-source pages are drawn here. Absence from this ledger is not a claim that a foundation is unused.

Inside the product or a real dependency of it.

A supported integration, not an internal dependency.

Foundations with no product edge asserted in this view

Numerus, Signum, and Selvedge remain part of the 14 open-source routes. This ledger does not invent a product relationship where the current pages do not make one.

The route may shorten. The thread must not break.

The answer should never become detached from the request.

Your question remains the thread through the run.

Each handoff says what moves and what stays private.

The result comes back with reasons and sources.

The objective, owner, and source set retain one identity.

Policy and approval gates remain named at every handoff.

The result returns with evidence, decisions, and ownership.

Contracts preserve identity across replaceable components.

The request ID and pinned inputs follow every derived artifact.

Typed handoffs expose policy, execution, and placement decisions.

Trace and receipts join the typed result at the caller.

The stack is easiest to understand as a journey. A question enters once, crosses only the boundaries it needs, and comes back with a result you can inspect. The labels keep product, foundation and research status separate before you choose a route.

The named stages show who owns knowledge, reasoning, action, compute and placement, so at every step you can see which owner answers and where the question stops if the later stages are never needed.

A request crosses only the boundaries it needs, so the full route is a map of what can happen rather than a promise that every product runs on every question, and the product, foundation and research labels stay separate as you read it.

The stack is one accountable operating path, not a catalogue of disconnected tools. An objective enters with its owner, sources, and policy, then returns as a result with evidence. That separation keeps the commercial scope legible while the route remains flexible.

Each product owns a distinct responsibility, so a team can adopt the layer that matches its operating need without taking on the whole path, and the boundary it buys stays legible in the commercial scope.

Only the required layers run, and explicit handoffs keep approvals, sources and execution records attached to the original objective, so the evidence returns with the result instead of being reassembled afterwards.

Read the architecture as a request path. Typed input becomes governed context, a traceable result, an authorised plan, an executable plan, and a placement receipt. The route is descriptive: it records contracts and evidence, not a mandatory call graph.

Named contracts keep components replaceable without hiding what each handoff accepts or emits, so a substitution stays reviewable and the schema at the boundary remains the thing actually under review.

A route can skip unneeded responsibilities while preserving request identity, pinned inputs, permits and the return trace, so a shorter path is still a fully accounted one and every crossing it does make stays typed.

You can start with one product. When a request needs more, the products pass it forward without losing the question, sources, or record.

The eight-product suite spans the work surface, knowledge, reasoning, governed action, compute, and placement. Each one owns a single part of the request, so you can start with the part you recognise and add the rest only when a request actually needs it.

Kera is a separate systems foundation, selected only when that graph-native route is the right fit. It is not a ninth part of the suite, so you can read the eight products as one set and treat Kera as the route underneath, chosen for its own reasons.

Buy for the responsibility you need first. The suite can then connect work, governed knowledge, reasoning, coordination, compute, and placement without turning one operation into eight projects.

The eight suite products can operate as one system, with each product carrying a named commercial responsibility. Buy the responsibility you need first and connect the rest later, so a first purchase stays scoped to one named owner rather than to the whole suite.

Kera remains a separate systems language and toolchain, rather than a ninth component in the suite. It is selected when that graph-native route fits, and it is never a required step, so the licensed suite still counts eight products and nothing more.

The products divide responsibility without hiding the handoffs. Start at any contract boundary, adopt the components you need, and keep the caller-facing result inspectable.

The suite spans interface, knowledge, cognition, coordination, compute, and placement through named contracts. Each boundary is typed, so a component can be replaced without rewriting its neighbours.

Kera is a separate graph-native systems language and toolchain that participates only when selected. The request path does not require it, so the eight contracts hold without it and a route can be read end to end from the suite alone.

A useful demonstration should show more than the answer. Follow the request through the work it needs, then inspect the record returned with the result. The map below traces one request from the moment it is asked to the moment it comes back, naming what it read, what it decided, and what it left behind.

The demonstration below follows one concrete run from request to result, so the visible artefacts have a clear origin.

This wider map shows where sources, decisions, execution, and evidence sit around that run.

Do not judge the system from a polished answer alone. Follow the objective, owner, sources, policy, approvals, execution, and evidence as one accountable run. Each stage leaves an artefact you can name and an owner you can ask, and the map below shows where each one sits on the route your own request would take.

The concrete demonstration zooms in on a single accountable route, with each artefact tied to the responsibility that produced it.

Use the wider map to check what should return to the operating record and who owns that handoff.

A demo is only useful when the boundary artifacts are visible. Follow the typed request through context, trace, permits, execution, and placement, then reproduce the returned evidence. Each boundary below names what the component accepted, what it emitted, and what it preserved, so the pack replays against the same route.

The run below is the concrete test: inspect what each component accepted, emitted, and preserved at its boundary.

The route is the reference model for reproducing the returned trace, permits, execution, and placement evidence.

A question should not disappear into a black box. It should come back as a useful answer with a record you can understand.

The route shows where knowledge, reasoning, action, and execution fit around your question.

Most requests use only part of it, so the map explains the shape without prescribing a fixed journey.

Start with an objective, its owner, sources, and policy. The stack coordinates the responsibilities it needs and returns the result, approvals, evidence, and record to the work surface.

Each product can stand on its own, with a responsibility that remains clear when the operating path grows. An objective, its owner, its sources, and its policy are named at the start rather than assembled later.

Together, explicit handoffs extend one path without rebuilding identity, governance, or evidence at every layer. The result, approvals, evidence, and record come back to the same work surface the request left from.

A typed request carries pinned context through governed knowledge, woven cognition, authorised coordination, compute, and placement. The caller gets the result and the evidence chain together.

The architecture is composable rather than mandatory end to end; only the required responsibilities run. A typed request carries its pinned context into knowledge, cognition, coordination, compute, and placement only where those are needed.

Their contracts preserve request identity, declared boundaries, and reproducible return artefacts for the caller. The result and the evidence chain arrive together, so the caller does not have to reassemble one from the other.

Each product declares the provider contracts it consumes. Provider implementations never import their consumers.