Quick Start

Get the system running in under a minute.

Prerequisites

• Python 3.11+
• uv (optional, used if present; otherwise venv + pip)

Setup

# Clone and enter the project
git clone https://github.com/adityamhaske/computer-use-automation.git
cd computer-use-automation

# Install everything: venv, dependencies, Chromium
make setup

Configuration

cp .env.example .env

The only thing that needs an API key is the live discovery run. Replay, escalation, the full test suite, and the demo all work without one.

Run the demo

# The whole story, one command — fourteen stages end to end
make demo

Takes about a minute. Works without an API key — discovery falls back to a recorded transcript and says so explicitly.

Unified Orchestrator (./start.sh)

Orchestration over the Makefile targets — it adds nothing you could not run by hand, it just names the combinations (app and console together, wait-for-ready, teardown on Ctrl+C).

./start.sh                 # Default: setup venv + run the full 14-stage demo
./start.sh ui              # Console + mock bank, with an escalation already waiting
./start.sh ui --headed     # ...and watch the supervised browser while you claim it
./start.sh ui --bare       # Console over an idle session: the queue stays empty
./start.sh app             # Run hostile mock back-office app (port 8811)
./start.sh app-b           # Run rebranded second-tenant variant (port 8811)
./start.sh check           # Run CI checks: lint + typecheck + invariants + secret scan + tests + smoke
./start.sh test            # Run offline test suite (no API keys, no network)
./start.sh eval            # Run stability and cross-tenant drift evaluations

Development commands (Makefile)

make check          # lint + typecheck + invariants + secret scan + tests + smoke (CI)
make test           # offline suite; no API key, no network
make invariants     # just the architectural contracts
make secrets        # fail on any key-shaped string in tracked files (HISTORY=1 adds every commit)
make discover       # live LLM discovery against the mock app; needs OMNIROUTE_API_KEY
make verify-live    # check the newest discovery run was a live model, not a script
make eval           # stability + cross-tenant measurement
make edge-cases     # 22 hostile/boundary scenarios run for real, every run saved to evidence/edge-cases/
make test-report    # whole suite under line + branch coverage -> evidence/tests/
make mutation-check # break each invariant on purpose; prove the suite goes red
make evidence       # refresh everything under evidence/ in one go

2,158 tests, mypy --strict clean, five enforced import contracts. The whole suite runs offline with no API key. make test-report writes the counts and coverage to evidence/tests/; make mutation-check breaks each invariant on purpose and proves the suite goes red.

Demo Walkthrough

make demo boots the mock back-office and runs fourteen stages end to end, writing everything to evidence/.

Fault injection

Faults are injected into the mock app, not the replay engine — the executor must not know a fault is coming:

# Arm a fault
curl -X POST localhost:8811/_control/arm \
  -d '{"fault":"transient_load","count":1}' \
  -H 'content-type: application/json'

# Reset
curl -X POST localhost:8811/_control/reset

Available faults: transient_load, session_timeout, undeclared_dialog, validation_error.

Exit codes

CLI Reference

make demo is orchestration, not a second implementation — every stage is a command you can run on its own.

Discovery

cua discover \
  --goal "Look up member 12345 and read their current savings balance" \
  --target http://localhost:8811 \
  --out evidence/capabilities/

Requires OMNIROUTE_API_KEY. The model drives a live UI, the run is compiled into a capability artifact.

Replay

# Success case
cua replay <artifact> --base-url http://localhost:8811 --input member_id=67890

# Business outcome (exit 0)
cua replay <artifact> --base-url http://localhost:8811 --input member_id=99999

Operator Console

cua console --target http://localhost:8811    # claim, act, release

Catalog

cua catalog list                              # typed signatures
cua catalog show <id> --tool-schema           # agent-facing contract
cua catalog invoke <id> --input member_id=12345 --base-url http://localhost:8811

Agent Demo

cua agent-demo --base-url http://localhost:8811   # caller handling all four statuses

Mock App

make app                  # hostile back-office on :8811
make app-variant-b        # second tenant variant

System Architecture

How the pieces fit together, and why the boundaries fall where they do.

Package map

Project layout

src/cua/          domain · perception · surfaces · targeting · policy · runtime
                  agent · recorder · replay · hitl · evidence · cli
