The technical reference

How Gradia works, in depth

The contracts behind capture, reviewed history, executable worlds, governed agents and independently checked release evidence.

Updated September 8, 202623 minute readSource-linked product guide

Interview or structured authoring and Observer follow distinct execution paths. Observer workflow receipts and Guard recordings require separate admission before they can support native evaluation claims.

In this guide · 14 sections
  1. From an interview to an executable environment
  2. Capture begins with an approved scope
  3. Events, sessions, cases and encrypted state
  4. Recovery and review preserve meaning across time
  5. AI proposes relevance; measured calibration gates automation
  6. Compiling reviewed evidence into a workflow world
  7. Time, visibility, replay and branches
  8. Governed model attempts and the Guard boundary
  9. Evaluators, calibration and native result admission
  10. Four primary policy-evidence lifecycles
  11. Worked synthetic workflow and deployment limits
  12. Capture continuation and current capacity boundaries
  13. September 7 implementation continuation
  14. Try the current Guard source

Gradia turns descriptions and selected observations of work into explicit, inspectable environments for agents. It stores the specification, permissions, execution conditions, observations and human decisions needed to assess a result. Its central architectural distinction is between what happened, what someone approved, what a model proposed, and what an execution actually demonstrated.

There are two implemented execution paths. The native path compiles a frozen specification into an environment and tasks, executes them through a gateway, and records episodes and grades. The Observer path turns reviewed case evidence and separately approved business rules into a deterministic workflow world. Both support evidence inspection; their receipts make different claims.

Data flow · each arrow names a transition, not automatic approval
  1. Interview or structured specificationFrozen Spec and EnvSpecIR
  2. Frozen Spec and EnvSpecIRGated build and fingerprinted environment
  3. Gated build and fingerprinted environmentNative run, episodes and grades
  4. Native run, episodes and gradesAdmitted assessment and evidence lifecycle
  5. Approved browser, desktop or service scopeObservations, sessions and cases
  6. Observations, sessions and casesExact human review of case evidence
  7. Exact human review of case evidenceSeparately approved workflow rules
  8. Separately approved workflow rulesCompiled workflow world and replayable runs
Inspect diagram source
flowchart TD
  A["Interview or structured specification"] --> B["Frozen Spec and EnvSpecIR"]
  B --> C["Gated build and fingerprinted environment"]
  C --> D["Native run, episodes and grades"]
  D --> E["Admitted assessment and evidence lifecycle"]
  F["Approved browser, desktop or service scope"] --> G["Observations, sessions and cases"]
  G --> H["Exact human review of case evidence"]
  H --> I["Separately approved workflow rules"]
  I --> J["Compiled workflow world and replayable runs"]

The diagram shows two paths, not an automatic conversion from a workflow-world receipt into a native grade or certificate.

1. From an interview to an executable environment

A workflow can start with guided discovery, a written brief or structured specification authoring. The backend records a versioned specification and validates an EnvSpecIR: the typed intermediate representation used by the factory and compiler. Relevant endpoints include POST /v1/specs/draft, the asynchronous POST /v1/projects/{project_id}/spec/author, and specification evaluation, critique and freeze routes.

Freezing through POST /v1/specs/{spec_version_id}/freeze requires explicit typed confirmation. The route validates the IR and rubric, rejects blocking critique findings when present, and prevents an already frozen version from being silently rewritten. A rubric must bind its criteria to assessable evidence; prose that merely sounds evaluative is insufficient. Sources: specification routes gradia/api/routes_specs.py, IR schemas gradia/schemas/ir.py, critique gradia/specs/critique.py.

POST /v1/builds starts from a frozen specification, its IR, a seed and applicable asset/version bindings. The factory runs gated phases. Failed phases halt the build; autonomy mode determines whether passed phases advance automatically or await human approval. The resulting fingerprint binds the IR, data assets and task specifications. Environment and task registration use that identity rather than treating a friendly name as a reproducible version.

The compiler emits deterministic files and separates task-facing material from grader-only expected answers. It also scans for exact answer-byte leakage. That is a concrete separation and check, not proof against every semantic information leak. Supported verifier implementations and skipped checks remain explicit. Sources: build routes gradia/api/routes_builds.py, factory pipeline gradia/factory/pipeline.py, compiler gradia/compiler/envcompiler.py.

