Roadmap and status

Ontologiq is alpha software built by one person. This page says plainly what is done, what is not, and what was left out on purpose — a deferred decision is not the same as an oversight, and the difference matters when you are deciding whether to depend on something.

Works today

The format: objects, identity, properties (bound and derived), state as ordered predicates, relations, inline governed actions.
The compiler: SQL views per object in the adapter’s dialect, catalog.json, and the MCP manifest.
The validator: cross-references, expressions, state-name typos, circular properties, tool-name collisions — all reported in one run with file, line and column.
The MCP server: read tools with sensitive-property withholding, state filters, clamped limits and honest truncation.
The action runtime: role checks, live preconditions, dry runs, a durable approval queue, webhook and handler effects with idempotency, and an append-only audit log.
DuckDB, end to end, with no credentials.

The visual workbench (ontologiq serve with a UI). A graph of the ontology, an object browser that goes from definition to live records, an action console showing evaluated preconditions and the approval queue, and a playground for the generated MCP tools. Read-only on the ontology — editing stays in Git, and a bidirectional graphical editor is explicitly not a goal.

The Databricks adapter. The package exists as a placeholder to keep the abstraction honest; making it real is the next adapter milestone, and the one that will prove whether the adapter protocol is the right shape.

ontologiq test. Declared checks — identity uniqueness, relation referential integrity, state coverage — runnable in CI. The verb exists and build already promises to include it, so the contract does not change under you when it lands.

Deferred, not dropped

Thing	Why it waits
State transitions (`from`/`to`/`via`)	The v0 predicates compute state from data. A transition graph with history belongs with a richer action runtime.
OSI export	Exporting aggregatable properties in Open Semantic Interchange format, so dbt, Snowflake and Cube can read them. Interoperability matters, but after the core is stable.
`packages.yml`	Ontology modules pulled from git by semver, dbt-style.
Multi-adapter projects	`source.adapter` is reserved in the schema; a differing value is a validate error rather than a feature that half-works.
HTTP transport with real authentication	Today the role is asserted by whoever starts the process. Multi-user serving needs OIDC and is a different security posture.
Policy pushdown	Compiling read policy into Unity Catalog row filters, Snowflake row access policies and BigQuery authorized views — enforcement in the warehouse, where it cannot be bypassed.
Schema introspection (`validate --with-db`)	Would let the validator catch unknown columns and type mismatches, and let identity comparison stop guessing.
Entity resolution across systems	Matching the same customer across SAP and CRM. Interesting, large, and not v0.
A package registry	`packages.yml` with git and semver is enough; a registry is a product of its own.

Known limitations

Worth knowing before you build on it:

Identity types are guessed. Without introspection, an identity value that looks numeric is compared as a number and everything else as a string. Leading zeros are handled ('0102' stays a string), but an exotic key type may still surprise you. Introspection fixes this properly.
show supports single-column identities only. Composite identities work everywhere else.
The mcp SDK is young. Version 2.0.0 is a recent, breaking rewrite of the low-level server; the pin is >=2.0.0,<3.
One serving process, one role. By design, until there is a transport that can authenticate.

Where help would matter most

The project is one person’s work so far, and these are the places where a second pair of eyes changes the outcome:

A second working adapter. Postgres or Snowflake would tell us whether the adapter protocol generalises or merely fits DuckDB, the only warehouse it has ever been driven against.
The format, used in anger. Model something real and tell us where the YAML fought you. Design feedback before 1.0 is worth more than code.
Security review. The governance claims in the security model are meant to be attacked. If one of them is not true, that is the most valuable issue you could file.
Warehouse-side policy pushdown, if you know Unity Catalog or Snowflake row policies well.

See CONTRIBUTING.md for how to get set up.

Versioning

Alpha: the format may change between 0.x releases. Breaking changes will be listed in the release notes, and ontologiq.yml carries a format: field so a future version can detect and migrate an older project.