apps/mock_bank/   the hostile target application (+ a "second tenant" variant)
docs/             ADRs (why) · design (how) · prd (what, in what order) · runbooks
tests/            unit · integration · contract · invariants · e2e(live)
evidence/         proof that the end-to-end thread actually ran
                  including evals/ — the measured numbers behind the claims

Execution Pipeline

One path to a surface, for every actor. Discovery, replay, and human intervention all take the same path.

Action ──► TargetResolver ──► PolicyEngine ──► SurfaceDriver
       (resolve or refuse)    (authorize)      (dispatch)

Enforced three independent ways:

1. Import rule. cua.runtime.dispatcher is the only module allowed to import cua.surfaces (.importlinter contract policy-chokepoint).
2. Type rule. SurfaceDriver.dispatch() accepts only an AuthorizedAction, which carries a token instance held exclusively by PolicyEngine.
3. Reconciliation test. Every dispatch event in a run record must have a matching authorize event with the same action ID.

Human input is policed, not injected

The console submits raw_input actions which traverse the same path under a distinct HUMAN policy profile:

The Ten Invariants

The value of this system is almost entirely in a handful of properties. Each is mechanically enforced — the test is named so you can see it fail on purpose.

1. Replay never calls or imports the LLM

cua.replay may not import cua.agent, httpx, or any model client — directly or transitively. A replay that can quietly ask a model for help is not deterministic, not cheap, and not auditable.

2. No action reaches a driver without policy authorization

cua.runtime.dispatcher is the only module permitted to call dispatch(). SurfaceDriver.dispatch() accepts only an AuthorizedAction, which carries a token that only PolicyEngine can mint.

3. Target identity is a semantic TargetDescriptor, never a raw CSS selector

Artifacts describe controls by role, accessible name, scope, structural anchor, and ordinal. Surface-specific data may appear only inside TargetDescriptor.hints, and a hint is an unverified cache.

4. Human input cannot bypass policy or evidence

The operator console never injects into the page. It submits raw_input actions to the SessionBroker, which runs them through the same chokepoint under the HUMAN policy profile.

5. Unknown states fail closed

If the observed UI matches no declared precondition, checkpoint, outcome, or recovery rule, it is UNEXPECTED_STATE and the run stops. If a target resolves ambiguously, the resolver refuses with TARGET_AMBIGUOUS.

6. Every sink is redacted

Logs, artifacts, evidence files, screenshots, and outbound LLM prompts. Secrets are {$secret: ref} references resolved at dispatch time and never written anywhere.

7. Business outcomes are not failures

"No such member" is a legitimate answer the caller needs, not a crash. BUSINESS_OUTCOME exits 0.

8. Automation may only act while it holds the session

Every dispatch asks the lease: who holds this session, and has it changed hands since this run was authorized. Either answer can refuse the dispatch with LEASE_LOST.

9. Capabilities are immutable

A Capability at id@version is frozen and content-hashed. Anything that changes because you ran it lives in a separate document: RunRecord, CapabilityEvaluation, CapabilityApproval.

10. domain/ is pure

No I/O, no network, no browser, no clock. cua.domain imports nothing else from cua.

The Capability Artifact

The unit of reuse in this system. What the LLM's discovery run compiles down to, what a human reviews, and what an AI agent invokes in production.

Decision rationale lives in ADR 0002. This document is the reference for what the schema is.

Three readers, one artifact

Document family

Only the first is the capability. The rest exist so the capability can stay immutable.

cua.capability/v1             frozen, content-hashed — the contract
cua.tenant_binding/v1         per-tenant vars + step overrides (base ⊕ overlay)
cua.run_record/v1             one execution: trace, resolutions, drift, evidence refs
cua.capability_evaluation/v1  aggregate over runs: stability, strategy mix, drift trend
cua.capability_approval/v1    draft → approved, approver, scope

Identity

capability:
  id: "corebank.member.savings_balance"   # <vendor-product>.<domain>.<operation>
  version: "1.2.0"
  content_hash: "sha256:…"

id is namespaced by vendor product, never tenant — the precondition for cross-tenant reuse.

Typed contract

inputs:
  - { name: member_id, type: string, required: true, pattern: "^[0-9]{4,10}$",
      sensitive: false, example: "12345" }
outputs:
  - { name: savings_balance, type: money, source: { step: read_balance } }

