Home / Glossary

Glossary

The shared vocabulary for orchestrata-ultimate and this wiki. Four parts: orchestrata terms for newcomers (start here; each term links to its page), the longer project vocabulary, the operational KG schema (the orchkg database), and the semantic/wiki graph schema (the memgraph database). Authoritative sources: knowledge_graph/canonical_schema.py (SPEC-106 FR-001) for the operational KG, graph-indexer/memgraph_client.py for the wiki graph. The whole system is explained in Orchestrata, explained.

Orchestrata terms for newcomers

Alphabetical. Facts are as of 2026-10-23 and cite their source.

• ADR (architecture decision record) — an append-only record of a one-way-door decision, in the repo's docs/adr/NNNN-title.md (105 files at 478d9a0ef), with status Proposed, Accepted or Superseded. Never edited once accepted; superseded instead. See Decisions and Open decisions.
• AST snapshot — the JSON serialization of the source tree that the AST toolkit queries (default warm cache plans/ast-ultimate.json, roots declared in env/ast-roots.env). It also feeds the Prolog gate layer and the orchkg code-intelligence sync. See Overview §5.
• AST toolkit — serialize_codebase_ast.py and its daemon, deployed under /opt/orchestrata-tools; the only sanctioned way to read Python structure and source in this project. See Overview §7.
• Brief — the written task a worker model builds from, kept in plans/briefs/. It must carry the labels GOAL:, FILES:, CONSTRAINTS:, DONE WHEN: and VERIFY: (plus a DESIGN_WAIVER: line for builder agents), per plans/briefs/TEMPLATE-sonnet-agent.md. See Briefs and the dispatch ledger.
• codetools — a separate code-tooling project (~/workspace/orchestrata.codetools, deployed at /opt/codetools) offered as a CLI, an MCP server and a Claude plugin; codetools ast map writes the codebase maps. Host-side orchestrata scripts are moving into it (ADR-0117, ADR-0118). See codetools.
• Components — the ten packages the monolith is being re-cut into under packages/: contracts, governance, knowledge_graph, kernel, session, volks, gateway, tools, integration (import name orchestrata) and plugin. The cut-over has not happened (ADR-0113). See Component DAG.
• CXP (Cross-agent eXchange Protocol) — the packet format every hop speaks (SPEC-004): CXPPacket, a flat packet with eleven core fields (message_id, from_agent, to_agent, thread_id, subject, payload, timestamp, priority, delivery_status, work_status, protocol_version). See cxp.
• cxpt — the native direct transport that carries CXP between gateway and kernel. It replaced the grpc.aio transport on 2026-08-07; CXP_TRANSPORT=cxpt in the profiles, and some names still say "gRPC". See gRPC retirement.
• Definition of Done — every spec packet ships with @traces, a regenerated RTM, documentation, a wiki update and at least 90% coverage (ADR-0069). See RUL-034.
• Factory — the factory package: SPEC-033's governed autonomous build factory (assumption ledgers, semantic anchors, red-first evidence, mutation testing, a DAG scheduler and merge queue). ADRs 0001 to 0033 are its decision register. See factory.
• Fleet — one of the three isolated Incus environments: prod (project default, 10.53.1.0/24), test (orchestrata-test, 10.53.2.0/24) and dev (orchestrata-dev, 10.53.3.0/24). See Isolated test fleet and Overview §6.
• Gate — a mechanical check with a command, a failure behaviour and no discretion: the battery in scripts/gates.py, the suite preflight, the session hooks and the Prolog gate layer scripts/gate.py. See Gates.
• Gateway — the single runtime ingress: WebSocketGateway, WebSocket JSON-RPC 2.0 on GATEWAY_PORT 8765 with HTTP on 8766, JWT auth by default (JWT_SECRET, TOKEN_EXPIRY_SECONDS default 3600), about 80 RPC methods (SPEC-014). See gateway.
• Governance — the policy layer: the governance package plus the Prolog rule files in src/orchestrata_ultimate/prolog/, consulted in-process before work runs (may_execute/2). Denials carry a reason; explain.pl gives proof trees. See governance and Governed action classification.
• Hermes — the Nous Research Hermes agent, deployed at /opt/hermes at a pinned commit and used as a non-Claude worker (DeepSeek or OpenRouter models) through the hermes MCP server; it reports answered_by, fell_back and cost_usd per run (ADR-0121). See Overview §7.
• Intent — a natural-language request from a person. The gateway parses it and either asks for clarification or sends it to the concierge volk as a CXP packet with subject intent; the kernel gates it through the intent broker and runs it in the PipelineRunner. See Overview §4 and orchestrator.
• INT-01..25 — the increments of the integration package, the composed release; INT-01 (spec delta and release scaffold) has landed, INT-02 to INT-25 have not (2026-10-23). See Overview §10.
• kg — Mohamed's alias for the operational knowledge graph, orchkg on the prod orchgraph cluster (ADR-0126 provenance). See orchkg.
• Kernel — the agent runtime process, python -m orchestrata_ultimate.agents.runtime_main, serving CXP on CXP_GRPC_PORT 50053 over cxpt; it runs the PipelineRunner, the Postman, the volks and embedded Prolog. Required for every authoritative test run. See kernel.
• memgraph (database) — the semantic / RAG database on the orchgraph cluster: embedded chunks of code, docs and specs. Not to be confused with orchkg. See Semantic graph.
• orchestrata-mcp — the orchestrata MCP server (/opt/orchestrata/.venv/bin/orchestrata-mcp), a WebSocket JSON-RPC client of the running gateway; every method is approval-gated unless marked read-only (ADR-0099). See gateway.
• orchestrata-tools — two things share the name. (1) The deployed developer tools at /opt/orchestrata-tools (ast, ast-daemon, ast_live_sync, codemod-daemon, observe_pytest, pytest-live, ship, swarm_supervisor; ADR-0067). (2) The component package packages/tools, import name orchestrata_tools (ADR-0107). See Overview §7 and the tools component reference.
• orchgraph — the Memgraph-fork Raft HA cluster in prod (project default): coordinators orchgraph-coord-1..3 (10.53.1.160/.109/.198, routing :7691) and data instances orchgraph-data-1..2 (10.53.1.128/.123). It hosts both orchkg and memgraph. See KG migration to orchgraph.
• orchkg — the operational knowledge graph database on orchgraph since 2026-07-26: code structure, specs, requirements and TRACES_TO, sessions, CXP packets, gateway audit, conversations, the component DAG. See KG migration to orchgraph and knowledge_graph.
• pi-worker / pi-task — pi-task at /opt/pi-worker: one task, one fresh Incus container (project pi-workers), a judge in a second container, and an accepted result returned as a branch pi/<task>, never merged automatically. See pi-harness.
• Postman — the message router (postman, alias U:PS): queues, topics, subscriptions, receipts, replay. Volks register with it and the pipeline routes packets through it. See postman.
• Profile — ORCHESTRATA_ENV_PROFILE (default test) selects env/dev.env, env/test.env or env/prod.env, endpoint-only files layered over a secrets-only .env; the test suite is hard-pinned to test. See Overview §6.
• Prolog KB — the Prolog knowledge bases: the governance rule files (29 .pl files in src/orchestrata_ultimate/prolog/ at 8a2cb42ad) plus the ground facts callers assert for each question, and the code-intelligence knowledge base the code_intel, trace_intel and history_intel tools query. Prolog is a stateless reasoning view; the graph is the sole fact store (ADR-0005). See The Prolog layer does not learn and the Prolog atlas.
• RTM (requirements traceability matrix) — the join of requirement ids to the code and tests that cite them, graded by evidence: TESTED, FAILING, CITED, DECLARED or UNLINKED (scripts/generate_rtm_evidence.py). See RTM.
• RUL (ruling) — a standing user ruling, RUL-001 to RUL-041, each tied to an enforcement mechanism. See the rulings canon.
• Session — a unit of tracked work: the session package, the session CLI and its per-project context.json, the gateway's session.* methods and Session nodes in orchkg. See session and Sessions.
• Spec — an authoritative requirement document, specs/NNN-name/spec.md with checklists/requirements.md; 79 tracked entries in specs/, 71 of them numbered spec directories. See Specs.
• Volk — one agent role. Eleven are registered at 8a2cb42ad: U:Cx concierge, U:BA analyst, U:PM, U:Ux, U:Ar architect, U:Cd code director, J:Junior, U:SD senior developer, U:Qa, U:Cp compliance, U:Do documentor. Every intent goes to the concierge first. See The volks.
• Worker model — the model that writes orchestrata code under ADR-0125: Sonnet subagents, or Qwen and DeepSeek through Hermes and pi-task; the host Claude writes briefs, checks and workflow only. See RUL-041.

