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