These emit JSON Schema directly, so the artifact is the agent tool contract — there is no second source of truth to drift. sensitive: true propagates everywhere.

Steps

steps:
  - id: enter_member_id
    action: { type: type, value: { $input: member_id } }
    target:
      role: textbox
      name: { match: exact, value: "Member Number" }
      scope: { frame: content, region: search_form }
      anchor: { relation: row_of, cell_text: "Member Number" }
      hints: { css: "...", node_path: "..." }   # unverified cache
      fingerprint: "sha256:…"
      recorded_strategy: semantic_exact
    precondition:  { assert: node_exists, role: textbox, name: "Member Number" }
    wait:          { for: snapshot_stable, timeout_ms: 5000 }
    postcondition: { assert: node_has_value, value: { $input: member_id } }
    risk: safe

Every step asserts both before and after. A step that only acts is a step that assumes the click worked.

Success, outcomes, recovery

# Did we actually reach the state we wanted?
checkpoint:
  all_of:
    - { assert: node_exists, role: heading, name_contains: "Member Detail" }
    - { assert: node_matches, role: cell, name_matches: '^\\$[0-9,]+\\.[0-9]{2}$' }

# Legitimate answers — NOT failures
outcomes:
  - { code: member_not_found, detect: { text_present: "No records found" },
      terminal: true, returns: { member_id: { $input: member_id } } }

# Bounded, declared remediation — never open-ended
recovery:
  - { id: transient_load, detect: { http_status_in: [502,503,504] },
      remedy: [ { reload: {} } ], max_attempts: 3, backoff: exponential }

Target Resolution

Resolution is where determinism is won or lost. Turning a semantic TargetDescriptor into a concrete UiNode in the current snapshot.

The resolution ladder

Strategies are tried in fixed order. The first rung that yields any candidate decides: exactly one wins; more than one is refused unless the descriptor carries an explicit ordinal. A rung with several candidates does not fall through to the next.

Rung 3 is what makes legacy enterprise apps tractable. Those apps are full of controls with no name, no label, and no test ID, sitting in a table cell next to the text that identifies them.

Rung 4 is a cache, not an identity. A hint is accepted only if the node it resolves to also satisfies the semantic assertion.

Ambiguity is refusal

If a rung yields two or more candidates and the descriptor carries no explicit ordinal, the resolver raises TARGET_AMBIGUOUS and the run stops. It does not pick the first, the topmost, or the highest-scoring. There is no threshold to tune: the reported ambiguity figure, (candidates − 1) / candidates, is for debugging and is never compared against anything.

Two plausible "Submit" buttons mean the screen is not what we think it is, and acting on either is how an automation posts a transaction to the wrong account. A refusal is recoverable — a wrong click may not be.

Drift

Resolving via a lower-priority strategy than the one recorded at discovery is drift — a signal, not a silent success. Per-step drift aggregates into a run-level drift_score.

This is the mechanism behind the multi-tenant story: a tenant whose UI has diverged shows rising drift before replays begin to fail.

Variant B: two kinds of divergence

Case A — markup churn, same vocabulary (the ladder handles this)

semantic_exact resolves it on both. This is the falsifiable form of "this system does not depend on CSS selectors."

Case B — rebranding, different vocabulary (this needs an overlay)

No automatic recovery here — and that is correct. Inferring that "Savings Bal." means "Savings Balance" is a fuzzy guess, and a system that guesses which row holds a balance will eventually read the wrong one.

Error Taxonomy

Two distinct type families — what we observed, and how the run ended — because they are not the same axis.

What we observed (a classification of a moment)

ObservationClass = EXPECTED | BUSINESS_OUTCOME | RECOVERABLE | HARD_FAILURE | UNEXPECTED_STATE

How the run ended (a terminal status)

RunStatus = SUCCESS | BUSINESS_OUTCOME | NEEDS_HUMAN | FAILED

The decision procedure

At every observation point the executor asks, in this order:

1. Does the state satisfy the step precondition / checkpoint?   → EXPECTED, proceed
2. Does it match a declared `outcomes` detector?                → BUSINESS_OUTCOME, return
3. Does it match a declared `recovery` detector?                → RECOVERABLE, remediate
4. Is it a known hard-failure condition?                        → HARD_FAILURE, stop
5. Otherwise                                                    → UNEXPECTED_STATE, FAIL CLOSED

