E-signature & Approval
How a finished specification is routed for e-signature, who can sign, separation of duties, and how approvals are recorded.
A specification must be approved by e-signature before it can be built. This is the platform's first governance gate: nothing is built from an unapproved spec, and every approval is recorded.
Routing for signature#
When a spec is complete, open it and choose Route for E-Signature. This locks the spec's content into an immutable version and creates an approval request.
Once routed, the spec can no longer be edited in place — approving a moving target would defeat the signature. If you need further changes, revise the spec, which produces a new version to be signed.
Who can sign#
Who may sign depends on your workspace type:
You are the Authorized Approver for your own work — you can sign your own specification in a single step, and your projects are private to you.
The request is routed to an Authorized Approver in your organization. By default, separation of duties applies: the person who authored the spec cannot sign it — a different approver must. An org admin can switch the workspace to self-serve approval in workspace settings if that policy fits your team.
What a signature records#
Approving a spec records who signed, which immutable spec version they signed, and when — as an append-only entry in the platform's audit ledger:
{
"event": "spec.approved",
"spec_version": "sv_3f8a2c",
"signed_by": "u_finance_lead",
"signed_at": "2026-07-01T14:32:10Z"
}The same pattern gates deployment: promoting a built application to a running URL is a separate approval, so the person accountable for what ships signs off before it goes live.
After approval#
An approved specification is handed to the Build Agent, which builds the application from it in a sandbox.