Known limitations

Two kinds of honesty: something described elsewhere that is not built yet, and a control that exists but does not yet reach as far as its name suggests. Each item was found by reading the code that would show it.

The process

• A Component tier for reusable patterns like de-duplication and PII handling, so a contract can reference one instead of restating it.
• Product-scoped requirement ids (REQ-CMR-001), which the current global grammar will need past one product.
• Scheduled automations with scoped write authority.

Known gaps

• Four-eyes on release approval. Approving and promoting both need release.promote; nothing yet checks that the person approving is not the person who cut the release — unlike the access decision, the access request and the integration-test sign-off, which all refuse the same hand.
• Sign-off needs a signed-in identity. The same-hand check on a data agreement's signature compares the signed-in principal, not the role, so in open mode — where nobody signs in — it cannot always tell two people apart.
• Switching role is not audited. Act as changes who the session acts as without writing an event to the audit log, unlike adding a person, inviting one, or changing a role, which all do.
• The first section of a data contract v0.1 needs an agent. Without ANTHROPIC_API_KEY the draft buttons are disabled, and there is no way to write that first document by hand — the upload a reviewer could use instead only appears once a document already exists.
• MCP counts steps its own way. The products tool's steps_complete is derived separately from the application's, and does not count the build or the integration-test sign-off — a live product can read 7/9 there and 9/9 in the application. The read API's /products agrees with the application.
• /decisions is linked from nowhere. The page lists every open access request and signature across every product, but no page links to it, and its access-request rows link to a step key the workflow does not define.

The agents

The three agent steps run against the model from the web application. python -m dpf demo still fakes the triage step with a fixed answer, so the worked example runs offline and identically every time.

Headless

The read API and MCP over HTTP exist (Read API and MCP). Not here: writes — a system or an agent opening a request, drafting or building — which would need agents to propose and only people to close a gate, recorded as such; webhooks, for which polling /api/v1/events from a cursor is the substitute; and machine identity beyond a token, such as an Entra service principal.

The warehouse

Nothing has run against a real Databricks tenant yet; the seed cannot be built into a non-DuckDB store, so dpf demo is DuckDB-only; a contract's mapping expressions are copied through untranslated; there is no OAuth or service principal beyond a token in an environment variable.

The quality push

Only the constraint set is applied; the DLT module and monitor definitions are printed for somebody to install. Drift is read back for constraints and not for the other two, because nothing was pushed there to drift from.

The trackers

Create only, against Azure DevOps Services and Jira Cloud, never yet against a real organisation. See Push to a tracker.