Failure codes

The fault matrix

Control Transfer (Human-in-the-Loop)

A human takes control of the same live session the automation was using — not a fresh one — does the manual work, and hands it back so the run can finish.

State machine

RUNNING ──escalate──► PAUSED ──human_claim──► HUMAN_CONTROL
   ▲                  (epoch++)               (epoch++)
   │                                                │
   └── resume (epoch++) ◄── RESUMING ◄── human_release (epoch++)

Re-anchoring happens after the lease is back in RUNNING: ReplayExecutor.resume() reconciles against the live screen before its first action. cua demo drives that resume; the operator console's Release returns the lease to automation but does not itself restart the run.

The lease

Lease(holder: Actor, epoch: int, expires_at: datetime)

holder ∈ {AUTOMATION, HUMAN, SYSTEM} — SYSTEM while the session is PAUSED or RESUMING, when nobody may act. Every transition increments epoch monotonically.

An operator's input is refused by the broker unless lease.assert_held(HUMAN, epoch) passes. An automation run checks that it holds the session when it starts (or resumes), then carries its epoch into every dispatch, and the dispatcher refuses a stale one with LEASE_LOST. Every change of holder advances the epoch, so the two checks together cover every dispatch.

Escalation triggers

Re-anchoring after handoff

On human_release the broker snapshot-diffs pre-handoff against post-handoff and records human_delta. When the run is then resumed, ReplayExecutor.resume() scans forward from the step that escalated:

1. A step whose postcondition already holds is skipped — doesn't redo human work. A step with no postcondition is never skipped.
2. The run resumes at the first step not visibly done — provided its precondition holds
3. Otherwise → UNEXPECTED_STATE, fails closed

Step 3 is the fail-closed rule applied to the handoff seam. "The human left the session somewhere I don't recognize" is exactly the moment not to improvise.

ADR 0001 — UiSnapshot as the cross-surface abstraction

Status: Accepted · 2026-09-11

Context

We must perceive and act on three very different kinds of surface: modern web apps, legacy server-rendered web apps (framesets, nested tables, non-semantic markup, no test IDs), and native desktop applications.

Three candidates: DOM/CSS first (breaks on desktop), pure vision (pixel coordinates are the least stable thing you can persist), and semantic/accessibility tree.

Decision

Perception normalizes every surface into a UiSnapshot: a tree of UiNode {node_id, role, name, value, states, bounds, scope, parent, hints}.

The artifact schema and targeting system depend only on UiSnapshot and TargetDescriptor. Neither knows what an accessibility tree, a CDP session, or a DOM is.

Consequences

Good. The same artifact can replay on a desktop driver, because role: button, name: "Search" means the same thing in UIA as in ARIA.

Bad. Accessibility trees on genuinely hostile legacy apps can be thin. Mitigated by driver-level enrichment and the structural_anchor resolution strategy.

ADR 0002 — Immutable content-addressed capability

Status: Accepted · 2026-09-11

Context

A capability artifact accumulates pressure to hold more: run counts, stability scores, approval state, last-run timestamps. An earlier draft put telemetry inside the capability. Two problems surfaced:

1. The definition mutates every time you run it — git diffs become noise
2. "Which version produced that run?" becomes unanswerable

Decision

A Capability at id@version is frozen and content-hashed. Nothing that changes as a result of executing it may live inside it. Runtime state moves into separate documents.

Consequences

Good. Reviewing a capability is reviewing a contract. A RunRecord can name exactly what it executed.

Also good. Immutability makes the multi-tenant story cleaner: a tenant cannot "drift" a shared capability by using it.

ADR 0003 — Four-class observation taxonomy

Status: Accepted · 2026-09-11

Context

A replay observes a screen and must decide what it means. The brief asks us to distinguish business outcomes, recoverable conditions, and hard failures. Working through the mock app exposed a fourth case: a state this capability does not understand.

A system without this category has to force it into one of the other three. The tempting choice is "keep going and see." That is precisely the behaviour that causes incidents.

Decision

Two distinct type families:

ObservationClass = EXPECTED | BUSINESS_OUTCOME | RECOVERABLE | HARD_FAILURE | UNEXPECTED_STATE
RunStatus = SUCCESS | BUSINESS_OUTCOME | NEEDS_HUMAN | FAILED

