Loading...
A deterministic policy evaluation engine that opens an Evidence Case for every AI-agent action posted to /v1/agent-events per your instrumentation contract, evaluates it against the signed policy, and returns a reviewer-ready evidence packet in one API call. Minimal latency overhead. Zero external runtime dependencies.
An Evidence Case is the case-level container that answers the six questions for one AI-agent action. The evidence packet is the reviewer-replayable snapshot the engine seals at verdict time and stores inside the case.
Four category boundaries, stated on the record. Each row lists what we do, the qualifier that bounds it, and one explicit non-claim.
We record what an AI agent said, offered, or promised to a customer at the moment it happened, along with the policy version that was in force.
The record covers agent commitments your team routes through /gateway/evaluate (verdict seam) and/or /v1/agent-events (Evidence Case ingestion seam); actions outside both paths are not captured.
This is not a general LLM-behavior monitor, and it does not verify anything the agent thinks or plans internally.
We evaluate each recorded commitment against your signed policy pack and return a deterministic verdict (ALLOW / REQUIRE_APPROVAL / BLOCK) with the rule set that fired.
Conformance is measured against the policy you calibrated during onboarding, not against any external standard or external certification.
This is not a certified compliance-management system, and it does not replace your internal control framework.
Each evaluation produces a tamper-evident evidence packet with content-hash chaining that operational reviewers and dispute reconstructors can inspect after the fact.
The packet is designed to help your team prepare for internal review and customer disputes; format and disclosure fit the operational-review use case.
This is not evidence signed by an audit firm, and it does not substitute for a formal audit engagement or a legal proceeding.
Our design principles (deterministic evaluation, tamper-evident evidence chain, single-tenant isolation, USD-only pilot scope) align with several themes discussed in the EU AI Act.
Alignment with themes is a design posture; we track the regulation as it evolves and adjust the roadmap accordingly.
This is not an EU AI Act certification, we do not sell a compliance guarantee tied to the Act, and no third party has attested that the product meets the Act's obligations.
See every AI-agent action your team posts to /v1/agent-events before it reaches the customer, with the Evidence Case answering what happened, what was required, and who approved it. Set monetary ceilings and approval thresholds per action type — no code changes needed. Scope is bounded by your instrumentation contract, not by claim of universal visibility.
One API endpoint, any language. JSON Schema contracts for type generation. Minimal overhead. No SDK lock-in, no agent framework dependency.
Tamper-evident evidence for every evaluation; HMAC signing attaches when an operator signing key is configured. Zero PII in HTTP responses, audit-log metadata, or telemetry; ephemeral event-store retention is opaque to external observers and expires within tenant retention window. Fail-closed by design — system errors never produce false approvals.
JSON Schema (Draft-07) contracts are available during pilot for TypeScript, Python, Go, and Java code generation. Additive-only stability guarantee — fields are never removed or renamed.
The response shape below is the simplified public API surface. The full replayable evidence packet (integrity chain, calibration lineage, replay inputs) is shown on /sample-packet.
{
"action_type": "credit_or_refund.issue",
"tenant_id": "acme_corp",
"actor_id": "agent-7b",
"target_id": "customer-4492",
"amount_cents": 15000,
"currency": "USD",
"reason": "Product arrived damaged",
"correlation_id": "conv-8812-msg-3",
"metadata": {
"original_transaction_id": "txn-9284"
}
}{
"verdict": "REQUIRE_APPROVAL",
"evidence_ref": "ev-8a3f2b91-c7e4-...",
"evidence_hash": "sha256:b94d1f2a3e5c...",
"reasons": [
"Amount $150.00 exceeds pre-authorized limit $75.00",
"30-day customer aggregate: $420.00"
],
"policy_version": "v1.3.0",
"evaluated_at": "2026-03-02T14:30:00Z",
"signed": true,
"intervention_plan": {
"action": "modify_and_retry",
"band": "amber",
"recommended_client_behavior": "MODIFY_AND_RETRY",
"safe_degrade_actions": [
"lower_amount"
],
"retry_guidance": {
"max_retries": 3,
"cooldown_seconds": 0,
"stop_condition": "action_allowed_or_max_retries_exhausted"
}
}
}The sample above is the verdict seam. The equivalent Evidence Case ingestion body (posted to /v1/agent-events, gated by GLZ_PIVOT_V1_ENABLED) is documented in docs/external/API_QUICKSTART.md §2. Legacy verdict seam and pivot Evidence Case seam are parallel Flask blueprints — see docs/pivot/GATEWAY_VS_V1_SEAM.md.
"signed": true in the response above represents a tenant with evidence signing configured. The full replayable packet schema is shown in the sample evidence packet.
Same input always produces the same verdict. The decision path is fully traceable through the tamper-evident evidence packet — replayable against the signed policy for operational review and dispute reconstruction.
ALLOWAction is within all policy bounds. The agent proceeds without modification.
REQUIRE_APPROVALAction exceeds a soft limit. The intervention planner returns a concrete modification — reduce amount, adjust scope, or degrade gracefully — and the agent retries automatically.
BLOCKHard policy violation. The action is denied with a tamper-evident evidence packet documenting the exact rule that triggered the block.
amount_cents changes. The deterministic engine produces three different verdicts; same input would always reproduce the same one. safe_degrade_actions: ["lower_amount"].Works with any agent framework, any language. The only requirement is an HTTP client.
Before your AI agent executes any commitment, POST the action details to /gateway/evaluate for the deterministic verdict + intervention plan (verdict seam). To open the Evidence Case for reviewer replay, your instrumentation additionally POSTs the same action as an AgentEvent to /v1/agent-events (V1.1 Evidence Case seam, enabled at deploy time via GLZ_PIVOT_V1_ENABLED). Two thin HTTP calls, no SDK or agent framework required. See docs/pivot/GATEWAY_VS_V1_SEAM.md for the compatibility diagram.
The engine returns a deterministic autonomous verdict (ALLOW / REQUIRE_APPROVAL / BLOCK on the wire — the middle enum is a legacy wire-contract alias for AUTONOMOUSLY_RESOLVED_ESCALATED per ADR SEC #504 §7.3, retiring 2027-01-15), the policy rules that fired, and — for amber verdicts — a concrete intervention plan telling the agent how to modify and retry.
Your agent follows the intervention plan: proceed as-is, reduce the amount to fit within policy, or stop. The retry loop converges automatically — actions matching your pre-authorized policy receive an autonomous ALLOW (or a deterministic MODIFY_AND_EXECUTE-style automatic modification); boundary cases receive a REQUIRE_APPROVAL verdict that, if you have configured the optional human-in-the-loop workflow, routes to your operator queue.
Every AgentEvent your instrumentation posts opens an Evidence Case that answers the six questions: what happened, what was required, what was observed, what was missing, who approved it, and which policy produced the verdict. The engine seals a reviewer-replayable evidence packet inside the case with a deterministic content-hash chain; HMAC signing attaches when the operator configures GLZ_PIVOT_V1_HMAC_KEY.
Amber verdicts don't just say "no." They tell your agent exactly what to change. Your agent uses the intervention_plan to modify and retry — within policy bounds. GreenLightz returns the guidance; your agent code executes the loop.
The intervention_plan field returns machine-readable instructions: reduce amount, adjust scope, switch to draft mode. No free-form parsing needed.
The retry_guidance field specifies max retries and stop conditions. The loop converges to an approved action or stops cleanly — never infinite.
The safe_degrade_actions field lists exactly which modifications are safe: lower amount, reduce scope, require user confirmation. No guesswork.
Simple amount thresholds are easy to game. GreenLightz evaluates across multiple risk dimensions simultaneously — each one is a separate veto gate.
Per-action-type ceilings, pre-authorization limits, and daily caps. Different policies for different action types.
Per-agent, per-customer frequency tracking across configurable rolling windows. Catches agents making 5 refunds in one hour.
Rolling-window cumulative tracking. A $50 refund alone is fine — but $420 total from the same customer this month triggers escalation.
Stacking detection and precedent analysis. Catches when commitments are split across multiple small transactions to avoid ceilings.
Dimensions are configurable per tenant. Shadow dimensions let you observe new rules without affecting production verdicts.
Each tenant gets a YAML configuration file. Change the file, change the governance. No deployments, no code changes, no downtime.
max_amount_centsPer-action-type amount ceilings. Set different limits for refunds, discounts, and shipping commitments.
pre_authorized_limitAuto-allow threshold. Actions below this amount receive an immediate deterministic autonomous ALLOW verdict.
approval_modeLegacy wire-contract knob (canonical alias: resolution_visibility_mode, retiring 2027-01-15). Controls how the deterministic autonomous escalation verdict is surfaced: manual (all escalations visible in recovery center for optional post-hoc customer-configured review), pre_authorized (auto-allow under limit), or block (SAFE_BLOCK for all non-ALLOW). The engine emits a deterministic autonomous disposition regardless — human review is a tenant-configured optional workflow chosen before activation.
enabled_dimensionsWhich governance dimensions are active: financial impact, policy compliance, behavioral patterns. Add or remove to tune.
webhook_url / webhook_secretApproval notification endpoint. Secrets use env-ref indirection — never inline in configuration.
policy_versionSemantic version tag for drift detection. The engine tracks which policy version produced each verdict.
The same refund request can get ALLOW under one tenant's policy and REQUIRE_APPROVAL under another's. Swap the YAML file — no code changes, no deployments, no downtime. Thresholds and operational configuration are tuned together during pilot onboarding.
Set the boundaries once. Let agents move faster inside them. Calibration runs in the portal before your AI agents go live and converts your judgment into a signed, deterministic policy.
Pick which of the nine commitment types your AI agent makes (refunds, discounts, SLA, delivery, data handling, etc.).
Essential first, then advanced and high-risk when relevant. Includes forbidden language, escalation routing (feeds the optional human-in-the-loop workflow if you enable it), retention, and segment thresholds.
For each calibrated knob, choose ALLOW / REQUIRE_APPROVAL / BLOCK / NEEDS_CLARIFICATION for just-below / at / just-above and conflict cases.
Our deterministic compiler converts your answers into a signed policy pack. Unresolved conflicts fail closed to human review. No AI generates policy.
Every runtime evidence packet now carries the originating calibration session ID inside its aggregate state. Your auditor can reverse-trace any auto-allow back to the customer-approved boundary in one hop — plus a two-hop audit-event chain (POLICY_DEPLOYED + CALIBRATION_SIGNED_OFF) for cross-verification.
30-minute live demo. We'll walk through the API, fire real evaluations, and show the local evidence chain.
Book a Demo