License Circuit Breaker

Executable data-rights revocation with DataHub. Revoke one upstream right; contain and verify every affected descendant.

Comment

License Circuit Breaker supports compliance operations. It does not provide legal advice, interpret contract text, or determine whether a legal or contractual obligation has been met. It acts only on usage rights that an operator has recorded as structured data.

Inspiration

When an upstream data right changes, a red catalog row is not containment. An organization still has to find every represented descendant, decide what can be disabled or rebuilt, stop prohibited serving, preserve the parts that remain allowed, and prove what happened. That response is usually manual and fragmented across datasets, features, models, indexes, APIs, and exports.

I built License Circuit Breaker as the execution and verification layer after rights detection: turn a structured revocation into an exact, reviewable plan; refuse unsafe certainty; execute only what can be justified; and preserve evidence for everything else.

What it does

The workflow begins with a machine-readable rights event containing the source, prior and new purposes, effective time, reason, replacement source, and requester. It then:

  1. reads current downstream lineage and entity context from DataHub;
  2. classifies descendants such as datasets, features, models, indexes, services, and exports;
  3. applies a deterministic, first-match-wins rule table in which incomplete lineage outranks any confident containment result;
  4. produces a typed action and cites both the rule and lineage path behind it;
  5. requires human approval for the exact plan hash;
  6. executes idempotent actions against disposable local artifacts;
  7. verifies outcomes by probing the artifacts rather than trusting its own receipts; and
  8. writes per-artifact outcomes to DataHub and confirms every write by reread.

The public fixed scenario is deliberately honest: it executes the two actions that can be proved, runs four post-action probes, writes and verifies eight DataHub outcomes, and leaves five explicit escalations where the graph cannot justify an all-clear. A contained endpoint answers HTTP 451 so containment is distinguishable from an outage.

How I use DataHub

The DataHub MCP Server provides the lineage and governed entity context that determine impact. The project uses the DataHub Python SDK for supported globalTags and datasetProperties writeback, followed by immediate rereads. Every operation is restricted to the exact license.* allocation.

DataHub is also part of the safety model: incomplete represented lineage produces escalation, not guessed containment. The public reset restores disposable artifacts, preserves governance history, invalidates the previous approval, and requires a new decision cycle.

How I built it

The backend uses Python, FastAPI, Pydantic, NetworkX, DuckDB, scikit-learn, httpx, the DataHub SDK, and the MCP Python SDK. A React, TypeScript, and Vite console renders API decisions without making policy choices in the browser.

The deterministic rule engine owns the verdict. An LLM may eventually explain a decision, but it cannot decide whether enforcement is allowed. Approval is bound server-side to the plan hash, and changing the plan invalidates the approval. Execution is idempotent and evidence is organized by decision cycle so a later approval cannot relabel an earlier run.

Challenges I faced

The central challenge was refusing to convert missing lineage into false confidence. Escalation rules therefore have the highest precedence, and the demo itself ends with residual exposure rather than a cosmetically perfect result.

The second challenge was making a public workflow runnable without reopening arbitrary mutation. The hosted application issues short-lived, single-use confirmations for its fixed scenario, serializes execution, applies transparent cooldowns, hides fault injection and arbitrary targets, and preserves audit history during reset.

I also caught an evidence-cycle defect before the first live public mutation: a new rejection could have selected an older run using the wrong approval. I rolled back the candidate and added regressions so every displayed run remains tied to its original approval.

What I learned

Verification must probe the protected artifact, not merely confirm that an adapter returned success. I also learned that an escalation is a useful product result: preserving uncertainty is more credible than forcing every graph into a green verdict. Finally, approval identity and evidence identity must be modeled together; otherwise later decisions can accidentally rewrite the meaning of earlier history.

What I am proud of

  • The agent connects a rights event to executable and explainable downstream actions.
  • Exact-plan approval and fail-closed escalation are enforced server-side.
  • Independent probes verify both containment and preservation of allowed branches.
  • Eight DataHub outcomes are written and verified by reread in the hosted scenario.
  • The public experience is runnable without credentials while remaining fixed, bounded, and synthetic.

Limitations and what's next

The product does not detect licenses, interpret contracts, prove legal compliance, or claim that DataHub contains every real-world copy. The included adapters act on disposable local artifacts; production adoption would require authenticated approvals and organization-specific connectors. Next I would add richer policy simulation, owner notification, connector-specific rollback, and review workflows for promoting approved policies.

Built With

Share this project:

Updates