Consequences

Good. The caller's contract is honest: BUSINESS_OUTCOME(member_not_found) exits 0 and returns data. A FAILED carries enough detail to fix without reproducing.

Bad. Authoring a capability requires declaring outcomes and recovery rules explicitly — more work than letting the executor improvise. That is the point.

ADR 0004 — A single, type-enforced policy chokepoint

Status: Accepted · 2026-09-11

Context

Three different actors want to act on the live session. An earlier draft forwarded human clicks directly via CDP — which meant the moment a human took over, the allowlist, risk classification, and evidence trail all stopped applying.

Decision

One path to a surface, for every actor: Action → TargetResolver → PolicyEngine → SurfaceDriver.

Enforced three independent ways (import rule, type rule, reconciliation test), because an invariant everyone agrees with is weaker than one nobody can violate.

Consequences

Good. Discovery, replay, and human intervention are the same code path, differing only in who originates the action — so the guardrails we test are the guardrails that run.

Bad. raw_input is awkward to police semantically. A click is hit-tested against control geometry and a key against the focused control, so a click on “Transfer Funds” needs explicit confirmation; a gesture on something the semantic tree does not expose falls back to its action type’s tier.

ADR 0005 — Tenants overlay a capability; they never fork it

Status: Accepted · 2026-09-11

Context

The economics of this system: if automating a flow for one credit union means re-recording it for the next 200, the product does not work.

Decision

Capabilities are namespaced by vendor product, not by tenant. Per-tenant differences are expressed as overlay documents.

# cua.tenant_binding/v1
capability_ref: "corebank.member.savings_balance@1.2.0"
tenant: first-valley-cu
vars: { base_url: "https://fvcu.internal" }
overrides:
  steps:
    enter_member_id:
      target: { name: { match: exact, value: "Member #" } }

Drift is measured, not assumed. Descending the resolution ladder at replay is a drift signal, not a silent success.

Consequences

Good. A rebranded label costs a four-line overlay, not a re-record. The drift score tells us which tenants are diverging before replays start failing.

Requirements Traceability

Every requirement mapped to the module that satisfies it, the test that proves it, and the evidence that demonstrates it.

3.1 — Capability discovery

3.2 — The capability artifact

3.3 — Deterministic replay

3.4 — Safety & data handling

3.6 — Human-in-the-loop escalation

Testing Strategy

Every architectural claim has a test that fails when the claim stops being true.

A design document that asserts an invariant is a wish. A contract in .importlinter plus a test that breaks on violation is an invariant.

Claim → test

Test layers

Offline by default

Everything except e2e/ runs with no API key and no network. 2,158 tests (1,800 of them edge cases: boundary, malformed, hostile and out-of-order input), mypy --strict clean. CI configures no API key on purpose — if a test needs the model, CI must fail rather than silently skip.

Continuous integration

.github/workflows/ci.yml runs the same targets a contributor runs locally, as separate steps so a failure names its stage:

1. Lint and format, then strict type check
2. Architectural invariants: the five import contracts, plus a check that every path the docs cite exists
3. Secret scan (make secrets HISTORY=1) over the tree and every commit. It never prints what it finds, since echoing a secret into CI logs is itself a leak
4. The offline test suite, the reviewer-path smoke test, and the full 14-stage demo

The workflow holds read-only permissions, and a newer push cancels a superseded run on the same ref. CI has no model key on purpose. The demo's evidence is uploaded as a build artifact, so a reviewer can download exactly what that run produced.

A second workflow, .github/workflows/verify.yml, runs the slow checks CI does not run on every push: the edge-case runs (make edge-cases), the test report with line and branch coverage, and the mutation check, which breaks each invariant on purpose and fails if any deliberate violation goes uncaught. It runs nightly, on demand, and on pushes that touch code or tests, and uploads evidence/tests/ and evidence/edge-cases/ as an artifact. Dependabot keeps the pinned toolchain and the Actions versions current, weekly and grouped.

The one thing CI cannot do on every commit is spend real tokens. A separate, manually triggered Live discovery workflow runs make discover against your gateway, then make verify-live, and uploads the evidence as a build artifact to review before anything is committed. It needs an OMNIROUTE_API_KEY secret, plus CUA_LLM_BASE_URL and CUA_LLM_MODEL variables, and the gateway must be reachable from a GitHub-hosted runner.

