# How Gradia works **General walkthrough ยท updated September 8, 2026.** Initial source checkpoint `30ce45d`; the [connected assessment release](OBSERVER-CONNECTED-ASSESSMENT-2026-09-08.md) records the latest implementation and qualification boundary. For implementation details, read [How Gradia works: the technical guide](HOW-GRADIA-WORKS-TECHNICAL.md). The [current claim ledger](../investor/CURRENT-STATE-AND-CLAIM-LEDGER.md) and [launch release record](OBSERVER-LAUNCH-RELEASE-2026-09-06.md) govern product status. Gradia helps a team turn its work into a test an AI agent can attempt, then keep the evidence behind the result. Start with a practical decision: can this agent handle this workflow, with these permissions, under these conditions? The useful output is a reviewed account of the work, an explicit definition of what the agent may do, and a result someone can inspect and repeat. Governance, evaluation and executable **Universes** connect those pieces. A Universe is a controlled environment where declared actions change state according to approved rules. ## Start with the work you already have **If you already run an agent, start with Guard.** Integrate the recorder with a supported part of its execution, capture a run, then verify and inspect the local evidence. Guard shows what that integration recorded and what remained outside its coverage. Its local verifier works without a managed account. A voluntary wrapper can be bypassed; installing it does not make every action observable. Managed Gradia adds authenticated evidence admission, source and rights handling, human review, governance and evaluation. A verified recording is a useful first step. Deciding whether the agent performed well requires an appropriate assessment. Use the [current Guard installation guide](https://www.gradiahq.com/governance#install-guard). **If people currently perform the workflow, start with Observer.** Approve selected sources, collect permitted activity, and assemble it into a continuing business case. The owner reviews that case before turning it into executable rules. **If you have no captured history yet, begin with an interview, a brief or structured authoring.** Describe the job, users, constraints, examples and successful outcomes. Gradia helps structure the specification and expose assumptions that need review. Its broader evaluation factory turns the specification into an intermediate plan called IR, then a build and a native evaluation environment. This is a separate execution path from Observer's workflow worlds; each has its own prerequisites and evidence requirements. ```mermaid flowchart LR G[Existing agent activity] --> GU[Guard recording and governance] O[Selected human work] --> R[Reviewed case and approved rules] R --> W[Observer workflow Universe] B[Interview, brief or structured specification] --> N[Built native evaluation environment] GU --> D[Appropriate evaluation and an evidence-based decision] W --> D N --> D ``` The diagram shows routes through the product, not automatic approval of every input for every downstream use. ## Follow one illustrative 45-day sales case Imagine a business-to-business opportunity that takes 45 days to qualify, approve and hand off. This example explains the workflow; it is not a customer deployment or a measured sales result. | Time | Work the team wants to understand | Possible approved evidence | |---|---|---| | Day 1 | Open and assign the opportunity | A selected Salesforce opportunity | | Day 8 | Discuss needs and outstanding questions | A selected Gong call and permitted transcript | | Day 18 | Review pricing and responsibilities | Approved email, channel activity and a native application window | | Day 32 | Resolve a missing condition | A permitted conversation and updated opportunity fields | | Day 45 | Approve the final handoff | Reviewed decision evidence and the agreed end state | A case can connect recordings from several sessions and sources across those weeks. The business owner decides which observations belong. A click or a changed field does not, by itself, explain why a person made a decision. ## Approve the capture boundary Before collection, name the participating people, devices, source accounts, purpose, content mode, expiry and retention. Select the smallest useful scope. Observer's service adapters cover selected Slack channels or threads, Microsoft mail folders and optional conversations, Teams channels, Gong calls, and Salesforce opportunities. They check the approved account and resource identity. Microsoft mail and Teams can renew an existing delegated grant; Gradia does not obtain new consent or expand its permissions. The browser receiver starts explicitly on an approved exact HTTPS page. It captures categorical navigation and click metadata, with visible controls and coverage gaps. It does not read page text or establish the account's corporate identity from the screen. The macOS and Windows companions cover one participant-selected, approved native application window. The Windows scope pins the exact executable and signing certificate; macOS checks the application bundle and signing team. Optional screenshots require separate permission to process that whole window and explicit local masking and acceptance. A narrow website or document permission is insufficient for whole-window capture. Websites use the browser receiver. Native recordings use an encrypted local vault. The participant can enable managed transfer or export sessions manually for Console import. Explicit continuous batches rotate a bounded session, wait for exact acknowledgment, then resume the same selected window after a fresh permission check. Transfer delays pause collection and remain visible gaps. Closing the companion stops collection; reopening leaves recording stopped and transfer off. The earlier Windows build, encrypted-import and installer checks have recorded synthetic Windows evidence. The transfer and batch-rotation coordinators have local core and cross-build tests; their installed Windows operation still needs qualification. Signed public distribution and qualification on the customer's actual applications remain separate release requirements. Neither companion claims unattended recording or complete desktop coverage. Choose metadata alone or separately approved content. Some provider APIs return message content into memory even during metadata collection; the connector's persistence rules determine what is retained. Sanitized text and masked screenshots still need human inspection. Names, business facts and other sensitive information can remain. ## Filter the case and verify the history Source permission and case membership answer different questions. Permission says what may be collected. Membership says which permitted observations belong in this particular case. An approved channel might contain several opportunities; its unrelated activity should not enter this opportunity's history. Inspect the observations, exclude unrelated work, restore a mistaken exclusion, and keep uncertain or missing coverage visible. AI can suggest relevance and stages. Automatic membership edits require a fixed policy and measured performance on separate human-labeled examples. A relevance score is not a probability that the history is true, and an AI suggestion never supplies human verification. Content review and history review are also distinct. Review what the captured text or screenshot reveals, then have the workflow owner verify the exact included history. Later changes make the previous review stale. The approval therefore identifies a specific reviewed edition, rather than a permanently trusted case name. This step produces a useful artifact before an agent runs: the owner-approved history, its included evidence, and an explicit account of what is missing. ## Turn the history into rules Observer can propose a workflow from the reviewed sequence. The owner supplies the business meaning that observation alone cannot establish. For the sales example, define who may request more information, who may approve pricing, which conditions permit handoff, and what counts as completion. Set the facts, actions, permissions, conditions, effects and timing explicitly. A rule might make handoff available only after the required approval has been recorded in the modeled state. The visual editor lets the owner inspect those rules, validate the exact plan and approve it before compilation. Changing a condition or permission requires a fresh approval of the changed plan. Three things remain separate: **observed history**, **owner-approved assumptions and rules**, and **what a run of those rules produces**. An unobserved phone call cannot be reconstructed merely because it would explain a gap. A simulated approval changes the modeled workflow; this execution path does not send an email or update the customer's CRM. ## Run time, inspect a checkpoint, try another continuation An Observer workflow Universe keeps its own virtual clock. Evidence and actions become available according to the approved time, role and state rules. A model cannot see a future observation simply because the case owner already has it. A wait is an explicit recorded transition. If the next permitted action is thirty days later, the simulation can advance to that declared time without waiting thirty calendar days. That demonstrates the modeled timing, not thirty days of actual business work performed instantly. The activity timeline shows recorded actions, waits and state changes. Select a saved checkpoint and create a branch to try another permitted continuation. For example, an approved plan might allow either requesting missing information or continuing once existing conditions are satisfied. Each branch records its own path and retains its relationship to the original checkpoint. A branch explores the approved model of the workflow. It does not establish what real people would have done in that alternative situation. ## Let an approved agent attempt the workflow Begin with a deterministic rule replay so the owner can inspect the environment. Then configure a governed AI attempt for the exact Universe, with the permitted model, data boundary, spending controls and required independent approval. The agent receives the evidence and actions currently available to its role. Gradia records model calls separately from accepted workflow transitions. If a prerequisite is missing, the relevant action remains unavailable. The resulting receipt lets a reviewer distinguish what the model proposed, what the engine accepted, and which state actually followed. That supports a concrete conversation about the attempt. It does not establish a model's general quality from one example. ## Decide what the evidence supports The first deliverable can be a reviewed case, approved rules, a recorded attempt, its replay or branch, and a decision to revise the workflow or test the agent again. The new [protected native reference step](OBSERVER-PROTECTED-NATIVE-PROBES-2026-09-07.md) lets the case owner prepare a question, explicit answer and reference sequence, then check that sequence through Gradia's native grader. The captured inputs and complete results stay encrypted under the original source permissions and retention. The Console can reopen these candidates and their probe evidence. A passing reference sequence is a useful preparation check; it does not score a model or automatically promote the task into a formal assessment. The [connected assessment journey](OBSERVER-CONNECTED-ASSESSMENT-2026-09-08.md) then lets you evaluate a model on that retained task. In Console, attach actual source permission and the declared model configuration, run the six grader checks, obtain Guard destination approval and ask a separate person to review the exact assessment. After both decisions, freeze and explicitly run it under project budget limits. You can compare two completed attempts when their conditions match. Source changes or withdrawn permission block reuse; an uncertain request is never automatically sent again. This is a bounded read-and-decide result on your reviewed evidence, not an ordinary population benchmark or a restored live application. For a formal release comparison, freeze the assessment conditions before eligible execution. The broader native evaluation path binds the system configuration, tasks, sampling plan, evaluator and review requirements to recorded results. Observer workflow receipts and Guard bundles do not automatically satisfy that separate native protocol. Gradia can then admit an exact release comparison, a signed technical evidence package, or a separately rights-reviewed remediation corpus. Missing scores and infrastructure failures remain distinct from model failures. Independent humans review the relevant evidence; later verification can refuse if a required approval, source, result or signing key is no longer valid. A proposed repair is something to review and retest. Preparing a corpus does not dispatch training, and a signed package does not confer legal compliance or external accreditation. The decision should name the exact tested conditions and remaining gaps so the next release can be assessed against them. ## Start small and leave with something reusable Bring a workflow owner, a source administrator and an engineering or AI lead. Agree on one decision, the accepted sources, required reviewers and success criteria. Use [Observer setup](https://www.gradiahq.com/observer/get-started), or [open your workspace](https://www.gradiahq.com/login) to begin the appropriate journey. The [buyer demo guide](../sales/WORKFLOW-DEMO-GUIDE.md) and [receiver instructions](WORKFLOW-OBSERVER-MANAGED-2026-09-06.md) give operational steps. Leave the first engagement with the accepted scope, reviewed history or specification, approved rules, exact result receipts, coverage gaps and the next decision. Measure setup effort, owner review time and whether the result changes that decision before promising a rollout timeline or savings. The [current production proof](OBSERVER-LAUNCH-PRODUCTION-2026-09-06.json) verifies the shipped managed path and replay of the existing synthetic case. Its earlier recorded smoke used two observations and a 30-day virtual wait within a 45-day case. No customer capture or production model-performance result is claimed. Teams with authorized workspace access can inspect the [synthetic demonstration](https://www.gradiahq.com/projects/6ecaafe2ee624ee99890cbea175fbed6/observer?case=sale). ## Continuing a captured workflow The Observer setup form covers browser, macOS, Windows, Slack, Microsoft mail, Teams, Gong and Salesforce scopes. It starts with metadata; screenshots or text require an explicit content boundary and exact scope approval. Approved service scopes offer a guided configuration download with exact bindings and credential environment references. The administrator supplies existing read permissions and operates the collector. Native apps offer optional managed transfer and explicit continuous batches as well as manual encrypted export; Console accepts desktop envelopes up to 50 MB. Continuous batches resume only after exact acknowledgment and fresh authorization of the same selected window. Transfer pauses are coverage gaps. Startup remains stopped and transfer off. A workflow owner can add renewed or additional approved scopes to the same case. This records a revision, makes the prior history review and compiled worlds stale, and leaves new observations needing a decision. Expired evidence remains a visible coverage gap. A new review and approved rule plan are required before creating the next Universe. Captured screenshots can be reviewed in Console and linked by artifact identity inside a world. English OCR on the managed server can propose text; a human must correct and explicitly approve it before a newly reviewed world can expose that text under the original principal, time and retention boundary. Manual transcription remains available. The workflow actor receives approved text and metadata, not screenshot pixels. Automatic visual understanding, universal application coverage and signed customer-ready desktop distribution are separate capabilities or qualification gates; the current release does not claim them.