Nobody needs another kanban board, and this post is not about one.
We open-sourced arrow-kanban — an Arrow-native work-graph engine with Parquet persistence, typed relationships, and a NATS server mode (MIT). One thing about it is genuinely unusual, and the rule we held ourselves to while writing this is that a claim is either runnable or it is labeled as something weaker. Everything below is one or the other, marked.
Installing: clone the repo and build from source. The crates.io release is still pending — neither name currently resolves to an installable version, so git is the path today.
1. The relationship vocabulary is data, and we can prove what that costs
Work items in this engine are connected by typed, directional edges — dependsOn, implements, validates, partOf — so you can ask "which experiment validates this hypothesis?" without parsing prose. The vocabulary those edges come from is not a Rust enum. It is an OWL ontology file, ontology/kanban.ttl: each predicate is an owl:ObjectProperty with a domain, a range, and an inverse, and the engine validates edges, projects inverses, and refuses near-misses from that data.
The loader fails closed, and the fallback is the strict direction: if the ontology is malformed, the engine falls back to a compiled predicate set that is narrower than the data — degraded means stricter, never looser. A broken ontology file cannot open the vocabulary up.
Adding a relationship pair costs zero lines of production Rust. We measured it on the fleet that runs this engine, twice, by different authors. One addition of two predicate pairs was +43 lines of ontology data, four owl:ObjectProperty declarations, zero production Rust — a figure the change's reviewer re-derived independently rather than trusting the author's count. A later, independent addition of a third pair by a different developer was +19 lines of data, again zero production Rust, accompanied by a 22-line test. The second measurement was not a re-run of the first: different pair, different author, same result.
Three different costs hide inside "add a relationship," and only the first is nearly free:
| Cost | What it takes |
|---|---|
| Add a predicate (validated, invertible, refusing near-misses) | Ontology data only — zero production Rust |
| Use one end-to-end (a producer writes it, a consumer reads it) | Ordinary code. The merge that wired one of those pairs into producers and guards touched 13 files / 1,283 insertions |
| Roll out | The validating server must rebuild. Single-writer, so it cuts both ways: the vocabulary changes fleet-wide atomically, with no version skew between agents — and there is a restart window on one process to plan around |
The second row is where your engineers will actually live, and the third is an operational property you should know before adopting anything with a single writer.
2. The trap we had to test our way out of
Here is the failure mode that almost nobody guards: after a data-only vocabulary edit, the pre-existing test suite passes whether or not your new predicates loaded at all. Green proves nothing broke; it does not prove anything arrived. The load-path guard is deliberately one-directional (the ontology may grow), so a silently-ignored predicate looks exactly like a successful one.
So every added pair ships with a test that goes red when its ontology block is removed — decision_obligation_pairs_are_loaded_from_data_only and its siblings in src/relation_vocab.rs. Clone the repo and run cargo test: those guards are the part you can check for yourself. The +43 / +19 / 13-file wiring figures are commit-pinned measurements from our private fleet repo, and we label them as exactly that.
3. The dogfooding is evidence, not a benchmark
This engine is not a demo extracted from slideware. It runs the live multi-agent development fleet that builds it — our monorepo pins arrow-kanban and arrow-kanban-server as dependencies, and in our deployment, arrow-kanban served the boards used to coordinate, review, and merge the vocabulary changes described above. It is evidence the engine works at one fleet's scale, not a scalability benchmark.
What this is not
arrow-kanban has no opinion about what work means. No built-in governance model, no workflow doctrine — those belong to the application embedding the engine. That is a design decision, not a gap: it is why the engine stays generic enough to open-source while the systems built on top of it stay ours.
If any of this is useful to you, the README leads with the same differentiators and links into the durability contract and extension guide. Contributions go through reviewed pull requests — the same discipline the fleet applies to itself.