The native RunService interacts with an environment through RunGateway, records Run, Episode and Grade data, and feeds report, comparison and certification machinery with their own admission conditions. A persisted report is therefore downstream of an identified execution path. One operational limitation matters: build history is durable, but the current factory pipeline object resides in the API process. A restart can leave a build requiring explicit recovery or a new build; it does not transparently resume every phase. Sources: run service gradia/runsvc/runner.py, gateway gradia/gateway/service.py, reports gradia/runsvc/report.py, certification gradia/runsvc/certify.py.

2. Capture begins with an approved scope

Observer is selective acquisition, not unrestricted surveillance. ObservationScopeEdition (gradia.observer.scope.v1) binds tenant, participants, devices, purpose, processing location, validity interval, retention, content mode and source identities. Each source binds its tenant/account and receiver rules. The strict models reject extra fields and invalid wire data. An event cannot acquire permission merely by claiming an old timestamp. Admission checks the grant at the current server time. Source: Observer contracts gradia/observer/models.py.

Receiver Implemented acquisition Important boundary
Browser extension Explicit Start, selected approved page, navigation/click/lifecycle metadata Exact HTTPS origin and pathname; no page text, titles, typed values, screenshots or automatic recapture after navigation/restart
Native macOS companion Start/Pause/Stop, selected signed application window, coarse interaction metadata; separately authorized screenshot review Entire selected window requires approval; supported browser applications are refused rather than treating application permission as website permission
Native Windows companion Start/Pause/Stop, exact executable and Authenticode certificate pins, one participant-selected window, coarse clicks and separately reviewed screenshots Windows 10 build 19041 or newer; native capture and signing are separately qualified; optional encrypted batch transfer with exact durable acknowledgement; manual export remains available
Service collectors Read-only requests against selected Slack, Microsoft Graph mail, Teams, Gong and Salesforce resources Explicit resource/account binding; no general discovery of everything a credential could access

Both native companions support explicit continuous batches while the app is open: five-minute/400-event/ten-reviewed-image limits, one pending batch, exact durable acknowledgment before rotation, and fresh source/window authorization before resuming. Transfer backpressure pauses capture and produces a coverage gap. Intent is memory-only and cancelled by restart, Stop, revocation or source change. This does not establish gap-free unattended operation or signed public distribution. See the continuous-capture receipt docs/product/OBSERVER-CONTINUOUS-BATCH-CAPTURE-2026-09-07.md.

The browser uses activeTab and scripting, verifies the canonical scope digest, and exports a bounded local queue. Although the shared schema names a rule field path_prefix, this receiver intentionally accepts an exact pathname. Query strings, fragments and encoded paths are refused. Its account selection is a participant assertion, not cryptographic proof of the account currently logged into a website. Source: browser receiver packages/workflow-observer-browser/README.md.

The macOS companion uses AppKit and ScreenCaptureKit on macOS 15.2 or newer. It checks bundle identity, signing team and the selected window. Screenshot mode uses a one-window filter, refuses unavailable or protected capture, and keeps the pending bitmap volatile until the participant masks regions and explicitly accepts it. Persisted pixels are encrypted and still require managed content review. It does not claim arbitrary screenshots are free of personal data, or that every embedded web view can be recognized. Sources: desktop companion packages/workflow-observer-desktop/README.md, native capture packages/workflow-observer-desktop/Sources/ObserverDesktop/NativeCapture.swift, desktop validation gradia/observer/desktop.py.

The Windows companion uses .NET 10 and WinForms. Its windows_rules bind an exact ASCII executable basename, executable SHA-256, Authenticode leaf-certificate SHA-256 and participant-selected window locator. WinVerifyTrust checks the host's existing trust/revocation cache. The adapter retains the process and executable handles and watches the original window lifetime, so a reused HWND or changed binary cannot silently become the approved surface. Changing focus pauses acquisition with a coverage gap. It observes coarse clicks, without retaining coordinates, keystrokes or window titles. Each explicit screenshot uses Windows Graphics Capture CreateForWindow for the retained source item, with no whole-display fallback. The user reviews and masks that volatile frame before local persistence. Sources: Windows companion packages/workflow-observer-windows/README.md, selected source packages/workflow-observer-windows/App/SourceWindow.cs, native screenshot packages/workflow-observer-windows/App/WindowSnapshot.cs.

