You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: refresh docs to match the now-shipped reality (real swarm, Gold Seal, honest pipeline, live model)
Audited the tracked product docs against what is actually on `main` and applied
surgical, honest fixes. Already-accurate docs (korg-registry, korg-embeddings,
korg-auth, korg-bridge, korg-seal) were left untouched.
README.md:
- Status section rewritten: honest shipped/planned split; 300+ tests (was a
stale "175"); swarm listed as a real 5-persona swarm; surfaced the Gold Seal,
honest pipeline, live-model and in-browser verifiers.
- BERT/Candle made honest (optional `candle` feature; deterministic fallback).
- Comparison gained Gold Seal + honest-attestation rows; added the live-model
swarm example + in-browser verifier links; removed stale "ARCHITECTURE coming
soon".
ARCHITECTURE.md: 4-persona -> 5-persona (added the distinct `Persona::Evaluator`);
new "Verifiable Flight-Recorder Capabilities" section (ledger@v1, Gold Seal,
honest run-once, provider model) with a clearly-marked Planned list.
ROADMAP.md: removed micro-healing from future work (it is already shipped).
Crate/adapter READMEs + docs/: removed invented perf/size numbers
(GIT_ISOLATION "<50ms", POSITIONING "200-line"); de-stale'd brittle exact test
counts (korg-core, korg-setup) or corrected them to the real counts
(recall-mcp); documented `response_format` + `DeterministicProvider`
(korg-llm); clarified legacy flat-ledger vs the recommended verifiable
per-session capture (claude-code); honest "no bundled SPA/WASM frontend"
(korg-server); corrected stale placeholder/stub claims that no longer match the
code (korg-tui).
Each edit was audited against the source and re-checked by an adversarial
honesty critic; spot-verified that all numbers are counted, not invented.
Copy file name to clipboardExpand all lines: ARCHITECTURE.md
+19-4Lines changed: 19 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ The entire Korg backend is implemented in Rust, which provides compile-time guar
12
12
13
13
-**Ownership and Borrowing**: Rust's ownership model ensures that there is always one and only one "owner" of any given piece of memory. Data can be immutably borrowed by multiple parties or mutably borrowed by exactly one party. This statically prevents data races at compile time. In Korg, shared state like the `Blackboard` is wrapped in concurrency primitives like `Arc<Mutex<T>>`, which enforce these borrowing rules at runtime, ensuring that even in a highly concurrent multi-agent system, there are no data races.
14
14
-**Absence of Null and Undefined Behavior**: Rust's type system eliminates null pointer dereferences through the `Option<T>` and `Result<T, E>` enums. This forces developers to handle the absence of a value explicitly, preventing entire classes of bugs and security vulnerabilities common in other systems languages.
15
-
-**Fearless Concurrency**: The combination of ownership rules and type-system constraints allows Korg to manage the 4-Persona Swarm with "fearless concurrency." The compiler guarantees that any data shared between threads (i.e., between the Leader orchestrator and its various tasks) is done so safely.
15
+
-**Fearless Concurrency**: The combination of ownership rules and type-system constraints allows Korg to manage the 5-Persona Swarm with "fearless concurrency." The compiler guarantees that any data shared between threads (i.e., between the Leader orchestrator and its various tasks) is done so safely.
16
16
17
17
### 1.2. Isolated Execution via Process Sandboxing
18
18
@@ -34,17 +34,17 @@ At the heart of Korg's concurrency model is the **Blackboard**, a central, obser
34
34
-**CRDT-like Merging**: The `perform_semantic_merge` function in `src/leader.rs` exemplifies this principle. It takes the outputs from all competing personas and uses a "Synthesizer" persona (Lucas) to reconcile them into a single, cohesive set of mutations. This is analogous to a CRDT merge function that resolves concurrent updates into a deterministic, final state.
35
35
-**Observability**: The Blackboard is the "Gravitational Well" around which the swarm orbits. It is the single source of truth for system telemetry. Personas emit `SwarmTelemetryPulse` messages, which the Leader ingests into the Blackboard's `trace_buffer`. The `Evaluator` then reads this buffer to assess the swarm's health, creating a tight, observable feedback loop. The state is exposed via the `/api/state` endpoint for the web cockpit, providing real-time observability to the human operator.
36
36
37
-
## 3. 4-Persona Adversarial Swarm Topology
37
+
## 3. 5-Persona Adversarial Swarm Topology
38
38
39
-
Korg employs a fixed 4-persona swarm, where each agent has a specialized, adversarial role. This division of labor creates a system of checks and balances that promotes robust, high-quality output.
39
+
Korg employs a fixed 5-persona swarm, where each agent has a specialized, adversarial role. This division of labor creates a system of checks and balances that promotes robust, high-quality output.
40
40
41
41
1.**Orchestrator Captain (The Planner)**:
42
42
-**Role**: High-level strategist and planner.
43
43
-**Function**: Receives the initial root task from the operator. Decomposes the task into smaller, actionable work packages (`decompose_into_persona_packages` in `src/leader.rs`). Initiates the `ContractNegotiation` phase, proposing acceptance criteria for the task. The Captain sets the direction for the entire swarm.
44
44
45
45
2.**Auditor Harper (The Researcher/Critic)**:
46
46
-**Role**: Context-gatherer, researcher, and adversarial critic.
47
-
-**Function**: During `ContractNegotiation`, Harper (acting as part of the `Evaluator`) critiques the Captain's proposed criteria for ambiguity and relevance, forcing a more robust contract. During execution, Harper is assigned "Research" tasks, gathering information from the codebase or external sources to inform the Builder. Harper's primary function is to prevent the swarm from "hallucinating" or working with incorrect assumptions.
47
+
-**Function**: During `ContractNegotiation`, Harper critiques the Captain's proposed criteria for ambiguity and relevance, forcing a more robust contract. During execution, Harper is assigned "Research" tasks, gathering information from the codebase or external sources to inform the Builder. Harper's primary function is to prevent the swarm from "hallucinating" or working with incorrect assumptions.
48
48
49
49
3.**Builder Benjamin (The Coder)**:
50
50
-**Role**: Primary code generator and implementer.
@@ -54,6 +54,10 @@ Korg employs a fixed 4-persona swarm, where each agent has a specialized, advers
54
54
-**Role**: Merger and finalizer.
55
55
-**Function**: After all personas have submitted their work, the `LeaderOrchestrator` invokes Lucas. As shown in `perform_semantic_merge`, Lucas's job is to take the winning proposal from the **Arena** and intelligently merge it with complementary ideas from the other personas. This produces a final, cohesive patch that is more robust than any single persona's output.
56
56
57
+
5.**Evaluator (The Harsh Adversarial Critic)**:
58
+
-**Role**: Independent scoring authority and Generator/Evaluator loop.
59
+
-**Function**: Spawned separately by the Leader (`Spawning Evaluator to score persona ...`), the Evaluator receives a generator persona's output and scores it against the negotiated contract rubrics in the **Arena**, following the Anthropic-style Generator/Evaluator loop. It is a distinct persona (`Persona::Evaluator`), not a role played by any of the four workers above, and it is what turns the swarm's output into a measured, adversarially-checked verdict.
60
+
57
61
This adversarial collaboration ensures that a plan is critiqued before it's executed, code is generated based on a solid plan, and multiple proposed solutions are synthesized into a superior final product.
58
62
59
63
## 4. State Transition Sequence
@@ -143,6 +147,17 @@ Korg maintains a tamper-proof audit trail of every significant action using a cr
143
147
- Simultaneously, it uses the `state_merkle_root` to find the corresponding state blob and rehydrate the logical `Blackboard`.
144
148
- This powerful feature allows an operator to rewind the AI's "thought process" and codebase to any valid, signed point in history and "fork" its execution in a new direction, all with cryptographic guarantees of integrity.
145
149
150
+
### 5.1. Verifiable Flight-Recorder Capabilities
151
+
152
+
Beyond the in-process provenance chain above, Korg ships a set of independently-verifiable, "flight-recorder" capabilities that let third parties check an agent's work without trusting Korg itself:
153
+
154
+
-**`korg-ledger@v1`**: A frozen, hash-chained, HLC-ordered, tamper-evident event ledger with cross-language conformance (Rust/Python/JS). Each event carries an Ed25519 per-event signature, and the ledger supports git-tip structural anchoring for offline structural verification.
155
+
-**Gold Seal (`goldseal@v1`)**: A public, independently-verifiable certificate of agent work, produced by the `korg-seal` CLI (mint/anchor/resolve/verify) and checkable by three conformant verifiers (`korg-verify` in Rust, plus Python and JS) as well as zero-install in-browser verifiers hosted on GitHub Pages.
156
+
-**Honest `korg run-once` pipeline**: Runs a real patch through a real `cargo check` and attests a mutation count that *equals* the real `git diff` (file count + changed paths). When it cannot produce a real result, it reports an honest null rather than fabricating one.
157
+
-**Provider model**: The default is a hermetic `DeterministicProvider` (fixture-only); `--provider ollama` runs a live local model on arbitrary tasks.
158
+
159
+
**Planned (not yet shipped):** live *network* time-witness anchoring (the anchor structure and offline verification are shipped; only the trusted-time witness fetch remains an honest limit), `crates.io`/npm publishing of the CLIs and verifiers, and a `korg fork` / execution-checkpoint-restore CLI (the primitives exist; the shipped reversibility today is `korg rewind`).
Since Korg personas can interact with GUIs and web browsers, a critical security vector is the accidental exposure of sensitive data in screenshots. The Visual Policy Engine in `src/vision_policy.rs` acts as a fail-secure firewall for all visual data.
| Semantic governance | BERT cosine similarity via the optional `candle` feature (Hugging Face); a deterministic embedding fallback runs when `candle` is not built|
286
302
| TUI dashboard | Ratatui + Crossterm |
287
303
| Web cockpit | Axum + SSE |
288
304
| Syntax highlighting | Syntect + tree-sitter |
@@ -291,7 +307,7 @@ Korg treats AI cognition the same way a hypervisor treats compute and Git treats
291
307
292
308
## Architecture Deep Dive
293
309
294
-
→ **[Read the full technical write-up](https://github.com/New1Direction/korg/blob/main/ARCHITECTURE.md)***(coming soon)*
310
+
→ **[Read the full technical write-up](https://github.com/New1Direction/korg/blob/main/ARCHITECTURE.md)**
295
311
296
312
### Real-World Audit Ledger Example
297
313
You can inspect a real-world cognitive audit ledger produced by Korg. This NDJSON file records a live session where Claude Code was prompted to call Korg's MCP tools to refactor a function and rename all call sites, capturing the full HLC causal graph and `actor_id` recorder metadata:
@@ -309,23 +325,28 @@ The short version:
309
325
310
326
## Status
311
327
312
-
Korg is in active development. Current test coverage:**175 tests, 0 failures** (162 cargo across 8 crates + 13 pytest for the PyO3 bridge).
328
+
Korg is in active development, built on a**frozen `korg-ledger@v1` spec with cross-language conformance** (Rust + Python + JS). Test footprint: **300+ Rust tests across the workspace plus Python/JS conformance suites**, CI-gated (build · tests · cross-language oracle · differential fuzz) and green on `main`.
313
329
314
-
-[x] Append-only cognitive ledger with HLC ordering
330
+
**Shipped:**
331
+
-[x] Append-only, hash-chained cognitive ledger with HLC ordering
315
332
-[x] Deterministic replay and projection rebuilds
333
+
-[x] Reversible execution — rewind the ledger to any prior sequence point (tamper-evident `LedgerRewind`)
-[x]**Gold Seal (`goldseal@v1`)** — a public, independently-verifiable certificate of agent work, with zero-install in-browser verifiers
336
+
-[x]**Honest pipeline** (`korg run-once`) — real patch → real `cargo check` → an attested mutation count that equals the real `git diff`; never fabricates (reports an honest null instead)
337
+
-[x]**Live local model** (`--provider ollama`) — real per-persona work on arbitrary tasks
338
+
-[x]**Multi-agent swarm** (Captain, Harper, Benjamin, Lucas, Evaluator) — genuine worker subprocesses doing real, measured, attested work with DAG data-flow between personas
0 commit comments