Skip to content

Middle-Core Charter

What team middle-core is for, in one page.

Mission

Middle-core is the provider-neutral semantic and governance layer of the platform. It lets humans and machine agents ask for meaningful platform activities — land knowledge, query the graph, route work, prove work is done, promote MCP tools — without touching provider internals (ArcadeDB, GitHub, backend-core). Meaning, lifecycle, and evidence live here; raw provider mechanics do not.

How it works

Middle-core is a model-driven generative runtime, not a hand-written CRUD service — the engine behind the AgentArmyX Labs north-star "One Model, Many Projections." One governed model is the single source of truth, and code is compiled from it:

model specs -> deterministic generator -> generated contracts -> in-memory object graph -> scenario runtime -> evidence
  • Model — model/middle-core/model.yaml (schema middle-core-model.v1) plus a UFO/gUFO-lite OWL ontology, a BPMN workflow, a DMN decision, and an ArcadeDB projection spec. YAML is authoritative in v1; the rest are referenced and verified.
  • Generator — tools/modelgen/ (Python) emits disposable contracts into templates/middle-core/generated/: object IDs, canonical data records, state-machine contracts + enums + a runtime enforcement API, workflow/scenario/projection contracts, a model validator, plus SHACL/OWL/RDF/JSON fixtures.
  • Runtime — hand-authored C# in templates/middle-core/Runtime/ consumes the generated IDs to execute scenarios over an in-memory graph and emit evidence.

The boundary rule: generate stable plumbing (IDs, DTOs, contracts, validators); never generate business behavior. Lifecycle transitions, redaction, and tool-promotion decisions stay hand-authored.

What the layer owns

Concern Owner
Provider capabilities, ArcadeDB operations, raw storage backend-core
Business-object meaning, lifecycle policy, scenario contracts, MCP eligibility middle-core
UI cards / read models middle-core projection, rendered by frontend-core

Governance is the point — evidence is a primitive: state machines are first-class ontology commitments, "done" is derived from evidence packs (not vibes), decision records explain every routing/waiver/promotion, and MCP tool exposure is gated on recent capability evidence. Everything traces actor -> goal -> use case -> activity -> business object -> data object -> provider projection -> evidence across 16 use cases (UC-01–UC-16).

Current state

Prototype ADR. The model defines 9 object types, 9 state machines, 1 scenario (knowledge-drop), 4 workflow steps, 2 projections, and generates C# only today, behind an L3 verification chain: Python validation → SHACL (pySHACL) → OWL consistency → C# build/tests → Playwright UI smoke.

Roadmap

The same governed model, more emit targets next:

  • JavaScript — toward frontend-core.
  • dlt (data load tool) pipelines — model-driven ingestion.

The generator is built as a reusable harness intended to later target backend-core and frontend-core too. The Labs north-star pushes this further still — "Skills as a Projection," where the agent roster and skills are themselves generated from the model. Further slices: parse BPMN/DMN directly, ArcadeDB projection ports, temporal snapshots, OntoUML/OLED model checking, and gated MCP tool promotion.

Lineage

Middle-core sits at the downstream end of the AgentArmyX Labs flow — "Think here. Share in the wiki. Commit on the board. Publish in the docs." Concepts incubate in the Labs vault, graduate into the ArcadeDB schema and OpenAPI contract owned by backend-core, and are projected here into typed, governed runtime contracts.