MandateGuard

An AI-native DataHub control plane that detects, quarantines, reconciles, and audits risky order and payment operations.

Comment

Inspiration

Order and payment incidents rarely remain isolated inside one table. A single mismatch can travel into settlement jobs, executive revenue dashboards, and financial decisions before an operator understands the full blast radius. Conventional reconciliation tools can find a bad row, but they usually do not know which downstream assets depend on it or where the resolution should be recorded for the next person or agent.

MandateGuard began with a simple question: what if an operations agent used DataHub context before taking action, rather than treating metadata as documentation that is consulted only after an incident? That idea led us to combine deterministic financial controls with DataHub discovery, entity context, lineage, and governed catalog updates.

What it does

MandateGuard is an AI-native operations data control center for high-risk order and payment workflows. Its MG-204 input contains 15 orders and 40 captured payments. The reconciliation engine computes 12 mismatched orders, 37 affected payment records, and $48,270 in exposure from those records. It identifies the unsafe records, stages quarantine, maps the affected asset and its blast radius, prepares 12 adjustment actions, and requires a human decision before quarantine, reconciliation, or catalog write-back is applied.

The scenario centers on finance.payments, with finance.orders upstream and two protected downstream assets: finance.settlements and executive_revenue. The operator can inspect evidence, follow the control stages, approve reconciliation, and review the resulting audit trail from one control-room interface.

The public demo is deliberately safe and instantly testable. It runs the policy agent against deterministic DataHub fixture responses, then applies reconciliation to the included sample payment records only after approval and verifies all 37 transitions plus zero remaining mismatches. It separately records three simulation receipts for the planned add_tags, update_description, and save_document catalog operations, so it never claims that the public demo changed a DataHub tenant.

How we built it

MandateGuard separates the interface, deterministic control logic, and DataHub access. The control room is built with React and TypeScript, while a dependency-light Node.js API owns the workflow. A pluggable gateway gives the public fixture and the connected DataHub path the same application contract, so the judge-facing experience remains reproducible without hiding the real integration design.

In connected mode, the gateway speaks Model Context Protocol over Streamable HTTP. A control run first calls tools/list to verify that the required capabilities are available. The policy planner then drives four explicit steps: search to discover finance.payments, get_entities to ground it, and get_lineage in the upstream and downstream directions. Every attempt is traced; transient reads can recover once; missing downstream lineage changes the decision to halt_before_quarantine. The displayed impact graph is constructed from those responses instead of from hard-coded connected-mode labels.

Mutations require a same-origin operator secret, explicit human approval in the control room, complete tool preflight, and the deployment-level DATAHUB_MUTATIONS_ENABLED switch. When enabled, the gateway can invoke add_tags, update_description, and save_document. Mutation calls are not automatically retried after HTTP or session failures. A successful receipt suppresses a duplicate operation only within the current Node process; there is no cross-restart guarantee and no guarantee for an ambiguously timed-out remote mutation. The public DataHub fixture records equivalent simulation receipts, while approval applies and verifies the 12 operational adjustments only in the included sample operations gateway.

We implemented the MCP client lifecycle, session reuse, JSON-RPC response validation, multi-event SSE parsing, tool discovery, read payloads, and mutation payloads. Automated contract tests exercise those calls against responses shaped to the official tool schemas. We then ran official mcp-server-datahub 0.6.0 end to end against a local DataHub Core Quickstart. The non-secret report captures the four traced reads, the entity before approval, successful add_tags, update_description, and save_document receipts, the entity after approval, and audit-document read-back. This is verified local MCP evidence, not a hosted tenant run; the public demonstration remains a deterministic DataHub fixture, and the operational record changes remain confined to the sample gateway.

Challenges

The hardest challenge was making the submission immediately usable while preserving a truthful boundary between a credential-free demonstration and connected evidence. A demo that required private tenant access would be difficult for judges to run, but a purely visual mock would not demonstrate the system architecture. The shared gateway contract solved that tension: the public fixture provides deterministic evidence and simulated catalog receipts, while the official local MCP run verifies discovery, entity context, lineage, and approval-time governed actions.

We also had to make risky operations explicit. Separating read-time impact analysis from approval-time mutations, checking the MCP tool catalog before a run, and requiring a second environment gate helped turn safety into visible product behavior rather than an assumption.

Accomplishments

We are proud of the complete, one-screen journey from record-derived anomaly detection to evidence, lineage-aware impact, human approval, applied adjustments, post-action verification, and audit. The UI exposes Observe → Plan → Act → Verify, the exact DataHub tool trace, and the negative branch where the agent refuses even to stage quarantine without a proven downstream boundary. The project is public, Apache-2.0 licensed, documented, tested, responsive, and accompanied by a deployed browser demonstration.

Most importantly, MandateGuard treats DataHub as part of the control loop. Metadata helps determine what is at risk before an action and becomes the place where governed resolution context can be preserved afterward.

What we learned

Metadata becomes operationally valuable when an agent can use it at decision time. Row-level evidence explains what failed; lineage explains what may fail next; entity context grounds the affected asset; and a durable catalog record lets future people and agents inherit the decision.

We also learned that a trustworthy agent experience needs clear mode labeling and layered authorization. A deterministic fixture is useful only when it is identified honestly, and a mutation-capable integration is safer when approval and deployment configuration are separate controls.

What's next

Next, we want to add DataHub assertions, configurable reconciliation policies, and configurable approval routing, and replace the process-local receipt ledger with persistent operation identities and remote outcome verification. We also plan to support refunds, chargebacks, and multiple payment providers. The same pattern can extend beyond payments to any high-value workflow where a local data failure has a larger downstream impact.

Built With

Share this project:

Updates