Follow the managed-build lifecycle and approval gates

A managed build moves through explicit stages so a request, blueprint, draft, approval, delivery, and live run are never treated as the same event.

Request ID and build ID

An ORD-... ID identifies the original managed-build request and its estimate.
A BLD-... ID identifies a delivered reusable system owned by one Signaliz workspace.
A UUID run_id identifies one intended execution of a delivered build.

Do not use an order ID as a build ID. A request can exist without a Final Build, and only Final Builds are exposed to API, MCP, CLI, and SDK clients.

Build stages

Stage	What it means	What it does not mean
Received	Signaliz stored the request and estimate.	The blueprint is not approved, no payment was taken, and no build is delivered.
Approved	The customer and Signaliz accepted the blueprint, scope, price, and operating boundaries.	The workflow has not necessarily passed its first QA cycle.
First Draft	A reviewable implementation exists with the agreed input, output, and QA contract.	It is not approved for finalization or live customer operation.
Customer Approved First Draft	The customer accepted the reviewable implementation or recorded required corrections.	Final delivery and the reusable run surface may still be incomplete.
Final Build	Signaliz finalized the system, assigned the customer workspace and tested routine, and published the delivery contract.	It does not authorize downstream sending or writes outside the approved scope.

If a material outcome, integration, volume, or cadence changes after approval, Signaliz may need a revised blueprint and renewed price acceptance before continuing.

What to review at First Draft

Check the implementation against the blueprint:

required input fields and accepted formats;
company, person, or record identity rules;
evidence, qualification, and exclusion policy;
branching and exception behavior;
expected output fields and failure states;
sample results and their provenance;
batch size, cadence, and delivery interface;
credit assumptions and measured execution budget;
prohibited actions and approval gates.

Record corrections against the draft. Do not approve it based only on a screenshot, preview, or successful test of one happy-path row.

Review-held execution

Managed Builds are review-held by default. These artifacts are handoffs, not permission:

an audience or contact file;
review-ready outreach copy;
a prepared CRM change set;
an available CSV export;
a configured connector;
a successful test run.

CRM writes, file uploads into customer systems, campaign enrollment, activation, and sending require the action to be explicitly included in the approved scope and the required customer approval to be recorded. When the approved scope stops at preparation or review, Signaliz must stop there.

Final Build handoff

Before treating delivery as complete, verify:

the BLD-... ID appears in the correct customer workspace;
status is Final Build;
the input and output schemas match the approved blueprint;
delivery notes and operating runbook are present;
the fixed Signaliz-credit price and Clay-credit budget per run are visible;
the included API, MCP, CLI, webhook, CSV, or workspace surface works;
a test run has a durable run receipt and expected result fields;
locked actions remain locked.

Next: Receive and own your delivered system.