Windows local state uses AES-256-GCM with a random key protected by current-user DPAPI, private filesystem access and an exclusive writer lock. Restart recovery stops capture; expired authenticated state is purged while corrupt state is preserved for explicit recovery/reset. Export uses the shared PBKDF2-HMAC-SHA256/AES-256-GCM desktop envelope and rechecks current scope and retention after the file dialog. Python validates the exact Windows evidence and routes accepted images through the same independent managed content and case reviews as macOS. Windows CI executes native storage/masking/UI checks, .NET-to-Python evidence interoperability, x64/ARM64 test packaging and tamper-refusing current-user installation. Those tests do not capture a customer application or establish signed public distribution. Sources: local vault packages/workflow-observer-windows/App/LocalVault.cs, platform checks packages/workflow-observer-windows/App/PlatformChecks.cs, cross-language verification scripts/verify_windows_observer_fixture.py.

Service adapters retrieve selected channel/thread, folder/conversation, call or Opportunity data. Optional text ingestion strips HTML and applies bounded redaction before creating a pending review artifact. Regex redaction is not exhaustive PII detection. Some provider APIs return unwanted body fields in memory even for metadata acquisition; these are discarded rather than persisted. Sources: connector scope and operation gradia/observer/connectors/README.md, adapters gradia/observer/connectors/adapters.py, content transformation gradia/observer/connectors/content.py.

3. Events, sessions, cases and encrypted state

CaptureSession identifies a period of acquisition with exact source/account/participant/device bindings. ObservationEvent (gradia.observer.event.v1) adds an event ID, sequence, occurrence time, kind and allowlisted metadata. ObserverExport (gradia.observer.export.v1) carries the scope digest, sessions and events. A case is a business process that can span many sessions and days; closing a browser session does not close the case.

Import is transactional. Identical redelivery is idempotent; an existing event ID with different bytes or a conflicting sequence fails closed. A rejected batch leaves no accepted prefix. Case memberships are included, excluded or needs_review; correction creates another decision edition instead of rewriting earlier evidence. Excluding an observation from one case does not pretend the permitted source observation never existed. Source: local store gradia/observer/store.py.

Managed operations live under /v1/projects/{project_id}/observer: scopes, receiver registration, imports, cases, memberships, editions and reviews. A receiver is separately registered against a project-bound service account and exact source bindings. It cannot appoint itself as a human reviewer. Source: managed routes gradia/api/routes_observer.py.

Managed storage serializes the local SQLite state and associated artifacts into an AES-256-GCM encrypted workspace. Authenticated additional data binds schema, organization and project, so moving ciphertext to another project fails authentication. GRADIA_OBSERVER_ENCRYPTION_KEYS supports a current write key and retained decryption keys. Project authorization, database context and PostgreSQL row-level security are separate controls from encryption. The current workspace is bounded to 32 MB; it is not an unlimited event warehouse. Source: managed storage gradia/observer/managed.py.

Transport and local storage are distinct. Production API traffic uses HTTPS. Desktop exports additionally use a passphrase-derived key, PBKDF2-HMAC-SHA256 with 600,000 iterations, and AES-GCM; the API decrypts and validates them in memory. Desktop local keys live in Keychain. Connector content is encrypted, while its local SQLite metadata and cursors rely on private file permissions and host protection. Offline receivers cannot guarantee immediate remote revocation or deletion while stopped; managed import rechecks authority, and API access plus worker sweeps enforce retention on managed evidence. Privileged host access and key custody remain operational responsibilities.

4. Recovery and review preserve meaning across time

A connector commits a page's deduplicated observations, pending outbox and cursor together. On recovery it drains that exact outbox before acquiring more. It acknowledges delivery only after event and artifact responses validate. Scope/configuration changes require a fresh binding; queued records cannot be relabeled into a newer grant. Rate limits create durable retry deadlines and coverage information rather than fabricated continuity. Sources: connector synchronization gradia/observer/connectors/sync.py, managed client gradia/observer/client.py.

A selected stream can be polled over multiple days or explicitly backfilled within scope and retention. That does not imply complete historical capture: for example, a reply to a Slack root outside a discovery window needs an appropriate selected-thread strategy. Graph delegated OAuth can renew an existing authorized grant with encrypted refresh-token rotation. Initial tenant consent, permitted API access and customer qualification remain external prerequisites. Source: OAuth operation gradia/observer/connectors/OAUTH.md.

