AI-native

How AI participates inside Lambda — Gus for ops chat, Edward for bounded stamp recovery.

Lambda is AI-native in a narrow sense: assistants participate inside product workflows with hard boundaries. They do not invent fiscal data, override CargoWise amounts, or stamp without evidence.

Two named roles:

Role	What it is	Who interacts with it
Gus	Read-only ops assistant in the workspace (and Slack for ops)	People in your organization
Edward	Backend stamp-failure recovery for system-owned interpretation mistakes	Runs automatically; humans approve live stamps

Automatic recovery (re-enqueue stuck work) is separate and non-AI. Corrective retry is a human/ops action with its own safety model — see Recovery.

Design rules

• CargoWise capture bytes stay immutable evidence. AI does not claim CargoWise was edited.
• Missing or contradictory fiscal data still fails or waits — AI does not guess RFCs, FX, balances, or parent links.
• Live stamps that change interpretation require human approval when Edward proposes a fix.
• Accountant-owned source issues stay with the accountant path; Edward does not take those over.

Gus

Gus helps you understand invoice status, why a document stopped, and what the note means — using the same workspace labels you already see (Failed, Waiting for parent, Auto fixing, Stamped, and so on).

Gus can:

• Look up invoices in your current organization
• Explain failures and AI-review outcomes in operational language
• Point you to the right document in Lambda

Gus cannot:

• Retry stamps, change amounts, or edit CargoWise
• Leave your organization scope
• Invent fiscal fields that are not in the evidence

Open Gus from the workspace sidebar when you need a status or failure explained without leaving the page.

Edward

Edward runs after a stamp failure when Lambda classifies the issue as a system-owned interpretation mistake — not an accountant source-data problem and not a hard infrastructure outage.

Typical path:

1. A stamp fails for a recoverability class Edward is allowed to handle.
2. The document moves to Auto fixing while Edward inspects the ingress capture and related evidence.
3. Edward may validate a candidate fix in the org test environment.
4. If a live stamp is warranted, the document moves to Awaiting approval and platform admins are notified.
5. A human approves or denies. On deny, Edward stops and reports; it does not keep trying live stamp.

Edward may recover bounded system mistakes (for example certain saldo/installment math or payload conversion issues). It does not invent customer fiscal fields, invent FX, or rewrite accountant-owned source data.

When Edward cannot recover safely, the document stays on the normal failure or support path — Failures and System errors.

What you see in the workspace

Label	Meaning
Auto fixing	Edward is reviewing a correctable system issue before stamp.
Awaiting approval	A proposed live stamp needs a human decision.
Timeline AI-review events	Evidence of what was inspected and proposed.

These labels sit alongside the ordinary stamping statuses. Read Statuses for the full set.

What AI does not own

Area	Reality
Ingress mapping	Deterministic CargoWise XML → intent. Edward may read the capture as evidence; it does not replace the mapper.
Analytics	No AI query engine. Gus may help you navigate; reporting stays SQL / Power BI.
Notifications	Templated product events. AI does not author accountant failure copy for the notification system.
Automatic recovery	Cron/resume of stuck durable work — no model, no intent rewrite.
Corrective retry	Human/ops path with preview proof — Recovery.

Next

• Modules — where stamping and analytics sit relative to ingress
• Statuses — Auto fixing and the rest of the labels
• Recovery — human corrective stamp safety (not Edward)