Loading...
Common questions from engineering leaders, security teams, and operations stakeholders evaluating GreenLightz.
An Evidence Case is the case-level container that answers six questions on the record for one important AI-agent action: what happened, what was required, what was observed, what was missing, who approved it, and which policy produced the verdict. It is opened when the deployer's instrumentation posts an AgentEvent to /v1/agent-events; the engine seals a reviewer-replayable evidence packet inside the case at verdict time. The verdict itself is returned by the parallel /gateway/evaluate seam; /v1/agent-events opens and seals the Evidence Case container that binds the verdict, evidence packet, and reconstructor context together. See docs/pivot/GATEWAY_VS_V1_SEAM.md. NOT legal or audit proof.
The Evidence Case is the container; the evidence packet is the reviewer-replayable snapshot the engine seals inside the case at verdict time. A single case can accumulate more than one packet as an action progresses (initial evaluation, approval resolution, retention expiry). Buyers and reviewers work with the evidence_case_id as the primary handle (per ADR ONT-10 canonical ontology; `case_id` remains accepted as a legacy alias until 2027-01-12); the packet_id + packet_hmac_sha256 are the tamper-evidence layer.
AgentEvent is the JSON record your instrumentation posts to POST /v1/agent-events: action_type, tenant_id, actor_id, target_id, action metadata, correlation_id. Identifiers are HMAC-hashed with per-tenant keys before storage; 18 known PII field-name aliases across 11 families are rejected at the top of the request payload AND one dict level deeper, plus SSN/PAN/email regex value scanning on payload string values, HTTP 400 with PII_METADATA_BLOCKED before the engine sees the body. The engine materializes the AgentEvent into an Evidence Case, evaluates it against the signed policy, seals an evidence packet, and emits the evidence_case_id (canonical per ADR ONT-10; `case_id` retained as legacy alias until 2027-01-12) + packet metadata in the response.
No. Evidence Cases are operational governance signals — tamper-evident, replayable, and policy-linked, but NOT legal attestation, NOT third-party audit opinion, and NOT a regulatory determination. Your auditor or counsel decides admissibility and sufficiency on their own terms. This is the same non-claim you will see at the top of every buyer-facing page.
GreenLightz evaluates AI-agent actions instrumented via /v1/agent-events — refunds, discounts, delivery promises, subscription extensions — against your company's signed policy in real-time. Scope boundary: only actions your instrumentation posts to /v1/agent-events (Evidence Case seam) and/or /gateway/evaluate (verdict seam) are captured; actions outside both paths are not seen. Each captured action opens an Evidence Case that answers the six questions on the record; the engine returns a verdict (ALLOW, REQUIRE_APPROVAL, or BLOCK) before the action takes effect.
The governance engine is fully deterministic — rule-based, not ML-based. Same input plus same policy equals the same verdict, every time. No LLM or AI model is involved in any governance decision, and there is no external LLM in the pivot slice (AgentEvent ingestion, Evidence Case materialization, verdict evaluation, and sealer are all offline-first). This makes verdicts reproducible, auditable, and explainable.
Nine built-in action categories: refunds and credits, discounts and offers, delivery promises, subscription extensions, SLA commitments, data handling pledges, support response commitments, policy exceptions and overrides, and goodwill remedies. Each is evaluated against per-action-type ceilings, aggregate thresholds, and velocity patterns before the Evidence Case is sealed.
GreenLightz can support your team's review of AI-agent actions through reviewer-ready evidence packets that record what the agent attempted, what policy applied, and what verdict was produced. This is NOT a claim of AI work correctness, model output validation, or reasoning-quality assessment. The verification surface is bounded to the policy-evaluation seam.
Yes, bounded to the policy-linked agent action seam. GreenLightz records which obligations a policy declared, which steps were observed, and which were missing. The reviewer interprets the conformance signal. This is NOT a claim of complete process compliance across your organization.
The system is fail-closed. Any error — network, storage, or internal — results in BLOCK or REQUIRE_APPROVAL. By design, a system failure does not produce a false ALLOW for your AI agent.
Designed for sub-millisecond evaluation overhead. P99 under 1 millisecond in our benchmarks. We measure the actual impact in your environment during the pilot.
No. The core evaluation engine has zero external runtime dependencies. It works fully offline — no LLM calls, no third-party APIs, no network dependencies in the evaluation path.
Yes, when advanced governance is enabled for your tenant. If your agent platform provides structured conversation signals — such as urgency indicators, manipulation scores, or escalation patterns — GreenLightz evaluates them deterministically alongside the commitment itself. High-risk conversational patterns automatically escalate the verdict. By default, the engine evaluates financial thresholds, velocity patterns, aggregate exposure, and repeat-pressure detection. Advanced signal evaluation is enabled during pilot setup when needed. No LLM is used in any evaluation path — all evaluation is fully deterministic and sub-millisecond in internal benchmarks (actual impact measured during pilot).
Two thin HTTP seams (both stateless JSON, no SDK). /gateway/evaluate returns the deterministic verdict + intervention plan your agent conditions on; /v1/agent-events opens the reviewer-replayable Evidence Case container that binds the verdict, evidence packet, and reconstructor context together. Any language that speaks HTTP can integrate — no SDK or agent framework lock-in required. The pivot Evidence Case seam /v1/agent-events is dark-flag gated at deploy time via GLZ_PIVOT_V1_ENABLED (returns 503 UNSUPPORTED_ROUTE when off). Compatibility diagram: docs/pivot/GATEWAY_VS_V1_SEAM.md.
Typical integration takes 1-2 days. Most teams wrap the API call in a single helper function. We provide JSON Schema contracts and TypeScript type definitions for code generation.
AgentEvent ingest rejects 18 known PII field-name aliases across 11 families (email, phone, ssn, address, credit_card, ip_address, name, dob, passport, license, mrn and their paired variants) at the top of the request payload AND one dict level deeper. Payload string values are additionally scanned for SSN (\d{3}-\d{2}-\d{4}), 16-digit PAN, and RFC-5322 email patterns — matches are rejected with PII_METADATA_BLOCKED at 400. Free-form commitment text is accepted, stored ephemerally, hashed into the tamper-evident chain, and is NEVER echoed in HTTP responses, audit-log metadata, or structured telemetry. Use opaque identifiers upstream — post the hash, not the PII.
All identifiers are SHA-256 hashed with per-tenant HMAC keys before storage — non-reversible. No PII is ever stored. Evidence packets are tamper-evident via content-hash chain; HMAC signing attaches when an operator signing key is configured.
Over 8,300 governance test cases across multiple suites — policy evaluation, disclosure governance, operational readiness, integration contracts, and end-to-end simulation. Key governance and claim-boundary test suites are CI-gated for release. The exact suite inventory (which suites, which counts, which are CI-gated vs advisory) is provided during technical review, so the number ties to a producible artifact rather than a marketing figure.
Six specific hardening controls are enforced in code for the current bounded scope: (1) fail-closed verdicts on error, timeout, or ambiguity; (2) deterministic decisioning — same input plus same policy equals the same verdict; (3) per-tenant HMAC key isolation on identifier hashing; (4) content-hash chained evidence packets (tamper-evident locally); (5) optional HMAC-signed packets when an operator signing key is configured; (6) PII-key rejection at ingestion — 18 aliases across 11 families at the top of the request payload AND one dict level deeper, plus SSN/PAN/email regex value scanning on payload string values, HTTP 400 with PII_METADATA_BLOCKED before evaluation. No external third-party security audit has been completed; an external audit is in planning. We can walk through the specific tests that gate each control under NDA.
Typically 2-4 weeks. Setup takes 1-2 hours on Day 0. Week 1 runs in shadow mode (evaluate but don't block). Weeks 2-3 run in live mode with real governance. A structured review session closes the pilot.
Starting at $3,000 USD for a 4-week pilot engagement. Includes shadow mode, live governance, structured review, and a full evidence report. Final pricing depends on evaluation volume and scope — we'll confirm during the demo call. (Draft for counsel review: all amounts denominated and payable in US dollars.)
Draft for counsel review: the current pilot is United States-domestic and US-dollar only. All fees, quoted amounts, and contractual limits are denominated in US dollars and payable in US dollars. The service is offered to United States-domiciled business entities for use within the United States. International or multi-currency support is not on the current pilot scope; please raise non-US interest with us and we will discuss whether a future engagement makes sense.
No (draft for counsel review). The current pilot offering does not include a service level agreement, uptime guarantee, response-time commitment, or service credits. The service is provided on a commercially reasonable best-effort basis. The governance engine is Offline-First and fail-closed by design — on error, timeout, or ambiguity it returns BLOCK or REQUIRE_APPROVAL rather than a permissive ALLOW — and Customer is responsible for engineering its integration to tolerate transient unavailability without harm to its end users.
No (draft for counsel review). GreenLightz makes no representation that it carries professional indemnity, errors and omissions, cyber-liability, or any other insurance covering the service. Liability under our Terms is contractually capped (see Terms Section 9). Customer must not treat any statement on this site, in our documentation, in our marketing material, or made by our personnel as a representation that the service is insured.
No (draft for counsel review). GreenLightz does not offer source-code escrow, open-source-on-shutdown, or a perpetual-hosting guarantee. Continuity is instead provided through Customer's right at any time to request export of its evaluation history, policy packs, and audit trail in a machine-readable format (see Privacy Policy Section 7 and Terms Section 10), so Customer can move that record off the service on its own timeline.
Yes. Start in shadow mode — GreenLightz evaluates in parallel but doesn't block your agents. You see what would happen without any impact on live operations. Switch to live governance when you're ready.
The reviewer export bundle structurally aligns with SOC 2 Trust Services Criteria (CC1, CC4, CC6, CC7, CC8) — signed policy packs map to CC1.4, chained audit logs map to CC4.1, encryption-key provenance maps to CC6.7, and incident-response data (audit_dropped_count, fail_closed_total) maps to CC7. We don't substitute for an attestation, but the bundle is structured so your auditor finds what they expect.
Only SHA-256 hashed identifiers with per-tenant HMAC keys are persisted at the reviewer surface. AgentEvent ingest rejects 18 known PII field-name aliases across 11 families at the top of the request payload AND one dict level deeper; payload string values are additionally scanned for SSN, 16-digit PAN, and RFC-5322 email patterns and rejected with PII_METADATA_BLOCKED at 400. Free-form commitment text is accepted, stored ephemerally, hashed into the tamper-evident chain, and is NEVER echoed in HTTP responses, audit-log metadata, or structured telemetry; ephemeral event-store retention is opaque to external observers and expires within tenant retention window. Reviewer bundles include a retention-policy summary + PII-pattern inventory + data-subject-rights applicability statement. Your DPO can verify the boundary directly.
Bundle alignment is documented for A.5.1 (policies), A.5.34 (PII protection), A.8.2 (privileged access), A.8.3 (access restriction), A.8.5 (secure auth), A.8.15 (logging), A.8.16 (monitoring), A.8.20 (network security), A.8.28 (secure coding), and others. Some controls (A.5.30 business continuity, A.8.13 backup) are production-dependent and disclosed as such.
Every policy deploy and rollback emits a POLICY_DEPLOYED audit event with the actor, timestamp, and chained hash. The /portal/audit page filters these for the reviewer's date range. Calibration signoffs are recorded as their own event type with the customer-acknowledged HMAC signature.
Default retention is 180 days per evaluation. Configurable per-tenant. Expiry is enforced by a scheduled retention task that emits APPROVAL_EXPIRED audit events for any in-flight approvals it transitions, preserving the audit trail for compliance review.
Yes. Tenant ID is the discriminator on every query — list_by_tenant() filters at the SQL level. Cross-tenant enumeration was security-class audited (A171-A173) and is concurrency-stress tested with 5 tenants × 10 concurrent writers. Identifiers are hashed with per-tenant HMAC keys, so even at the hash level tenant data cannot be cross-correlated.
GreenLightz produces tamper-evident local evidence packets (content-hash chain + optional HMAC signing) that may support your team's audit preparation work. The packets are NOT audit-grade evidence. Your auditor determines admissibility, sufficiency, and methodology.
No. GreenLightz does not claim EU AI Act compliance, regulator-readiness, or any legal determination. GreenLightz can help organize evidence — including action inventory, data-flow inventory, autonomous-verdict lineage (with human-approval lineage attached only when the customer has configured the optional human-in-the-loop workflow), and policy-version lineage — that you and your counsel may use during your AI governance review. Interpretation of any regulatory framework is yours and your counsel's, not GreenLightz's.
Only applies when the customer has opted into the optional human-in-the-loop workflow (the engine's REQUIRE_APPROVAL verdict is deterministic and terminal on the wire regardless). For customers who have enabled that workflow, the expiry behavior is per-tenant configurable: notify_only (just expire + notify, default), auto_reject (transition the approval row to REJECTED with explicit audit), or escalate_supervisor (notify supervisor role for re-queue). The actual mode that fired is recorded on the approval row as expire_action_applied so the operator portal shows you which path was taken.
audit_dropped_count is exposed at /gateway/analytics/health and via Prometheus audit_dropped_total counter (multi-worker safe). Every audit failure increments it. Operator sees count > 0 and can investigate before the audit-integrity gap accumulates. The metric is labeled by event_type so you know WHICH events are dropping.
All persistent state (policy packs, evidence packets, approvals, audit) is on SQLite or Postgres — restart-safe. In-flight HTTP requests fail with a transient error (caller can retry); no evaluation state is held in memory across requests. The retention scheduler resumes from where it left off based on persisted expires_at timestamps.
Yes for read-heavy workloads + Postgres backend. For SQLite-backed pilots, single-worker is recommended (the GOVERNANCE_PROFILE env var enforces this in production-like mode to prevent multi-worker SQLite footguns). expire_stale() is concurrency-safe across workers — only the worker whose UPDATE compare-and-set wins emits the audit event, so no duplicates.
Yes. The /portal/policies page exposes rollback for any tenant's deployed policy pack. Rollback emits POLICY_DEPLOYED audit (with rollback intent), reverts to the previous SIGNED version, and is HMAC-bound to the deploy actor. Past evidence packets continue to reference the policy version that was active when they were produced — they don't change.
Operator-visible signals at /portal/analytics: fail_closed_total (verdicts where the engine fail-closed due to error), audit_dropped_count (audit emit failures), policy_verification_failed counters (HMAC mismatch on policy load), and per-tenant evaluation volume + verdict trend. Plus the /portal/audit page surfaces every governance event with formatDetail rendering per-event-type.
Your portal includes a one-time guided calibration flow. You answer a tiered question bank (essential first, then advanced and high-risk when relevant) about your commitment boundaries, then judge boundary scenarios (just-below, at-threshold, just-above) for each calibrated knob. Our deterministic compiler converts your answers into a signed policy pack — no AI is involved in policy generation. Typical setup takes 30 to 90 minutes.
Run a new calibration session. The prior signoff is preserved with status SUPERSEDED for audit lineage; the new signoff atomically deploys a new policy version. Previous evidence packets remain intact and continue to reference the policy version that was active when they were produced.
Runtime evidence packet references the deployed policy version. The policy version links to the calibration session via two audit events (POLICY_DEPLOYED + CALIBRATION_SIGNED_OFF). The calibration session contains the customer answers, scenario decisions, signoff actor, signoff timestamp, and HMAC signature. Your auditor can trace any auto-allow back to a specific customer-approved boundary in two hops.
No. Calibration is explicit, customer-acknowledged, and signoff-gated. The compiler is pure deterministic dictionary mapping with no LLM at runtime. Unresolved customer conflicts fail closed to REQUIRE_APPROVAL — they cannot silently become ALLOW. Operators must explicitly acknowledge unresolved conflicts before signoff.
Yes. Your calibration includes a forbidden_phrases list (e.g., 'lifetime guarantee', 'medical advice', 'no questions asked refund'). The evaluator pre-gate checks every commitment's text against your list using Unicode-normalized, whitespace-tolerant, word-boundary aware matching. A match blocks the commitment with a traceable reason.
30-minute demo. We'll walk through the product, answer your specific questions, and discuss how GreenLightz fits your use case.
Book a Demo