A case edition freezes canonical bytes: source revisions and availability, sessions and gaps, admitted events, memberships and a cutoff. A digest identifies these exact bytes. Local CLI attestation is explicitly a local operator assertion. Managed review requires the authenticated workflow owner, current content reviews, resolved memberships and the exact current edition. Its receipt is gradia.observer.authenticated-case-review.v1.

This review attests to that recorded history and declared coverage. It does not prove complete capture or approve a simulator's rules. Late evidence, corrected membership, revocation or retention changes can make the current view stale. Historical receipts remain historical; they cannot authorize newly changed content through an unchanged label. The API reports human_verified only when the managed review is current.

5. AI proposes relevance; measured calibration gates automation

The AI routes under /observer/cases/{case_id}/ai implement policies, proposals, calibration and application. AssemblyPolicy defines the workflow, allowed stage vocabulary, include/exclude thresholds, minimum precision and predeclared heldout IDs. A proposal uses at most 200 business observations and bounded already-reviewed text. Screenshot pixels and hidden membership answers are not model input. Sources: assembly contract gradia/observer/assembly.py, AI routes gradia/api/routes_observer_ai.py.

The governed client records model/policy identity, prompt version/digest, evidence digest and seed. Output must name only supplied event IDs and allowed stages. Missing decisions abstain; invented IDs or malformed output are refused. A relevance score is a model score, not an established probability of correctness, and a suggested stage is not an executable causal rule.

Automatic membership application requires measured calibration. Predictions and related answer-revealing metadata stay hidden until the owner submits heldout labels. Include and exclude decisions are measured separately with a 95% Wilson lower confidence bound and minimum sample count. Defaults are thresholds of 0.95/0.05, minimum precision 0.90 and 30 decisions per class. These are configurable constraints, not evidence that a deployment already meets them. Offline fixture output cannot establish production calibration.

Application rechecks the exact proposal, current evidence and model policy; it preserves explicit human decisions. The resulting record still requires review and cannot issue human_verified. A successful calibration is bounded to its exact case/model/policy evidence, not a guarantee across future customers.

6. Compiling reviewed evidence into a workflow world

WorldPlan (gradia.observer.world-plan.v1) declares principals, source visibility, initial state/facts, terminal states, a virtual time interval, actions and rights. WorkflowAction declares source/target states, permitted actors, required event IDs, time constraints, typed preconditions and effects. Facts use bounded strings, integers, booleans or null; uploaded executable code is not accepted. Source: world compiler and runtime gradia/observer/universe.py.

The initial proposal is deterministic chronological organization. Up to 100 observations can receive individual actions. Larger cases, up to 10,000 observations, use at most 100 groups with at most 100 observations each, preferring contiguous source/session/day boundaries. Every included event remains attributed. Grouping saves interaction steps; it does not infer business causality. The owner edits the rules, supplies actual rights and separately approves the exact plan digest.

Compilation requires a current reviewed case, reviewed content and valid source visibility. It binds the plan to an EnterpriseTwinSpec and captured records using the existing capture/ACL contract. The resulting gradia.observer.workflow-universe.v1 identifies both plan and twin digests. Its mirror mode means a reproducible selected-record mirror, not a complete replica of the source application. Reviewed screenshot references remain references; pixels are not silently passed to the agent. Sources: capture contract gradia/twins/capture.py, twin runtime gradia/twins/runtime.py.

Illustrative rule fragment, not a complete API request:

json
{
  "action_id": "approve_terms",
  "from_state": "terms_ready",
  "to_state": "approved",
  "actor_ids": ["commercial_owner"],
  "required_event_ids": ["terms_record_17"],
  "requires": {"legal_checked": true},
  "effects": {"approved": true}
}

7. Time, visibility, replay and branches

WorkflowWorld.observe() filters records by occurrence time and viewer principal. Modeled facts are shared within the plan's view; there is no per-fact ACL. Available actions additionally require the right actor, state, time window, arrived evidence and type-exact preconditions: boolean true is not integer 1.

WorldCommand either selects an available action or advances the virtual clock strictly forward within the horizon. Advancing time never silently executes an action. Effects update modeled state in memory; they cannot write to Slack, Salesforce or the captured desktop.

