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.
ontologiq docs: the ontology rendered as one self-contained HTML page — entities, state predicates, governed actions, and the exact MCP tools each role sees — for the reviewer who will never read YAML.
ontologiq propose: a human initiating an action from the terminal, through the same role check, live precondition and durable queue the MCP path uses. Approval stays its own verb.
The workbench (ontologiq workbench): the ontology as a live page — the graph, definitions next to warehouse records with computed state, an action console with dry runs, the approval queue and the audit trail. Read-only plus dry-run by construction: no route proposes, approves or executes, and the socket binds loopback only.
DuckDB, end to end, with no credentials.
Adapters for Postgres, MySQL and Databricks, built on a shared DBAPI base where each adapter is only its connection policy. Postgres and MySQL are driven against live service containers in CI through the whole loop — including the re-validation refusal — and Databricks has passed the same smoke against a live serverless warehouse; the adapters page says exactly what is and is not proven.
ontologiq import dbt: scaffold objects/*.yml from a dbt project’s schema.yml or manifest — sources from models, properties from columns, unique/not_null tests suggested as identity candidates (commented, never guessed). No dbt runtime dependency. State and actions remain yours to write, deliberately: they are the part dbt cannot express.
ontologiq test: the data checks the ontology implies — identity uniqueness and completeness, relation referential integrity, state coverage — run read-only in the warehouse, counting rows without copying them out. build runs them, as its contract always promised.
HTTP transport with OIDC (serve --http): multi-user network serving where identity is verified per request — the role from the token’s role claim, the audit trail recording the token subject, sessions bound to their credential. Network serving arrived with OIDC, not with a flag: the transport cannot run unauthenticated.
ABAC on actions (policy.where): predicates over the object’s columns and actor.* attributes from verified token claims, evaluated at proposal and again at execution with the claims pinned. Only where identity is verified: stdio and the terminal refuse such actions rather than assert attributes they cannot verify.
Read-policy pushdown, Unity Catalog first (read_policy): a row predicate compiled into the deployed view using the warehouse’s identity functions (current_user(), is_account_group_member()), so the warehouse enforces it for whoever runs the query. Databricks only for now; validate refuses the field on other adapters rather than shipping a policy that looks enforced and is not.

Field reports from real schemas. The live smoke proves the loop on clean fixtures; your warehouse has composite keys, exotic types and permission boundaries the fixtures do not. Running an adapter against something real and reporting back is still the cheapest, highest-value contribution there is.

Approval in the workbench. OIDC opened the gate; the next step is the approval queue moving into the workbench for verified users. Until that lands deliberately, the workbench stays read-only and the terminal signs.

(On imports generally: being a runtime over foreign ontology formats is a non-goal. No open format carries source binding, identity and state predicates together, and without those the governed-action guarantee is not expressible — so Ontologiq imports and exports, but never interprets a foreign format live.)

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.
Policy pushdown beyond Unity Catalog	`read_policy` covers Databricks today by compiling the predicate into the view. Postgres RLS, Snowflake row access policies and BigQuery authorized views each need their own identity-function mapping, added deliberately.
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 stdio process, one role. By design: stdio cannot authenticate, so the process runs as the role it asserts. Multi-user serving is what serve --http with OIDC is for.

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:

Drive an adapter against a real schema. The live smoke proves the loop on clean fixtures; a field report — success or failure — from your actual warehouse, with its composite keys and permission boundaries, is the cheapest, highest-value contribution there is right now.
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.