Project vocabulary

• orchestrata-ultimate — the single-package port (~122K LOC) of the 26-package orchestrata monorepo. Python 3.14 free-threaded, uv-managed, absolute imports only. The port itself is complete; work is now maintenance, tooling, and capability build-out.
• Volk — an agent role in the multi-agent system (from German "folk"). Eleven exist: analyst (U:BA), architect (U:Ar), codedirector (U:Cd), compliance (U:Cp), concierge (U:Cx), documentor (U:Do), junior (J:Junior), pm (U:PM), qa (U:Qa), senior_dev, ux (U:Ux). Each has a system prompt, tools, and handoff rules; BaseAgent is the shared base class.
• Kernel — the Agent Runtime coordination engine (kernel/, agents/runtime_main.py, CXP over the cxpt transport on CXP_GRPC_PORT/50053; gRPC was retired 2026-08-07). REQUIRED infra for every test-suite run — a run that skips it is invalid/false-green.
• CXP (Cross-agent eXchange Protocol) — the typed packet protocol agents use to talk to each other (cxp/): packets, headers, routing, priorities, delivery guarantees; the cxpt direct transport between processes, with WebSocket and HTTP dispatch paths in kernel/dispatcher.py.
• Postman (U:PS) — the message routing/delivery engine (postman/): queues, topics, subscriptions, receipts, replay, circuit breakers.
• Orchestrator (U:Ox) — the governance/policy management engine (orchestrator/): intent parsing/classification/routing, the PipelineRunner, fact stores, impact analysis.
• Intent — a parsed user request routed to a pipeline: classified, validated (Prolog), secured, then executed as a PipelineRun.
• Pipeline / PipelineRunner — the staged execution of an intent across volks (e.g. review work type: QA → Cp), with retry classification, checkpoints, escalation-as-data, and KG absorption.
• Gateway — the WebSocket surface (SPEC-014, gateway/): RPC dispatch, pub/sub, auth, ring buffers, the PolicyGate, and the UI (VizInt) bridge.
• Governance / PAM — the Prolog-backed policy layer (governance/, prolog/*.pl): may_execute/2, constitutional articles, ethical checks, escalation, safe mode. Strict mode (ORCHESTRATA_GOVERNANCE_STRICT, default fail-closed) turns evaluation errors into denies.
• Prolog engine (janus, free-threaded) — SWI-Prolog embedded via a PATCHED janus-swi (scripts/_janus_patched) that runs with the GIL genuinely off on 3.14t. Never revert to stock janus/grpcio. Rules live in .pl files (consulted); only GROUND facts are assertz'd.
• Harness — the scenario-driven volk evaluation system (harness/): YAML scenarios, evaluators (syntax/lint/file/llm-judge/trace), Incus isolation, healing, history.
• Spec / SPEC-NNN — the authoritative requirement documents (specs/000..106). Specs override tests and opinions: design/contract questions are resolved from specs first.
• Requirement / RequirementItem — a spec's user-story-level requirement and its checklist items (the REQ-NNN-... ids). Code claims coverage via @traces; the graph links code to RequirementItem via TRACES_TO.
• @traces — the decorator (core/base/traces.py) @traces(spec=..., story=..., reqs=[...]) that declares which requirements a class/function/method implements. Harvested by core/tracing/scanner.py; synced to the KG by scripts/sync_traces_to_graph.py (formerly sync_traces_to_neo4j.py).
• RTM (Requirements Traceability Matrix) — the spec↔code↔test coverage matrix. The honest form is the evidence-graded RTM (scripts/generate_rtm_evidence.py: TESTED / FAILING / CITED / DECLARED / UNLINKED, per its docstring at 8a2cb42ad); the legacy docs/rtm.md "100% coverage" is fiction slated for retirement.
• Runtime attribution — deriving (code → requirement) evidence from which code actually executes under a requirement's citing tests (per-test coverage contexts, COVERAGE_CORE=ctrace mandatory). Plan: plans/bdd-runtime-tracing-plan.md.
• Context pack (SPEC-106) — the deterministic, budgeted context brief built for agent tasks: frame (entity linking on name/qualified_name) → selector (per-TaskType template expansion over the KG) → packer (budgeted markdown with provenance). Surfaced by ContextInjector.
• AST toolkit — scripts/serialize_codebase_ast.py: the house tool for structure questions and refactors (symbols/refs/rename/check-deps/ standards/gen-*). Used instead of grep/sed for structure.
• Session CLI — per-project work tracking (context.json) via session begin/work/artifact/choice/achievement/handoff/end. Never hand-edit context.json.
• Knowledge wiki — this wiki: durable cross-agent knowledge, indexed into the Memgraph graph (wiki-kimi index) and embedded for RAG (wiki-rag-ingest / wiki-rag-query, codestral-embed-2505 + cohere/rerank-4-pro with RRF fusion).
• Incus fleet — the container infrastructure (NOT docker/localhost), three isolated projects. Prod (default, 10.53.1.x, measured 2026-10-23): redis-queue .10, the orchgraph cluster (coordinators .160/.109/.198, data .128/.123, routing .160:7691), prometheus-metrics .40. The Neo4j nodes were deleted 2026-07-26 and the prod Prolog containers retired by ADR-0110. Test is 10.53.2.x, dev 10.53.3.x. Terraform-managed (ADR-0077).
• The two graphs — #1 source of confusion: orchkg is the OPERATIONAL KG (sessions, audit, code intelligence, specs, traces); memgraph is the SHARED SEMANTIC/RAG graph (wiki pages + code chunks + architecture twin). Since 2026-07-26 both are databases on the same orchgraph cluster, isolated by database name. Never conflate them.
• Ruling 2 (canonical ids) — code-node identity is {project}:{qualified_name} (e.g. orchestrata-ultimate:knowledge_graph.search.SearchEngine); spec-tier ids are {project}:{natural id}. Entity linking joins on name/ qualified_name PROPERTIES, never by parsing id strings.
• Test standards — no mocks/stubs/fakes/monkeypatch/skips/xdist; real infra; function-scope fixtures; test_id-scoped data; live-observer runs only; kernel required. Enforced by audit_test_purity, test-review (T-rules), isolation audit, and PreToolUse hooks.

Governance & action classification (SPEC-034)

Terms for how the governance layer decides whether an action is allowed. Full treatment: Governed Action Classification.

• Action atom — the single Prolog term the constitution reasons about (e.g. delete_data). Today it is just the raw action string a caller passed (governance/prolog_client.py:186), not derived from the real operation.
• Reduction function — the (currently missing) function that turns a real operation (tool call / CXP packet / intent) into the atom/descriptor the gate reads. Its absence is why the constitution can't fire on real actions. SPEC-034 target: reduce_to_action (REQ-034-020).
• Classification — deciding what kind of thing an action is (security threat? involves PII? destructive?). The article checks are only as good as it.
• Blocklist vs allowlist — a blocklist names bad things and permits everything unlisted (its weakness); an allowlist names good things and denies the rest. The constitution's risk categories are blocklists of atom names, so a threat under a new name escapes.
• Property-derived classification — classifying by the attributes an action/resource has (env=prod, reversibility=irreversible) not by name on a list (ADR-0034).
• Lexical — "of words/surface text." A lexical detector matches words or string patterns (keywords, regexes) rather than reasoning over structure or meaning. intent_security.py's injection regexes are lexical: cheap, high-recall, easily fooled by rewording. Contrast structural (parsed shape) and semantic (meaning). Detectors are tiered by measured precision because lexical ones are noisy (ADR-0029).
• Toothless / decorative — a rule that cannot fail any input, so it looks like a control but enforces nothing (Articles VIII–X are bare true). Worse than no rule: it creates false confidence.
• PEP / PDP — Policy Enforcement Point / Policy Decision Point. The PDP is the one place that decides (the Prolog gate); a PEP intercepts an operation, asks the PDP, and enforces the answer, holding no policy of its own.
• ABAC — Attribute-Based Access Control: authorization by matching attributes of actor/action/resource/context, not by role (RBAC) or a global flag. Fits the prod-vs-test distinction (a resource attribute).
• Standing policy grant — a human-ratified pattern rule that auto-authorizes a whole scoped class forever (e.g. "delete any test fixture in env=test"). Widening its selector is a loosening (human-only).
• Consent grant — a human authorization bound to one specific resource, single-use, with expiry and provenance (e.g. "delete THIS prod row, once").
• Tightening vs loosening — a change adding denials is a tightening (quorum-eligible); one adding acceptances is a loosening (human-only, ADR-0009).
• Fail-open vs fail-closed — on error/misconfig a fail-closed gate denies (safe), a fail-open gate allows (dangerous). governance_strict (default true) makes the main engine fail-closed; some sites fail open (prolog_gate.py:96, ethical.py:112).
• Audit-only / shadow mode — the gate runs and records a verdict but does not act on it (kernel/dispatcher.py:310, default off). Not enforcement.
• Atom supply — asserting the ground Prolog facts the rules read (involves_pii(X), human_consent_given(...)). Facts come from outside the rulebase (ADR-0005); today almost nothing supplies the constitution's.
• Constitution-tier — artifacts whose changes need human ratification, never autonomous quorum (ADR-0013): constitutional.pl, the SPEC-034 authorization model.

Operational knowledge graph (orchkg on orchgraph)

The orchkg database on the orchgraph cluster (prod routing neo4j://10.53.1.160:7691), which replaced the Neo4j instance at 10.53.1.11:7687 on 2026-07-26.

Canonical schema: knowledge_graph/canonical_schema.py. Identity rule: {project}:{natural id} for project-scoped tiers; global natural ids for truly global things. ~48 labels in the live graph; the canonical core:

Node labels — code structure tier

• Project / Portfolio — the project hub node (keyed by slug) and its grouping. Every project-scoped node links up to its Project.
• Package / Directory / File — filesystem structure. File/Directory are being migrated to project-qualified ids (multi-project invariant).
• Module — one Python module (id {project}:module:{dotted.path}); DEFINES its classes/functions.
• Class / Function / Method — code symbols with name, qualified_name, project properties (the join keys for entity linking and trace sync). Method = function bound to a class.
• Parameter — a function/method parameter (HAS_PARAMETER from its owner).
• Predicate / Rule — Prolog predicates and rules from the governance layer's .pl corpus.
• UnresolvedCall / UnresolvedClass — call/inheritance targets the AST sync could not resolve to a known symbol (kept explicit, not dropped).

Node labels — spec/traceability tier

• Spec — one SPEC-NNN document (id {project}:{NNN}, natural_id kept).
• Requirement — a user-story-level requirement inside a spec (id {project}:{spec}::{req}; spec_id property links up).
• RequirementItem — one checklist item (id {project}:{REQ-tag}, bare tag kept in req_tag). The canonical target of TRACES_TO — code never traces to Requirement directly.
• UserStory / Scenario — story-level grouping and harness scenarios.
• Test / TestRun / TestResult — test entities and execution outcomes.

Node labels — runtime/operational tier

• Session / SessionStart / SessionEnd — engineering sessions (the session CLI's counterpart) and lifecycle events.
• Volk — an agent role (keyed by alias, e.g. U:Qa).
• Intent — a parsed user intent; PipelineRun — one pipeline execution of it; Task / Action — units of work within.
• Message — a CXP packet (inter-agent message); GatewayEvent / AuditEntry — gateway audit log entries; Event — generic runtime events; ToolCall — one tool invocation by an agent.
• PolicyDecision / Violation / Escalation / Resolution / Timeout — governance outcomes: a policy verdict, a rule violation, an escalation to a human/higher authority, a conflict resolution, a timeout event.
• Conversation / ConversationTurn — SPEC-021 captured conversations (Claude/kimi/IRC producers) and their turns.
• Decision / Artifact / Change / Component — an architecture/process decision record, a produced artifact, a code change event, a named system component.
• Fact / Memory — Prolog-derived session facts and SPEC-010 agent memory entries.

Node labels — architecture ontology tier (ontology phase 1-2)

• Architecture / Pattern / DesignModule / DesignClass — the as-designed architecture: the root architecture description, applied design patterns, and design-level modules/classes (vs the as-built Class/Function tier).
• ApiContract / DataEntity — declared API surfaces and domain data entities.
• QualityAttribute / WAFPillar / Constraint — quality attributes (with measurable scenarios), well-architected-framework pillars, and hard constraints the design must satisfy.
• CapacityModel / CostModel / CostLineItem / Environment — capacity and cost modeling artifacts and deployment environments.
• ArchitectureDecision — an ADR (ingested from this wiki's decisions.md); immutable once ratified (ADR-integrity gate).

Relationship types (edges)

• DEFINES — structural ownership: Module DEFINES Class/Function; Class DEFINES its methods. The backbone of code containment.
• CONTAINS — filesystem containment (Directory CONTAINS File etc.).
• HAS_PARAMETER — Function/Method → Parameter.
• CALLS / IMPORTS / INHERITS / IMPLEMENTS — code intelligence: call graph (lives on Function/Method), module imports, class inheritance, interface implementation.
• TRACES_TO — code symbol → RequirementItem: "this code implements that requirement". Written by sync_traces_to_graph.py from @traces; gaining a provenance property (static|runtime|both) per the BDD plan.
• TESTED_BY — code symbol → the test that exercises it (selector ranking signal).
• HAS_SPEC / DEFINES_REQUIREMENT / HAS_ITEM — Project → Spec → Requirement → RequirementItem: the spec corpus hierarchy.
• REQUIRES — requirement-level dependency.
• CHANGED_IN / NEXT_VERSION — temporal versioning: symbol → Change, version chains.
• MENTIONS / IN_THREAD / TRIGGERED_BY / RESULTED_IN / FAILED — runtime signal wiring: a signal (event/conversation) mentions code, belongs to a thread/session, was triggered by an event, resulted in a decision/resolution; TestRun/Event FAILED some node.
• HAS_CONVERSATION / HAS_TURN — Session → Conversation → turns.
• Architecture-tier edges: HAS_ARCHITECTURE / HAS_COMPONENT / EXPOSES (component → ApiContract), DATA_FLOWS_TO, DEPENDS_ON, PERSISTS_TO, RUNS_ON (→ Environment), HAS_SCENARIO / SATISFIES / HAS_QUALITY_ATTRIBUTE / MEASURED_ON (quality attributes), ADDRESSES_PILLAR / MUST_FOLLOW / CONSTRAINS (pillars & constraints), MODELED_BY / INFORMS / HAS_LINE_ITEM / METERS (capacity & cost), DECIDES / CHOSE / REJECTED / JUSTIFIED_BY / WEIGHS / SUPERSEDES / SELECTS / FORCED_BY (ADR reasoning: what a decision decided, the option chosen/rejected, its justification, trade-off weighing, supersession), APPLIES / USES_PATTERN (pattern application), THREATENS / AFFECTS / MITIGATED_BY (risk wiring), HAS_SLO.

Operational KG — core schema (code structure + spec/traceability tiers)

Semantic / wiki graph (Memgraph HA, routing 10.53.1.160)

One shared Raft-HA cluster serving BOTH the knowledge-wiki graph index and orchestrata's semantic/RAG layer; within the memgraph database, isolation is by label, and the operational KG is a separate database, orchkg.

Wiki-index labels (written by wiki-kimi index)

• Page — one wiki page (path, title, description).
• Project / Concept / Agent / Service / Procedure / Decision / Blocker / Session / Tag — typed entities extracted from pages: active projects, domain concepts, the agents (claude/kimi/deepseek), infrastructure services, step-by-step procedures, decision records, active blockers, work sessions, and controlled-vocabulary tags.
• Runbook / Tool / Milestone / Reference — operational runbooks (one per ## heading in runbooks.md), CLI tools extracted from reference/ pages, release milestones, and external-URL reference nodes.
• Chunk — the wiki RAG retrieval unit written by ingest_chunks.py (384-dim embedding, chunk_embedding vector index). This is the wiki's ACTIVE chunk label — distinct from orchestrata's SemanticChunk family below.

Wiki-index edges

• BELONGS_TO — page → its project. TAGGED — page → Tag.
• LINKS_TO — page → page (markdown links). MENTIONS — page → entity it names. REFERENCES — page → external resource.
• HAS_DECISION / HAS_BLOCKER — project → its decision/blocker records. HAS_PROCEDURE — client API (link_project_procedure) exists but is not emitted by the current indexer walk. PRODUCED — session/agent → artifact.
• HAS_RUNBOOK / HAS_MILESTONE — project → its runbooks / release milestones.
• DEPENDS_ON — Decision → entity named in its text; Service → Service (links between infrastructure/ pages). RELATED_TO — Concept↔Concept, Procedure↔Procedure. USES — Agent → Service. DERIVED_FROM — Chunk → its source Page.

Wiki-index schema (Memgraph)

Semantic-RAG labels (written by orchestrata ingest + wiki RAG)

• SemanticChunk (+ legacy CodestralChunk/QwenChunk/Chunk — a known label-split debt) — an embedded chunk of source code or wiki text with its vector; the retrieval unit for GraphRAG.
• ArchitectureChunk — the semantic twin of the ratified architecture ontology corpus (ADR/design docs) for architecture retrieval (ruling 4).
• Entity (Spec/Requirement/Story/CodeElement flavors) — the enhancement layer linking chunks to structured entities, with IMPLEMENTS edges.
• Module / ADR / Tool — coarse code-module nodes, ADR mirrors, and a small number of tool nodes.

Semantic-RAG schema (Memgraph)

Neither graph models the volk tool registry; the live registry is tools.registry ToolRegistry.metadata()/names() (SPEC-072).

Related

• Orchestrata, explained
• Orchestrata Ultimate hub
• Table of contents
• KG migration to orchgraph
• Rulings canon
• Wiki home