Each frame binds the command, previous frame and before/after state roots. A root includes the compiled world, principal, clock, state, facts and command history. A branch replays the parent's command prefix and records its checkpoint identity; it is not an arbitrary mutation presented as history.

Data flow · each arrow names a transition, not automatic approval
  1. Approved world and initial stateReplay exact command prefix
  2. Replay exact command prefixVerified checkpoint root
  3. Verified checkpoint rootContinue original commands
  4. Verified checkpoint rootExecute alternative allowed commands
  5. Continue original commandsOriginal run receipt
  6. Execute alternative allowed commandsBranch receipt with parent linkage
Inspect diagram source
flowchart LR
  A["Approved world and initial state"] --> B["Replay exact command prefix"]
  B --> C["Verified checkpoint root"]
  C --> D["Continue original commands"]
  C --> E["Execute alternative allowed commands"]
  D --> F["Original run receipt"]
  E --> G["Branch receipt with parent linkage"]

The receipt gradia.observer.world-run.v1 claims deterministic execution of approved rules. Its elapsed business time is simulated, and completion means reaching a declared terminal state. Neither means the real organization completed the task.

The project Universe entry point reads GET /v1/projects/{project_id}/observer/universes for a paginated metadata-only directory. Entries name the exact case/world identity, digest, retention and source-review availability; they expose no source content or run payload. A deep link selects a world only when that identity belongs to the selected case. The detail and execution paths recheck current source validity; a directory row is not execution authorization.

The broader Universe substrate also declares actors, topology, capabilities, resources and projections. Its declaration manifest explicitly does not prove runtime capabilities or model results. Execution and field-effect receipts have separate materialization and verification paths. The Observatory renders recorded frames with distinct auditor/agent projections; absent parent/checkpoint evidence must not be illustrated as a proven branch. Sources: substrate gradia/scenarios/universe_substrate.py, execution receipts gradia/api/routes_universe_execution.py, Observatory API gradia/api/routes_scenarios.py.

8. Governed model attempts and the Guard boundary

POST /v1/projects/{project_id}/observer/universes/{universe_id}/agent-runs runs a bounded model attempt: one to eight calls, and no more than 200 accumulated world commands. The model receives visible evidence, current state and permitted action choices through a restricted projection. It returns an action or clock advance; the interpreter remains responsible for validity and effects. Source: agent execution gradia/api/routes_observer_agent.py.

The server persists a pending call reservation before provider I/O, applies spend checks and semantic-flow authorization, then rechecks scope and current review before applying the response. An uncertain call is not automatically sent again under the same request identity. Non-offline dispatch uses the actual governed model client and approved control edition; an offline fixture is useful testing, not a live model evaluation. Source: control admission gradia/api/control_flow.py.

Project-attributed Gateway calls also use a durable cost ledger. Migration 0145 adds RunBudgetAllocation and LLMCallBudgetHold with forced project RLS. Admission locks the project, reserves the run allowance, and commits the run, queue job and durable request identity together. Before each provider attempt, a separate short transaction reserves its conservative configured-cost bound; no database lock spans network I/O. Settlement records actual spend once and closes the hold. Unknown billing, interrupted attempts and vendor bound violations retain exposure for reconciliation; job age alone cannot release funds. Finite caps refuse unknown prices and providers with hidden retries. GET /v1/projects/{project_id}/budget exposes recorded spend, commitments and uncertainty. These controls do not reconcile vendor invoices, allocate organization-wide funds across projects, or cover platform/infrastructure fees. Sources: ledger gradia/db/budget_reservations.py, Gateway adapter gradia/api/budget.py, migration alembic/versions/0145_durable_project_budgets.py.

Gradia Guard addresses another boundary: execution evidence and control receipts around software/model activity. The @gradia/guard SDK and wrapper can record process lifecycle and byte digests, with managed evidence re-verification. A voluntary wrapper can be bypassed; stronger enforcement claims need separately established runtime/adapter evidence. Internal hash consistency alone proves neither authorship, trusted time nor scientific validity. Observer's human history review is not a substitute for Guard runtime evidence. Source: Guard SDK packages/guard/README.md.

9. Evaluators, calibration and native result admission

An evaluator needs evidence that it recognizes intended success and failure boundaries. EvaluatorAdmissionDraft binds judge, rubric, scaffold, criteria and probes. The admission engine distinguishes positive controls, isolated mutations and system-boundary probes. Environment failures, budget stops, protocol failures and insufficient evidence are separate from agent failure. An isolated mutation must identify the intended criterion failure, rather than rewarding any arbitrary red result.

