Ontology and Object Types
You model your organisation at the level of meaning. A dataset can be promoted to an Object Type – a typed semantic object whose column markings are enforced when it is read. Object Types are what the rest of the platform reads, and what an AI tool connected to Kovac will read.
Policy and clearances
The policy core is pure, property-tested logic over identity, ontology and request. Object, action and deploy requests are checked against your policy today – three of seven routes to data – and most of that gating runs in the Go services, not the kernel. Three failure cases still proceed today when they should stop: a deploy on a policy error, an object read on a lookup error, and a plan that cannot be signed. Column clearances are enforced on record reads in Kovac (object reads); not yet on raw files or previews. Access control is policy-as-code and a permission graph, with time-boxed grants whose expiry is enforced; a grant is scoped per marking rather than per dataset, and by the end of November 2026 only your administrator or your Data Officer can issue or revoke one.
By whenEvery path to data goes through policy by the end of November 2026. Every route blocks a request when the policy check cannot run, by the end of November 2026. Clearances enforced on every read by the end of November 2026, and carried through pipeline transformations, computed server-side, by March 2027.
Signed execution
When the kernel is reachable, it signs plans, actions and grants with Ed25519. The kernel holds the signing key, so only the kernel can produce a valid signature; nothing verifies one yet. The signature covers the plan's id, intent and code hash – not its inputs and outputs. If the kernel is unreachable, the plan proceeds unsigned. A deploy is signed after it runs.
By whenNothing runs unsigned by the end of November 2026. Every plan signed before it runs, covering its inputs, outputs and permitted operations, and verified by the engine that runs it, by March 2027.
Decision records and time travel
Refusals on the routes Kovac checks are kept in a searchable record. Permitted requests are not recorded yet, and the record is not signed. Any signed-in user can add an entry today, so by our own guide's test the trail is a log. An approval is recorded against a plan, but not required: the plan does not wait for the approval before it runs. Ontology changes are versioned today.
By whenBy the end of November 2026, only Kovac itself can write to the record; by then, every entry is signed and linked to the one before it as it is written, permitted requests as well as refusals. Reconstructing the governed state at any past moment – ontology, policy and lineage – is on the roadmap, not dated yet.
The architecture boundary
The kernel holds the policy core and the signing key. AI and orchestration are designed to run as a governed client, with no special trust and with retrieval outside the kernel boundary. Kovac is designed to govern what runs, not how: it sits beside your warehouse and compute rather than replacing them. PostgreSQL and MySQL connect today, for schema discovery, and pipelines run on file data. Fields you mark sensitive are masked with placeholders before Kovac passes them to an AI model or posts them to another system.
By whenReading straight from your database tables by December 2026.