Prove the core loop, cold, on a real repo.
Find the gaps. Fix them the same day.

2,022 files → 2,402 ledger objects, cold, in under a minute of pipeline time.

$ ekos init && time ekos build
Build complete. Files observed (new): 2022
real  0m33.587s

$ time ekos recover
Recover complete. SQL: 2 (both dialects clean)  Git commits: 500
Contributors: 124  Local documents: 41  CI/CD pipelines: 14  Passes run: 8
real  0m0.509s

$ time ekos resolve && time ekos compile && time ekos commit
resolve:  Merges proposed: 8    compile: 3977 relationships
commit:   840 evidence records, 71 subsystem rollups
real  0m0.084s / 0m0.155s / 0m53.433s

Total: well under two minutes end to end, cold, on a real 2,022-file repo with real git history, real SQL schemas across two dialects, real CI pipelines, and real documentation. ekl "FIND Object" confirms 2,402 objects in the ledger afterward — files, tables, contributors, pipelines, documents, and rollups together.

0 real tables → 42 real tables, from the same file.

WARN sql-analyzer: sqlparser failed on priv/repo/structure.sql:
     sql parser error: Expected: end of statement,
     found: INCREMENT at Line: 116, Column: 5;
     falling back to empty graph

INFO sql-analyzer complete
     pass=sql-analyzer:priv/repo/structure.sql
     objects=42 relationships=0

Root cause: `sqlparser`'s CREATE SEQUENCE option parser checks INCREMENT/MINVALUE/MAXVALUE/START/CACHE/CYCLE in a fixed order, once each, no loop — real pg_dump output emits START WITH before INCREMENT BY, which this single-pass checker can't handle. Two more real gaps surfaced in the same file investigating further: CREATE UNLOGGED TABLE (no dispatch case for a real, otherwise- tokenizable keyword) and a trailing NOT VALID clause on a real CHECK constraint. Fixed by three preprocessing passes — whole-statement stripping for sequences (never modeled in the KIR anyway), and two narrower, information- preserving keyword/clause strips that keep the real table/constraint intact.

public.sites: 21 real columns, real types, real evidence.

Object: public.sites (Table)
  Properties:
    columns: [
      {"data_type":"BIGINT","name":"id"},
      {"data_type":"CHARACTER VARYING(255)","name":"domain"},
      {"data_type":"BOOLEAN","name":"public"},
      {"data_type":"BOOLEAN","name":"locked"},
      {"data_type":"JSONB","name":"imported_data"},
      {"data_type":"CHARACTER VARYING(300)[]","name":"allowed_event_props"},
      {"data_type":"BOOLEAN","name":"conversions_enabled"},
      {"data_type":"BOOLEAN","name":"funnels_enabled"},
      ... 13 more real columns
    ]  // 21 columns total
  Evidence:
    [100%] priv/repo/structure.sql — "CREATE TABLE public.sites"

This is the table behind Plausible's core "is this site public, is tracking locked, which event props are allowed" logic — real array types (CHARACTER VARYING(300)[]), real JSONB columns, real booleans, every one correctly typed. Before RFC 0059 this table — and every other real table in the file, including api_keys, users, and 39 more — simply did not exist in EKOS's knowledge of this repo.

14 merge proposals → 8 — with more real tables to confuse it, not fewer.

Fix verified with real numbers first, not guessed: Jaro-Winkler/Jaccard scores computed for all 17 real pairs `ekos resolve` proposed against this repo (*Postgres tables hadn't recovered yet when the 0.85 baseline was captured live, so this one row's "before" score is the same real column data, scored the same way, in a unit test — not a separate live run). At 0.85, 16 of 17 known-wrong merges clear the bar. At 0.90 — plus stripping `Table`'s schema-qualifier prefix, which was independently inflating name similarity — 14 of 17 are rejected and all 3 known-correct merges survive. Not a complete fix: 3 residual pairs (real, different CI pipelines and doc-generator readmes with near-templated names) still merge — documented honestly in the RFC, not hidden.

Two objects that vanished are directly findable again, under their own names.

$ ekos query find imported_browsers
plausible_events_db.imported_browsers   // was absent — merged
                                                    // into imported_visitors

$ ekos query find Niklaas
Niklaas Baudet von Gersdorff             // was absent — his 1 real
                                                    // commit had vanished under
                                                    // Niklas Hambüchen's identity

$ ekos query object <imported_browsers id>
columns: [..., "browser", "browser_version"]     // its own real distinguishing
                                                    // columns, not imported_visitors'

This is the concrete, human-legible version of "14 → 8 merge proposals": a real contributor's identity and his one real commit are back under his own name, and asking about imported_browsers now returns its own real columns — browser, browser_version — instead of silently substituting imported_visitors's 8-column schema.

The exact same question. The exact same ledger. One retrieved nothing.

$ ekos ask "Who is Niklas Hambüchen and what did they
             contribute to this repository?"
I apologize, but there is no provided context or
evidence to answer this question. I'm unable to
provide an answer without any information.

$ ekos ask "Who is Niklas Hambüchen and what did they
             contribute to this repository?"
Niklas Hambüchen is a contributor to this repository,
having made 2 commits.

Sources:
  [100%] git:contributors — "contributor: Niklas Hambüchen"

Root cause: any punctuation in a question (a trailing ? is enough) made `Ledger::find_objects` escape the entire sentence into one literal FTS5 phrase — text that can never appear verbatim in an object's indexed content. Fixed by extracting keywords (stopwords and punctuation stripped, split the same way FTS5's own tokenizer splits on `_`) and trying an AND query for precision, then OR for recall, before falling back to the original raw question.

ekos_search and ekos_ekl confirm both fixes, not just the CLI.

→ tools/call ekos_search {"query":"imported_browsers"}
← {"matches":[
    {"id":"023b95fd-...","name":"plausible_events_db.imported_browsers"},
    {"id":"d24e8bb9-...","name":"fixture/ga4_report_imported_browsers.json"},
    ...
  ]}                              // the real Table object, ranked first

→ tools/call ekos_ekl {"query":"FIND Object WHERE kind='Table'
                                   AND name CONTAINS 'sites'"}
← {"count":1,"rows":[
    {"id":"b5dc8424-...","kind":"Table","name":"public.sites"}
  ]}                              // the real Postgres table, one clean hit

Both fixes hold over the exact interface an agent host actually calls — not just the CLI convenience wrapper around it. One ledger, one fix, both surfaces.

Three real gaps. Three real fixes. Verified live, not just unit-tested.