Orchid — Autonomous Research, Development & Execution System

Orchid is an autonomous agent system that pursues human-set goals with minimal supervision. The human sets a goal and may, optionally and asynchronously, observe progress and redirect. Everything between goal and outcome — research, hypothesis formation, development, and execution — is driven by the system itself.

Orchid is designed as a recursive orchestration system: a root orchestrator node owns the root goal, decomposes work, and may spawn child orchestrator nodes for sub-goals. Each node runs its own local cognitive loop, schedules workers, and reports through a durable knowledge store. Workers are stateless leaves; orchestrator nodes are internal control-plane nodes.

The contract

Role	Responsibility
Human	Set goals. Optionally observe. Optionally redirect. Approve gated acts.
Orchid	Everything else: gather context, decompose goals, spawn child orchestrators, find sources, form hypotheses, accumulate facts, make decisions, act, and learn.

The design target is async-first autonomy: the system must make meaningful progress while no human is watching, and must remain legible enough that a human returning hours or days later can understand what happened, why, and which orchestrator node or worker did it.

The seven first-class knowledge objects

Orchid's durable semantic memory and reasoning substrate is built from seven knowledge entity types. Everything the system knows, wants, or has decided is one of these:

1. Goal — what we are trying to achieve, and why.
2. State — where the work currently stands.
3. Context — the framing, constraints, and environment a goal lives in.
4. Source — where information came from (provenance).
5. Hypothesis — a proposed, testable belief about the world.
6. Fact — a verified, sourced claim treated as ground truth.
7. Decision — a committed choice, its rationale, and its alternatives.

These are detailed in 02-data-model.md.

The operational ledger

Recursive orchestration also requires durable control-plane state. Orchid stores an operational ledger alongside the seven knowledge entities:

• OrchestratorNode — a control-plane node that owns a goal/subtree by lease.
• WorkItem — a persisted unit of schedulable work, including worker tasks and child-orchestrator tasks.
• Lease — single-writer ownership over a goal's State.
• ResourceClaim — a read/write/exclusive claim used to coordinate concurrent nodes safely.

The operational ledger is not an eighth knowledge object; it is the system's runtime/accountability layer. The Knowledge Store is still the durable mind from which all processes rehydrate.

Document map

Document	Purpose
00-vision.md	Why Orchid exists, principles, non-goals.
01-architecture.md	Recursive orchestrator nodes, data flow, deployment shape.
02-data-model.md	Seven entities plus operational ledger schemas/invariants.
03-cognitive-loop.md	Per-node perceive → reason → act → learn cycle.
04-human-interface.md	Goal setting, observation, redirection, approval gates.
05-knowledge-and-memory.md	Graph/vector store, belief dynamics, concurrency.
06-execution-and-safety.md	Autonomy levels, inherited gates, guardrails.
07-glossary.md	Shared vocabulary.
08-recursive-orchestration.md	Multi-orchestrator concurrency rules.

Status

Draft v0.2 — architecture and data model under design. Nothing here is load-bearing yet; this set defines the target before implementation.