The engine recomputes reports from exact evidence-set/probe inputs. It does not manufacture trustworthy probe observations. Runtime adapters must establish those inputs' provenance. API flows include project evaluator admission editions, POST /v1/evaluator-admission-editions/{edition_id}/admit, and report verification. Sources: admission engine gradia/judges/admission.py, evidence sets gradia/judges/evidence_sets.py, admission routes gradia/api/routes_evaluator_admissions.py.

A native Observer-to-evaluation bridge therefore requires explicit environment/task construction, applicable runtime and evaluator admission, and an actual native execution. Existing workflow-world completion cannot stand in for Episode and Grade. The strict native policy protocol below currently reads native_grade_task_correct_v1; it explicitly does not establish broader evaluator calibration through that receipt alone.

The retained assessment bridge docs/product/OBSERVER-CONNECTED-ASSESSMENT-2026-09-08.md implements a separate version-2 source-retained lifecycle under each native candidate. Server-derived configuration binds the installed source manifest, read tools, model pin, actual routed adapter/endpoint and execution limits. The observer_retained_rights grant binds the exact captured source and disclosure recipient, with persisted owner authority. Six native control episodes establish the executed task_correct evaluator; their protected Grades/traces are reloaded at admission, with deliberately absent evidence remaining an unscored boundary control. An eligible generic report or an unrelated asset-rights edition cannot substitute for these proofs.

Owner and independent reviewer decisions bind the canonical observer_retained_assessment draft. Freeze atomically composes encrypted state with the existing ObserverNativeAssessment identity. Its journal allocates the actual run budget, persists request intent and Guard receipts, rechecks current authority immediately before dispatch, saves responses before applying actions and never resends an uncertain request. Protected results and matched one-task/seed comparisons reauthorize current dependencies on read. They remain outside ordinary benchmark totals and generic package/corpus admission. See API composition gradia/api/routes_observer_retained_assessment.py, production authority gradia/observer/assessment_admission.py and executed evaluator evidence gradia/api/observer_evaluator_evidence.py.

10. Four primary policy-evidence lifecycles

The Console at /projects/{project_id}/policy-evidence provides exact drafting, reference lookup, preflight, independent human decisions, immutable issuance and current verification for the four families. Comparison inputs use structured assessment selectors and run identifiers; the other templates retain advanced JSON. Initial source authority, rights, policy requirements and declared system releases must already be admitted through the API. Reviewer handoffs contain draft bytes and project identity, not approval; ambiguous writes retain their exact request/key for retry. Sources: Console lifecycle apps/console/components/policy-evidence-lifecycle.tsx, client contracts apps/console/lib/policy-evidence.ts.

The lifecycle APIs turn exact dependencies, independent human decisions and native run observations into immutable editions. They use POST /v1/projects/{project_id}/policy-evidence/{family}/draft-preflight, followed by human decisions on the returned subject digest and creation with that same expected digest. Sources: lifecycle routes gradia/api/routes_policy_evidence_lifecycle.py, contracts gradia/policy_evidence/contracts.py.

Family What admission establishes
assessment-contracts A frozen execution contract approved by an owner and a distinct independent reviewer, with exact policy, release, task, universe, evaluator and sampling dependencies
release-comparisons Server-derived paired observations from actual completed baseline/candidate native runs under their frozen assessments
technical-evidence-packages An exact artifact manifest, permitted audience, comparison/release bindings and independent review/issuance decisions
remediation-corpora Reviewed native failure/repair items with current source rights, recipient scope and explicit split/overlap constraints

NativeExecutionPolicy uses gradia.policy-evidence.native-execution-policy.v1. Its configuration, task, universe, sampling-panel, rule and evaluator manifests bind exact native identities and bytes. The environment must belong to the project through its specification/build chain and match the fingerprint. Tasks and sampling cells must match the declared policy, not merely exist as uploaded assets. Model pins describe recorded model identity; they do not verify provider weights. Source: native lifecycle verification gradia/policy_evidence/lifecycle.py.

Comparison inputs name assessments and run IDs. The server reads actual runs, episodes and grades, requires complete declared task/seed cells, validates ordering and trusted-time bounds, and recomputes the paired result. Infrastructure failures and unknown grades do not become agent failures. Deltas are descriptive paired outcomes, not an automatic significance test. Caller-authored result JSON cannot substitute for runtime records.

