Autopilot
Guide status: Governance guidance. Last reviewed 14 August 2026. Only action domains, controls, history and rollback behaviour visible in the installed version should be treated as implemented.
Purpose
Autopilot is the supervised execution layer of the operating system. It allows approved classes of work to proceed within explicit limits while keeping the merchant's authority, auditability and ability to intervene intact.
Autopilot is not a universal permission for Liva 7 to change the store. Authority should be granted per action domain, with scope, constraints, duration, failure behaviour and review conditions. A capability described in product direction is not available until the installed application exposes and records it.
Before you begin
- Start in Observe or Recommend until evidence and operating behaviour are understood.
- Identify the precise action domain, such as preparing content or adjusting an eligible placement.
- Confirm the people authorised to change policy and review history.
- Define commercial, privacy, inventory, brand, market and time limits.
- Know how the current experience will be preserved or restored if execution cannot complete safely.
Set authority deliberately
Observe permits analysis without proposed or executed changes. Recommend permits proposals but no execution. Ask First requires an authorised decision before each applicable action. Auto-execute permits only the defined action class inside the approved policy.
Choose the lowest level that supports the operating need. New, high-impact, difficult-to-reverse, externally billed or poorly measured actions should not begin in Auto-execute.
A complete policy
- names the allowed action and excluded actions;
- defines eligible products, audiences, placements and markets;
- sets value, volume, frequency and duration limits where relevant;
- states the evidence or readiness required before execution;
- defines safe fallback, stopping and escalation rules;
- records who approved it and when it must be reviewed.
Execution records should connect the triggering evidence, applicable policy, requested change, actual result and later outcome. Absence of an error is not sufficient proof that a storefront change is live.
Supervise and intervene
Review policy use, exception rates, unavailable states and outcome guardrails. Pause or reduce authority when evidence quality changes, the store structure changes, repeated fallback occurs, or measured outcomes breach the agreed boundary. Do not broaden authority automatically because one action succeeded.
Safe use and fallback
When policy, evidence, eligibility or target state cannot be verified, the safe result is no material change. Preserve the current experience, record why execution did not proceed and request review where appropriate. Credentials, Shopify account ownership, app charges and other platform-controlled actions remain outside unattended operation.
You are finished when
- each enabled action domain has a narrow, explicit policy;
- the policy owner, review date and stop conditions are recorded;
- execution and live verification are auditable; and
- safe fallback has been tested for the actual surface.