The fake LLM

agent/fake.py implements LlmPort by replaying a recorded transcript. This exercises the real discovery loop — same policy, same resolver, same evidence bus — for free.

Risk: fixture drift. Mitigated by regenerating fixtures from a live run via script, plus a contract test asserting fixture shape matches the live LlmPort schema.

Run a Discovery

Discovery is the probabilistic half: an LLM drives a live UI to a goal and we record what it did. It is the expensive path, run once per capability.

Prerequisites

cp .env.example .env     # set OMNIROUTE_API_KEY, CUA_LLM_BASE_URL, CUA_LLM_MODEL
make app                 # the mock back-office on :8811

Run

cua discover \
  --goal "Look up member 12345 and read their current savings balance" \
  --target http://localhost:8811 \
  --out evidence/capabilities/

What happens

1. The driver observes the surface and normalizes it into a UiSnapshot
2. The snapshot is rendered for the model — not raw HTML, and redacted on the way out
3. The model emits a tool call from the closed action space. It cannot invent an action
4. PolicyEngine authorizes it. Off-allowlist or irreversible actions are blocked
5. The resolver resolves the target; the dispatcher dispatches; the bus records everything
6. Loop until the goal is met or a stop condition fires
7. On success, the compiler emits a draft Capability

Output

evidence/discovery/<run_id>/
  trace.jsonl        authorize / resolve / dispatch / observe, actor-tagged;
                     each llm_call carries the gateway's provider and request id
                     and the measured latency_ms;
                     run_end carries the stop reason and budget (steps, tokens, elapsed)
  snapshots/         UiSnapshot per step
  screenshots/       redacted
  run_record.json    timings, model, tokens_used -- summed from the llm_call events,
                     and equal to the budget's token count
evidence/capabilities/<id>@<version>.yaml

Verify it was live

make verify-live                                   # the newest evidence/discovery/disc-* run
make verify-live RUN=evidence/discovery/<run_id>  # a specific one

Hard checks fail the command: a named, non-scripted model, tokens spent, and a gateway-issued request id on every model call. A median latency under 100 ms only warns, because a hosted model rarely answers that fast but a local gateway with a warm cache can. Runs recorded before latency_ms existed fall back to timestamp gaps and are labelled derived, not measured.

If it fails

Run a Replay

Replay is the deterministic half: the production execution path. No model, no decisions, no surprises.

make app
cua replay evidence/capabilities/corebank.member.savings_balance@1.0.0.yaml \
  --input member_id=67890

Exercising error paths

Faults are armed on the mock app out of band, never through cua replay (it has no fault flag): POST /_control/arm with {"fault": <name>, "count": <n>} (-1 = every request), after signing in. cua console --capability <ref> --arm-fault <name> does the same for a supervised run.

The session_timeout remedy needs corebank.auth.sign_on in the catalog and the operator credentials as secrets (CUA_SECRET_COREBANK_OPERATOR_ID, CUA_SECRET_COREBANK_OPERATOR_PASSWORD). Without either it fails closed as RECOVERY_EXHAUSTED.

Debugging a failure

Determinism

Same artifact + same inputs + same app state ⇒ identical decision trace. If two replays diverge, that is a bug in this system, not flakiness.

Handle an Escalation

A run stopped because it could not safely proceed. This is a designed outcome, not a crash.

Taking control

cua console          # http://localhost:8812

Claim takes the lease. The lease epoch increments, and any in-flight automation dispatch is refused with LEASE_LOST.

You are driving the same live session, not a copy.

What you can and cannot do

Handing back

Release diffs session state, records human_delta, and returns the lease to automation. The console does not restart the run itself; when a caller resumes it (ReplayExecutor.resume(), as cua demo does), the executor:

1. Scans forward from the step that escalated
2. Skips a step only if its postcondition already holds (a step with no postcondition is never skipped)
3. Resumes at the first step not visibly done, provided its precondition holds
4. Otherwise stops with UNEXPECTED_STATE

Afterwards

A recurring escalation is a capability defect, not an operations problem. Usual fixes:

• Screen seen repeatedly but undeclared → add an outcomes or recovery entry
• TARGET_AMBIGUOUS on the same step → tighten the descriptor
• Rising drift_score for one tenant → add a TenantBinding overlay, or re-record