About the role
Kanan Labs has a constitution, an enforced type system, a working signing chain over a sealed slice, and a green test suite. It does not yet have a running product. The distance between those two facts is this job.
That is an unusual starting position and we think it is a good one. The opinionated, easy-to-get-wrong decisions have been made and are enforced in CI. What remains is building, not re-architecting. You will spend the first eighteen months with your hands in the code rather than in a management calendar.
The hard problems are real and we will not pretend otherwise. Signing coverage is honest over one slice and not yet at scale. Determinism holds until it crosses a hosted vendor boundary. Privacy and data residency have no owner, and the first genuine exporter document that arrives turns that into a legal question rather than an engineering one. The knowledge substrate will not survive two orders of magnitude and everybody here knows it.
A note on what this is not. It is not a management role for at least eighteen months — there is no team yet. It is not a research position; papers are welcome, shipping is the job. And it is not a rebuild. You will disagree with things here, we want that, and there is a written amendment mechanism for exactly that purpose — but if your first instinct on inheriting a system is to replace it, this will not suit either of us.
What you’ll do
- The typed primitive families and the type system that enforces them — including the parts you will decide are wrong.
- The compiler: product-agnostic primitives compiled into signed, versioned, product-aware rule packs that a downstream engine executes.
- Determinism and replay. Byte-identical output from identical inputs, or a written reason why not.
- The signing chain — Ed25519, canonicalisation, hash-chained append-only ledgers — and making the coverage honest rather than partial.
- Privacy and data residency architecture. Currently unowned, and the highest-severity item on the list.
- The knowledge substrate decision, and the retroactive recompilation that has to survive it.
What we look for
- You have maintained a rule base, schema, taxonomy or standard across a real amendment cycle — and can tell us precisely what broke the first time.
- Expert-level Python, and a genuine preference for typed contracts over flexible dictionaries.
- You can explain without prompting why a 99%-accurate non-deterministic component is worse than a 90%-accurate deterministic one in a system whose output must survive an adjudication.
- You have shipped inside a standards-bound regime — FHIR, SNOMED, XBRL, ISO 20022, ONDC or Beckn, PCI — where the specification sat upstream of your opinion and you were fine with that.
- You can hold a boundary you disagree with while you argue properly to change it.
Nice to have
- Deontic logic, defeasible reasoning, or any serious exposure to knowledge representation for law.
- LegalRuleML, Akoma Ntoso, Catala, OpenFisca, s(CASP), or the rules-as-code world generally.
- Applied cryptography for evidence — canonicalisation, non-repudiation, replay defence.
- Compiler or intermediate-representation design. Bitemporal data modelling.
- Any familiarity at all with customs, trade or insurance regulation. Genuinely optional — the founder supplies this.