Skip to main content

Where Verdict fits and how to reason about the whole system

Objective​

Place Verdict correctly as the coming-soon defend layer without overstating it, and reason about the fully assembled fabric as one system: its failure modes, its topologies, and its boundaries.

Concept​

You have assembled Zift, Writ, the PDP, and Herald into a working pipeline. Two things remain for an architect: where the fourth product goes, and how to think about the whole rather than the parts.

Verdict: the defend domain, coming soon​

Verdict is the agentic firewall, the fourth domain of the fabric. It is coming soon; describe it as future, never as shipping behavior. Its role is human-in-the-loop defense: for a high-risk action, the decision is not simply allow or deny but "allow, subject to a human approving." In policy terms that is an obligation the PEP must satisfy before it honors the decision, the same shape as the break-glass "notify the privacy officer" obligation you have seen.

The seam is already visible in the lab. An admin exporting a restricted record is exactly the kind of high-blast-radius action a human should confirm. Today the policy allows it outright; a Verdict-style design would attach a require-human-approval obligation and let the firewall hold the request until approval. The "going further" exercise in the lab README has you model that obligation so you can see where Verdict plugs in.

Reasoning about the whole system​

An architect evaluates the assembled fabric on properties the individual courses could not show:

  • Fail-closed by construction. The policy is default allow := false. If Herald cannot federate a required context field, the guarded rule simply does not fire and the decision denies. A missing signal is a denial, not an accidental allow. Confirm this is true of every rule you added.
  • Topology choice is an architecture decision. The same policy and bundle run under a sidecar PDP, a centralized PDP, an Enterprise-OPA masking deployment, an AI-MCP gateway (workload mTLS), or an admission controller. Topology changes the latency budget (sub-5ms to under 50ms) and the blast radius, not the policy. Writ promotes the same signed bytes regardless.
  • One artifact, one source of truth. Because Zift extracts to Git, Writ governs Git, and the PDP runs the signed result, there is exactly one place the authorization lives. That is what makes replay meaningful and audits answerable.
  • Boundaries stay crisp. Writ governs but never decides. Herald fronts but never decides. The PDP decides but never governs. Zift assesses but never runs at request time. Keeping these straight is the difference between an architecture that scales and one that quietly puts the control plane on the request path.

Hands-on lab​

Return to your green suite and do the Verdict-seam exercise from ../lab/README.md: add an obligations contains "require-human-approval" rule that fires when an admin exports a restricted record, then add one test asserting the obligation is present for that request and one asserting a plain internal read carries no obligation. Run:

git clone https://github.com/EnforceAuth/university-labs.git
cd university-labs
opa test courses/capstone-four-product-fabric -v

You are modeling, in plain Rego, the hand-off where the agentic firewall will attach. Note what you did not have to change: the allow rules, the bundle shape, the masking. Verdict adds an obligation at the enforcement seam; it does not rewrite the decision or the control plane.

Check for understanding​

  1. State Verdict's role in one sentence and label it correctly as to availability. In policy terms, what construct expresses "allow, but a human must approve first"?
  2. Herald fails to federate change_ticket.status for a restricted request. What decision does the fabric return, and which property of the policy guarantees it?
  3. A teammate proposes routing every request through Writ so it can "see and approve" decisions centrally. Explain why that breaks the architecture and which component should be doing that instead.