Concepts

Orkastery architecture

Understand who presents, executes and verifies each change.

Who conducts, executes and checks. The host presents intent to the core. The core dispatches the runtime and receives code and evidence for verification. Gates and the ledger remain in the core.

Isolation and authorization. The thread defines scope and permissions. The worktree isolates code. Leases coordinate collisions. The delivery gate rechecks authorization and evidence before merging.

Three layers with explicit responsibilities

The host receives the request and presents decisions. The ork core applies contracts, records state and checks evidence. The runtime writes the product. A runtime report does not replace running the checks.

The core is a deterministic CLI. Adapters connect hosts and runtimes; business rules remain in the core so the same decision keeps its meaning across channels.

State and provenance

The orkastery.yaml manifest defines the project. Each thread has state, a ledger, claims and hashed prompts under .orkastery. Query these through core commands. A conversation may explain state, but is not its source of truth.

ork thread status <thread>
ork phase list <thread>
ork claims list <thread>

Isolation and decisions

A worktree separates a thread’s code. Leases coordinate resources that could collide, such as edited paths and the merge destination tree. Parallel work still requires serialized delivery.

The mode controls scheduled pauses. Blocking policies, verification failures and typed escalations still apply. Memory provides context; it does not grant authorization.

Two measures with different purposes

The conduction index derives from ledger events and describes how the cycle was conducted. The human score records the owner’s assessment of the result. They have different sources: neither should be invented or used as a measure of the other.

A delivery rate requires a time interval, a defined population and source records. This page does not report a rate without that measurement.

Deterministic graph: the KG1 contract

KG1 defines ork.code-artifact-graph/v1 and ork.graph-benchmark/v1, with pure validation and a synthetic corpus. Identical input, configuration and extractor versions produce identical identities and canonical content. Each relationship requires locatable evidence and preserves source access restrictions.

The graph is a disposable local projection. KG1 provides the contract, pure validation and the corpus; extraction is KG2, and the index with ork grafo queries is KG3. It does not change orkmind.company-brain/v1 or replace Ork state or Company Brain. No measured benchmark demonstrates savings at this stage.

Extraction, index and queries: KG2 and KG3

KG2 extracts a graph in the same contract from a local Git repository: TypeScript and JavaScript through the compiler, Markdown with sections, links, frontmatter and cited IDs, and provenance for every edge. An edge exists only with proof; anything unproven stays out and is declared as a diagnostic or as a gap in the extraction report. The same input yields the same graph and digest in any read order.

KG3 stores that graph in a local index for a clean HEAD, outside git, and queries it for neighbors, callers, importers and paths. The same question produces the same output, every edge carries its extractor and evidence, and answers declare themselves partial. Records outside the local grant appear in no answer, count or candidate. Incremental extraction, phase consumption, federation and an MCP tool remain out of scope.

ork grafo indexar --verificar
ork grafo vizinhos <node> --json