AI Operational Assistant R0 Development - Senior Full-Stack / AI Engineer — Deliver a Small, Well-Specified WhatsApp + Azure AI Assistant (R0, 80h cap)

We are building **R0** — the first production slice of an operational assistant used by a real, paying French client. This is not a prototype, not a redesign exercise, and not an open-ended AI product build.

The architecture, product behavior, data contract and acceptance criteria are **already decided and documented**. We are buying implementation, not discovery.

You will receive, before you quote:

- a vendor-neutral engineering scope
- a conversation contract (how the assistant must understand and speak)
- an acceptance fixture pack containing **real data and expected outcomes**
- the **source code of our existing PDF generation service**, which you must reuse

Most of the behavioral design work is already done. Your job is to build it correctly.

---

### What the system does

A single operator interacts with the assistant **through WhatsApp** — text, voice notes, documents.

1. **Morning perception.** On weekday mornings the system reads new Gmail messages (read-only), summarizes what appears to need attention, and sends the operator a short brief on WhatsApp — audio first, text below. It does not classify into business workflows, does not reconcile payments, and does not create tasks.

2. **Conversational document work.** The operator speaks or types naturally ("remove the disposal line and set it to 1,490"). Azure OpenAI interprets the instruction against the current structured document snapshot and returns a **strict JSON patch**. The backend validates the patch, applies only what was requested, and writes a new immutable version. Untouched fields are preserved byte-for-byte. A deterministic diff is computed from the data, not narrated by the model.

3. **Controlled external action.** Nothing leaves the system without explicit approval. The operator receives a signed, short-lived mobile review page showing the exact PDF, recipients, subject, body, attachments and diff. Approval is bound to a **fingerprint of the exact action**. Any material change invalidates it. One external effect exists in R0: a single approved outbound email.

---

### Explicitly OUT of scope

Do not price these. They are deliberately excluded:

- inbound email classification, task creation, CRM
- payment matching, banking integration, invoicing, VAT logic, e-invoicing
- schedulers driving business workflows, reminders, follow-up automation
- dashboards, admin consoles, multi-tenant SaaS, role hierarchies
- rebuilding the PDF renderer (it exists and works — you wire it)
- vector databases, RAG pipelines, custom OCR, agent frameworks
- native mobile apps
- any autonomous external action beyond the one approved email

If a capability is not in the scope document, it is out.

---

### Non-negotiable engineering invariants

These are what we are actually buying. A cheaper build that weakens them is not an equivalent build.

- No external action without explicit operator approval
- Approval is bound to the exact action fingerprint; stale approval cannot ride on changed content
- Prior document versions remain retrievable and are never overwritten
- The model proposes; deterministic code validates before anything is written
- Critical unknown data is surfaced or blocks execution — never silently guessed
- Ambiguity produces a question, never a silent best-match
- Text marked verbatim is never rewritten by the model
- Webhook replays and retries never produce duplicate work or duplicate sends
- Uncertain send results are never blindly retried
- No client-specific names, contacts or rules hardcoded in the codebase

---

### Delivery constraints

- **Engineering cap: 80 hours.** If a block cannot fit, name that specific block, explain why, and propose a simplification. Do not raise the total.
- All source code committed **continuously** to a Helix-controlled repository from the first commit. No ZIP delivered at the end.
- Helix owns the delivered code and work product.
- No undisclosed dependency, private repository or vendor-held credential may be required for us to run or redeploy.
- No production secret committed to the repository.
- Acceptance is judged on **observable behavior against the written fixtures**, not on percentage complete. A mock integration does not pass a production gate.

---

### Provided by us before kickoff

- Azure account and model credentials
- WhatsApp Business number, provider account, approved message template
- Google OAuth client and authorized pilot mailbox
- Outbound sender domain and DNS verification
- Existing PDF service source package
- Repository
- Acceptance fixtures with real data
- Conversation contract

Waiting on third-party approvals (Meta, DNS propagation) is **not** charged against your hours.

---

## WHAT WE NEED IN YOUR QUOTE

Reply against the scope document only. Do not re-quote earlier or broader versions of this project.

1. **Lowest fixed total price** for the scope as written.
2. **Total developer-hours committed**, not exceeding 80, with a block-by-block breakdown.
3. **Calendar days** from access/kickoff to final handover.
4. **Who writes the code.** Name the developer(s) and their actual allocation. We prefer a single accountable developer.
5. **Confirmation** that every acceptance gate is included and nothing is deferred.
6. **Any block you believe cannot fit its hour target** — with the technical reason and a proposed simplification that preserves the visible behavior.
7. **Any external access dependency** that could delay delivery.
8. **Written confirmation** of continuous commits to our repository, our ownership of the code, and no undisclosed dependencies.

---

## HOW WE WILL CHOOSE

The winning bid is the **lowest-cost build that passes every acceptance gate within the cap**.

A cheaper quote that removes a gate, weakens an invariant, relies on mocks, or hardcodes client-specific logic is not an equivalent implementation and will not be selected.

We value a precise "this block won't fit, here's why, here's the alternative" far more than a confident "yes to everything".

---

## NOTE TO APPLICANTS

Please read the attached scope before quoting. Generic proposals describing your team's general capabilities will not be reviewed. We are looking for someone who engages with the specific engineering constraints above.