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 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.

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.

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.

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