Final issuance signatures bind authoritative human identities and issuance time as well as the reviewed subject. A dedicated service-configured policy-evidence keyring uses Ed25519; issuer registries and signed payloads bind organization and project identity. GRADIA_POLICY_EVIDENCE_SIGNING_KEYS supports rotation with retained verification keys. A self-digest is insufficient. Current verification follows dependencies and decisions, checks asset bytes and native observations, and rejects revoked, superseded, expired or unavailable prerequisites. Project locking and database append-only protections preserve lineage under concurrent admission.

For remediation, native failures must derive from actual non-infrastructure failing episodes. Rights must cover the exact source artifact and current organization/project recipient. Optional source comparisons must match the source assessment/run. Split isolation, duplicate repair checks, literal answer overlap and privacy checks are bounded checks; they do not prove exhaustive privacy, semantic non-leakage or training benefit. Corpus admission does not launch training. Source: remediation verification gradia/policy_evidence/remediation.py.

The authenticated verification endpoint is GET /v1/projects/{project_id}/policy-evidence/lifecycle/{family}/{edition_id}/verify. Reading a stored edition is not equivalent to this current-admission check. The lifecycle API guide docs/product/POLICY-EVIDENCE-LIFECYCLE-API-2026-09-06.md contains runnable request examples, native manifest shapes and key operations. Admission limits include 8 MB per asset, 32 MB per read budget, 512 references, bounded recursive traversal and 10,000 native task/seed cells; oversized derived receipts are refused before issuance.

11. Worked synthetic workflow and deployment limits

Consider an explicitly synthetic 45-day procurement case. Approved acquisition includes a selected supplier mailbox, a selected commercial channel and a signed procurement application window. A weather page is outside scope and contributes no captured content. The process spans separate sessions; a second procurement case uses independent memberships.

An analyst excludes an unrelated approved-source message, includes the actual terms exchange, and resolves the remaining observations. A late legal update changes the case edition, requiring a new exact review. The owner then approves rules such as “terms require legal approval,” including who can see source records and who can execute each action.

The compiled world can advance virtual time to the legal update, execute permitted approval and compare an alternative branch that misses a deadline. The resulting receipts show which approved rules ran and how modeled state changed. They do not prove the supplier really accepted terms. A native performance assessment requires the separate environment/task/runtime/evaluator chain and recorded runs described above. Revoking the source or expiring its evidence invalidates current dependent use rather than quietly preserving an apparently current approval.

Deployment separates the Next.js Console, Python API, worker, PostgreSQL and asset storage. API startup applies migrations under a PostgreSQL advisory lock; the worker executes queued work and Observer retention sweeps. The Console's API rewrite origin is fixed at build time, so changing it requires rebuilding. Sources: API image Dockerfile.api, Console image apps/console/Dockerfile, worker gradia/worker.py.

The release record distinguishes service deployments from later documentation commits. Local/native build checks do not qualify every customer application: Developer ID signing, Apple notarization, tenant consent, source credentials, approved model access and customer-specific live testing remain explicit activation requirements. Build recovery, bounded workspace capacity, selective capture, shared modeled facts and the separate evaluation bridge are current architectural limits. They are visible so an enterprise can choose a defensible deployment scope and know exactly what each result supports.

Capture continuation and current capacity boundaries

POST /v1/projects/{project_id}/observer/cases/{case_id}/scopes accepts append-only scope_ids with an expected_case_revision. The authenticated case owner can link only approved, currently available project scopes, with at most 100 total links. A hashed scope-link receipt records exact scope digests, actor and previous/new revision. Concurrent stale writes refuse. Existing case reviews and compiled worlds remain bound to their prior revision, so they cannot authorize the changed history. Fresh editions can explicitly declare a retired scope unavailable without restoring its observations.

The guided Console form validates the receiver-specific source IDs, supported content mode, expiry and retention before submission. Native scopes remain separate from website and service scopes. Desktop file admission uses the backend's 50_000_000-byte envelope bound; generic metadata files retain an 8 MiB client limit. Native vault capacity, backend evidence validation and managed workspace bounds remain independent limits.

