The repo is the record
Facts live as plain files beside the code they describe. No database, no catalog service. Models in the repo, payloads where they belong.
Organizational knowledge, kept true by a compiler.
Who owns which service. What depends on what. Knowledge as code puts those facts in git, reviews them in pull requests, and lets a compiler reject the ones that stop being true. It makes modeled facts easier to review and maintain over time.
This approach is implemented in Cueto, open source on GitHub. Cueto is a system Stratorys built for its own use, not a client engagement, so this study documents a design and involves no client data and no client names.
Nobody lied. The facts just went stale.
A wiki can say Alice owns the billing service long after she has left. Write ownership as a typed reference instead of a string, and the reference can be checked against the people recorded in the system. Remove her from that record, and the build can fail in the same pull request.
Ownership as a typed reference
Alicein the roster, on the data team
Billing serviceowned by Alice, a reference and not a string
Alice leavesthe build fails until ownership is reassigned
How knowledge as code works.
Six pieces that turn scattered facts into a record a compiler can vouch for.
Your vocabulary
You decide what exists in your world, teams, services, datasets. Nothing is imposed, because people only maintain schemas they own.
Composition
Packages from different teams merge into one unified view with no central coordinator. The org-wide picture is derived, never written by hand.
The membrane
CI validates every change. References are typed against what actually exists, so a change that breaks one is rejected at the door.
Pipelines
Imports from HR systems, wikis, and warehouses converge into the repo, and pass the same checks as any human edit.
History and review
Git is the archive, the pull request is the review. Versioning did not need to be reinvented.
Knowledge checked as it changes.
The checks run on every proposed change. Agents and busy humans keep adding facts, and modeled references that become invalid can fail the build instead of drifting silently.
Adopting knowledge as code.
Adoption is incremental, and each step pays for itself.
01
Start with one domain
Pick the facts that go stale fastest, usually service ownership, and encode just those. One domain, a few files.
02
Turn on the membrane
CI checks every pull request from day one. Drift stops accumulating the moment the first check runs.
03
Connect the sources
Pipelines can import from the systems you already run, while changes remain subject to the same checks.
Encoding knowledge as code is hands-on work we take on in delivery engagements. For another system we designed and shipped, read the PR Triage design study.
Curious whether this fits your organization?
We will look at where your knowledge lives today and where encoding it would pay off first.