one·engine

The claim

Not four applications wired together. A composable intelligence architecture: independent domain engines join into a unified system through a single contract, and the unified system exposes that same contract, so it can become a capability inside something larger. Composition is recursive by construction, not by special case.

        research + software + university + web
                          ↓
                 UNIFIED INTELLIGENCE          ← speaks the contract
                          ↓
                     CAPABILITY                ← consumed by URL, opaquely
                          ↓
                    HIGHER SYSTEM              ← speaks the same contract
                          ↓
                       BEYOND

The four engines stay four engines

Each keeps its own codebase, agents, Parallel integration, Context Graph, Knowledge Graph, and DataHub platform. Not one line of those four repositories was modified, and nothing was installed into their environments — each adapter runs inside its engine's own venv and calls its existing front door.

The keystone

# the unified system holds four of these
CompositeEngine(members={"research": RemoteEngine("http://localhost:9101"), ...})

# a second-level system holds ONE of these, and cannot tell the difference
CompositeEngine(members={"unified": RemoteEngine("http://localhost:9100")})

If recursion needed a different mechanism one level up, the claim would be false. Ask the second-level system who it is, and it answers all the way down — through a single contract call:

meta-studio          composite
 └── one-engine      composite
      ├── research-engine   leaf
      ├── code-engine       leaf
      ├── learn-engine      leaf
      └── design-engine     leaf

Four layers, four owners

Temporal is never the knowledge graph; DataHub is never the workflow state. That separation is enforced by packaging: temporalio is an optional extra only the unified system installs, so an engine cannot import it.

Federation, not flattening

Each engine keeps publishing to its own DataHub platform. The federation adds one platform that owns only the cross-domain claims — and takes its lineage upstreams from datasets the engines emitted themselves, so a single composed run renders as one connected graph spanning five platforms.

concept.<slug>          cross-domain identity — every domain's name for one subject
stage.<obj>.<n>-<eng>   one member execution  — upstreams: that engine's OWN datasets
objective.<obj>         the composed run      — upstreams: every stage + the concept

The engines propose; the scaffold decides

Federation gave the system memory and Temporal gave it durability. Neither gave it judgment — and the first real run showed the cost: the software engine honestly reported a failing test suite, and the pipeline generated a public website for that software anyway. Nobody had decided whether that was acceptable.

A composition gate is a pure function from a stage's contract result to a verdict. It declares how it judged, honestly:

Verification is HUMAN on purpose: whether the suite is red is a hard fact the gate settles; whether to ship anyway is a judgment a person makes. Gates read only the contract, so they add decision without adding coupling — and they run inside the workflow, so the decision is the orchestrator's and lands in durable history. Every verdict is published as an event and as a DataHub dataset downstream of the stage it judged.

Events describe; they never command

ResearchCompleted, CurriculumCreated, SoftwareBuilt, SiteGenerated — past-tense facts about state changes. No event tells another engine what to do, and ingesting one provably executes nothing. That restraint is what keeps the engines autonomous while the system behaves as one.

It evolves, and it does less on purpose

The system is not limited to one-time generation. Asked to re-evaluate a subject, it researches what changed, then reads its own history to work out what it already built — and skips every stage whose domain has nothing to update. Each skip records its reason rather than leaving a hole.

new information about X
        ↓
research                    what has changed about X?
        ↓
impact analysis             what has this system already made for X?
        ↓
curriculum · software · web only where something exists to update

Impact reads the composite's own stage narration rather than each engine's private event vocabulary — so an engine that joins later becomes legible to it by naming its outputs conventionally, with no table to update anywhere.

Degradation is honest

Health reads ok only when the system can actually deliver what the architecture promises — not merely when its servers are running.

Run it

./scripts/up.sh

curl -X POST http://localhost:9100/objectives \
  -H 'content-type: application/json' \
  -d '{"inputs":{"topic":"WebGPU compute shaders"}}'

Research runs; its discoveries shape the curriculum; the curriculum's learning order shapes the software request; the software's product name shapes the web brief. Then it all lands in DataHub as one connected graph.