Reference

Glossary

Every Oraclous term, defined once — the canonical, citable source. Each entry is a self-contained answer.

Actor: An Actor is any entity — human member or AI Agent — that can be assigned work in a Harness. Humans and Agents are symmetric Actors: each has an identity, a scope, and a capability allocation, and they share a common interface. This symmetry is the basis of the "second mind."
Agent: An Agent is a non-human Actor with its own identity, role, capability allocation, scope, and Consciousness record. An Agent is not the language model — the LLM is a resource the Agent uses. Oraclous always says "Agent," never "bot" or "chatbot," because Agents are governed, identity-bearing participants in the work.
Agentic AI: Agentic AI is software in which AI Agents pursue goals by planning, taking actions through tools, and adapting — rather than only answering prompts. Oraclous is an agentic AI platform: it gives Agents identity, capabilities, and governance so they act as accountable participants in real work, alongside humans, under your organisation's access rules.
Application gateway: The Application Gateway is Oraclous's Layer-4 public-facing surface — the platform's contract with the outside world. It exposes REST and WebSocket APIs, the MCP server and client, webhook receivers, published Agents, embeddable widgets, and member-facing UIs, and it enforces authentication, rate limits, and CORS scoping. The frontend talks only to the gateway.
BYOM (Bring Your Own Model): BYOM means Oraclous runs the language-model provider you choose, treating the LLM as a resource an Agent uses rather than the Agent itself. Supported protocol shapes are Anthropic-native, OpenAI-compatible, and Gemini-compatible; model configuration resolves at agent, workspace, or organisation level. Switch providers by config without rewriting the Harness.
Capability: A capability is anything an Actor can invoke in a workspace. There are five kinds: Tools (invokable functions), Skills (prose loaded into an Agent's context), Agents, Harnesses, and Human roles. The Capability Registry is the single source of truth for what capabilities exist, under one uniform descriptor model.
Capability registry: The Capability Registry is Oraclous's Layer-2 single source of truth for what can be invoked in a workspace. It owns the uniform capability descriptor model (one schema across the five kinds), capability resolution, versioning by content hash and semver, ReBAC-gated visibility, and the inbound/outbound adapters — including the MCP tool importer.
Compile flow: The Compile flow is how an Operator's stated goal becomes a committed, governed Harness. Its steps: state the goal, the Gateway invokes the compiler harness, a workspace survey runs, optional clarifying questions are asked, the topology is planned, a manifest is emitted, a review dialogue happens, and the Operator commits. You review the Harness before it runs.
Consciousness: Consciousness is the per-Actor record of accumulated learning, written and consulted through Oraclous's Learn flow. It is the platform's term for an Actor's persistent memory of past work — not literal sentience. Consciousness is substrate-anchored: exporting a Harness exports its OHM definition but not its accumulated Consciousness records.
Credential broker: The Credential Broker is the Substrate's secret keeper: it stores credentials under per-organisation encryption and resolves them on demand for authorised invocations. Credentials never leave the broker in plaintext and are never cached outside it. In cloud mode, KMS separation ensures Oraclous-the-company cannot unilaterally decrypt them. It holds BYOM provider credentials and OAuth tokens.
Data sovereignty: Data sovereignty is Oraclous's architectural guarantee that an organisation's data stays under its control, identically whether self-hosted or cloud-hosted. Every record carries an organization_id, credentials never leave the broker in plaintext, and in cloud mode KMS separation means Oraclous staff cannot decrypt customer state. Cross-organisation data flow is structurally impossible.
Execution engine: The Execution Engine is the part of Layer 3 that handles work outside a single request: long-running jobs, checkpoints, schedules, and task-board state. It registers and fires triggers from the OHM, tracks jobs, supports pause/resume/cancel for durable executions, and enforces timeouts and the declared retry count — no runaway loops.
Federation: Federation is controlled collaboration across workspace boundaries, where one workspace requests another's capabilities under relationship-based (ReBAC) policy. Oraclous's Traversal flow governs these cross-workspace requests; cross-workspace traversals are metered and provenance-tracked. Federation is cross-workspace, not cross-organisation — cross-organisation data flow remains structurally impossible.
Harness: A harness is a workspace artifact that describes how a goal gets done across humans and Agents. It contains a goal statement, a roster of Actors, an orchestration spec, triggers, a task-board reference, a policy envelope, and a provenance link. In Oraclous every executable thing is a harness; you describe one, you don't code it.
Harness runtime: The Harness Runtime is Oraclous's Layer-3 executor — its central nervous system — that loads a Harness and runs it to completion or escalation. It dispatches Actors (Agents into a tool-use loop, humans into task-board assignments), resolves capabilities and credentials per invocation, and enforces the policy envelope. There is no privileged code path.
Human-in-the-loop (HITL): HITL is the assignment of a step in a Harness to a human for review, approval, or action. Oraclous's Runtime treats waiting on a human like waiting on a tool return — same primitives, different latency — so human oversight is structural, not a manual side-channel. The Runtime enforces HITL gates regardless of prose.
Knowledge graph: A knowledge graph is an organisation's queryable, provenance-tracked memory, stored on the Substrate as nodes and relationships scoped by organization_id. The knowledge-graph-service owns the write side: multi-modal ingestion of text, documents, structured data, code, and temporal data, plus schema management, analytics, and ReBAC-graph maintenance. Cross-organisation traversal is structurally impossible.
Knowledge retrieval: Knowledge retrieval is the read side of the Substrate, exposing modality-appropriate ways to query the knowledge graph under ReBAC. The knowledge-retriever-service offers semantic, full-text, hybrid, graph-traversal, and temporal queries, every one returning the same NodeResult envelope with provenance. It also performs federation traversal across workspaces under ReBAC.
Manifest: A manifest is the serialised form of a Harness in OHM format. It carries a content hash (immutable, automatic) and optional semver tags. Its structured zone holds validated fields like actors and policies; its prose zone holds model-interpreted instructions. A prose instruction never overrides a structured policy — code wins.
MCP (Model Context Protocol): MCP is an open protocol for connecting AI systems to tools and context, which Oraclous supports as both a server and a client. As an MCP server (via the Application Gateway, ReBAC-scoped), it exposes workspace capabilities to clients like Claude Desktop. As an MCP client, it imports external MCP tools into the Capability Registry as native OHM tools.
Metering: Metering is the Substrate-level tracking of resource consumption per organisation and per workspace. It captures tokens, tool invocations, storage, execution time, and cross-workspace traversals. Metering measures consumption neutrally — it does not assign prices, leaving pricing under the customer's control.
Multi-agent orchestration: Multi-agent orchestration is coordinating several AI Agents — assigning their work, sequencing hand-offs, and governing what each may do — so they act as one system rather than in isolation. Oraclous orchestrates Agents and humans together through one runtime, under one ReBAC policy envelope, with the Harness as the unit being orchestrated.
OHM (Oraclous Harness Manifest): OHM is the serialised, portable form of a Harness — YAML with embedded Markdown, written to .ohm.yaml. It has two zones: a structured zone (machine-validated YAML fields) and a prose zone (model-interpreted Markdown). OHM is the canonical hub every portability operation routes through, so you can leave without re-implementing.
Operator: An Operator is the person who states an organisation's goal in natural language so the platform can compile it into a governed Harness. The Operator describes what needs doing in prose; the platform owns how the runtime enforces it. This separation lets teams ship workflows without an engineering sprint per use case.
Organisation: An organisation is the outermost tenancy unit in Oraclous, and the boundary across which data flow is structurally impossible. Every node, relationship, query, cache entry, and audit log carries an organization_id. An organisation contains a hierarchy of workspaces. It is the unit data sovereignty is guaranteed around.
Platform-as-code, actors-as-harnesses: This is Oraclous's founding principle: the platform's machinery is code (it enforces governance and executes deterministically), while its behaviour is Harnesses (which reason and act on goals). Governance is written once by the platform; work is described in prose by Operators. The category boundary shifts from "build the agent" to "describe the goal."
Policy set: A policy set is a versioned governance envelope that declares the rules a Harness runs under. Oraclous ships five named sets, from development to production-strict to production-federated, each declaring trust tier, budget ceilings, signature requirements, BYOM constraints, capability allow/deny, and audit level and retention. Coded enforcement applies them; prose never overrides them.
Portability: Portability is the property that OHM and Oraclous's open reference runtime let a customer leave without re-implementing their work. Every portability operation routes through OHM, the canonical hub. The docs state portability's limits plainly: knowledge-graph data goes via standard exports, and credentials, the ReBAC graph, and Consciousness records do not travel.
Provenance / audit: Provenance is the traceable record of where every result came from and how it was produced, written as a universal sink on the Substrate. Combined with ReBAC and versioned policy sets, provenance gives auditors proof rather than promises: every node, relationship, query, and audit log carries an organization_id, and harness executions write provenance through.
ReBAC (Relationship-Based Access Control): ReBAC defines permissions by the relationships between entities — people, Agents, workspaces, data — rather than by static roles. Oraclous enforces ReBAC platform-wide, at the Harness level, so the fabric that runs the work also proves who could touch what. Contrast with RBAC: RBAC grants access by assigned role and suffers "role explosion"; ReBAC grants access by relationship to the resource.
Second mind: A second mind is the unified operational fabric Oraclous forms around an organisation, where human members and AI Agents work side by side under the organisation's own access rules. It is not a single clever agent but the organisation's combined human and Agent capacity, governed as one fabric and orchestrated by goals written in plain language.
Substrate: The Substrate is Oraclous's trust root — Layer 1 of the architecture — owning identity, the ReBAC graph, knowledge graphs, credentials, audit, metering, task boards, manifests, and Consciousness records. Every storage primitive carries an organization_id that every query must filter on, making cross-organisation traversal structurally impossible. All other layers depend on it.
Workspace: A workspace is the primary working unit nested inside an organisation, holding members, Agents, tools, knowledge graphs, Harnesses, task boards, and policies. Workspaces are arranged in a hierarchy within an organisation, and Federation lets them request each other's capabilities under ReBAC. They are the scope most day-to-day work happens in.