The current actor is text-based. Reviewed PNG artifacts retain media type, artifact ID and SHA-256. After separate human transcription approval, a newly reviewed compiled record can also carry its exact text, source digest, text digest and review receipt. The local English OCR draft alone grants no model access. Pixel retrieval remains unimplemented, and scope approval, masks or image review do not imply that a model inspected the screen.

Long workflow actor inputs expose exact pages of at most 200 permission/time-visible records under a 100,000-byte JSON limit. record_page names the visible count, offset, snapshot digest and exact next cursor. The agent-only retrieve command selects the next page for its next model call. The cursor binds principal, current world root and the digest of visible record order. Retrieval consumes the unchanged 1–8 model-call allowance, keeps before/after roots equal and adds no world transition. Act/advance reset paging at the new checkpoint. Every provider call retains the prior durable intent, spend, current-review and no-resend gates. A single record that cannot fit remains a named refusal; records and reviewed text are never silently truncated.

Membership policy scope manifests include currently available sources while the full snapshot still includes retired-source coverage and the case revision. Policy/proposal retention follows frozen scope IDs and actual event dependencies. Expired earlier case scopes do not retire a new policy that depends only on renewed evidence. The historical held-out exposure ledger is preserved.

September 7 implementation continuation

The completion plan docs/product/ENTERPRISE-COMPLETION-PLAN-2026-09-07.md records the current source, local verification and production states. Managed desktop transfer uses live scope checks, an exact encrypted pending journal and retention-generation fencing across network awaits. It does not automatically resume capture. The reviewed screenshot text path docs/product/OBSERVER-REVIEWED-SCREENSHOT-TEXT-2026-09-07.md uses bounded local English OCR, independent human text review and source-bound actor projection; no screenshot pixels are passed to a model.

The optional native browser adapter docs/product/SYNTHETIC-BROWSER-NATIVE-GATEWAY-2026-09-07.md executes real HTML actions against a fixed synthetic CRM/mail application and writes native Run/Episode/Grade/Transcript evidence. It is not the production default or a managed Observer hydration path. The protected Observer native reference path docs/product/OBSERVER-PROTECTED-NATIVE-PROBES-2026-09-07.md adds exact-source candidate registration and in-memory deterministic reference execution. Native task/version rows store strict references; full task/twin, transcript and grade bodies stay in the original encrypted workspace. Short leases recheck source/owner/IR currentness, and PostgreSQL write guards prevent ordinary native payload storage. These episodes are excluded from model benchmark and policy-assessment populations. Generic materialization, promotion, model-worker admission and application snapshots remain separate gates. The Analytics package bridge docs/product/ANALYTICS-REVIEWED-PACKAGE-2026-09-07.md now atomically turns an exact independently reviewed proposal into verified files and a durable project-bound receipt.

Try the current Guard source

The source install below is pinned to the verified public 0.1.0-beta.8 commit. The scoped package is not yet available from the public npm registry. Check the installation guide for the current capture, verification and managed-admission steps.

npm install git+https://github.com/rudycelekli/gradia-guard.git#92a93c610f4d02c3db21fe6a6d526d9bd046fe86

rudycelekli/gradia-guard@92a93c610f4d02c3db21fe6a6d526d9bd046fe86

Source checkpoint and product status

Source baseline: repository 30ce45d, 6 September 2026, updated through the connected assessment implementation docs/product/OBSERVER-CONNECTED-ASSESSMENT-2026-09-08.md on 8 September. This is an implementation reference, not a claim that every integration has been qualified in a customer environment. For the shorter explanation, read How Gradia works. Historical deployment provenance is recorded in the launch release record docs/product/OBSERVER-LAUNCH-RELEASE-2026-09-06.md; newer release records preserve their own evidence.

Take the next step with your own workflow.

Choose one real decision, an accountable workflow owner and a precise capture or authoring scope. Keep the assumptions, approvals and evidence visible from the beginning.

Keep a copy

PDF and PowerPoint: September 6, 2026 slide editions. This website guide and its Markdown source are updated separately.

Built from docs/product/HOW-GRADIA-WORKS-TECHNICAL.md.
Source SHA-256: 9e73635c5fb8edf2bf466a2aa8bdac51b87766e3b1ad3ff301daec78b0078a7f
Repository paths in the guide identify implementation references; they do not imply that the application source or private evidence is publicly accessible. Illustrative cases are labeled and are not customer results.

Back to top ↑