Reference build · Controlled workflow automation
A workflow that stops exactly where human judgment begins.
A deterministic browser-based reference showing validation, allowed state transitions, explicit approval, idempotent retry behavior, and a visible audit trail.
- Proof type
- Reference build
- Audience
- Agencies and operations teams scoping controlled automation
- Timeline
- Reference build reviewed in July 2026; no client implementation timeline is claimed.
- Last reviewed
01 / Buyer and problem
The system had one clear job—and explicit limits.
A request-routing automation can create bad downstream records when required data is missing, approvals are bypassed, or retries duplicate the same action. The important behavior needs to be visible before integrations are added.
Who this helps
The reference focuses on workflow behavior that can be reviewed before a real CRM, inbox, or task system is connected.
Exact role
Designed and implemented as a local reference build, including workflow states, validation branches, approval controls, simulated adapter behavior, audit history, and browser tests.
Constraints
- Run entirely in the browser with fictional data and no real CRM or network side effect.
- Allow only declared events to advance the state machine; stale actions cannot skip validation or approval.
- Keep approval, rejection, failure, and retry outcomes explicit and inspectable.
- Use one duplicate-prevention key across an explicit retry path.
Scope
- Deterministic workflow state machine
- Required-data validation
- Human approval and rejection path
- Local CRM-response simulation
- Idempotency and explicit retry behavior
- Visible state and audit history
02 / Architecture
A visible path from input to controlled result.
- 01
Request interface
Three fictional scenarios expose complete, missing-data, and adapter-failure paths.
- 02
State machine
Declared transitions prevent stale or out-of-order actions from bypassing required steps.
- 03
Approval gate
The proposed action, reviewer, destination, and duplicate-prevention key are visible before a decision.
- 04
Local adapter
CRM responses are simulated in the browser; no external system receives data.
- 05
Audit record
Each transition records the technical state, event, visible result, and reason.
03 / Delivery process
The work, in the order it became verifiable.
- 01
Define the state contract
List every allowed state, event, stop condition, and visible result before implementing the interface.
- 02
Validate before preparation
Incomplete requests stop for the missing value instead of guessing or preparing an invalid downstream action.
- 03
Prepare without dispatching
The exact proposed task becomes reviewable while the simulated delivery count remains zero.
- 04
Require an explicit decision
Approval advances to the simulated adapter; rejection ends the run with the reason in the audit record.
- 05
Expose failure and retry
A failed simulated attempt stays stopped until the person selects a retry that reuses the duplicate-prevention key.
04 / Decisions and tradeoffs
The useful part is why the boundary exists.
Use deterministic branches instead of generated decisions
Approvals, required values, retry behavior, and outcomes should be inspectable and testable.
- Tradeoff
- The reference does not demonstrate model-led classification or enrichment.
Stop on failure until a person retries
Silent automatic retries can make duplicate side effects harder to diagnose.
- Tradeoff
- A real implementation would need an agreed operational queue and response expectation.
Keep the adapter local
The public lab can demonstrate behavior without creating records in an external account.
- Tradeoff
- It is not evidence of a production CRM integration.
05 / Evidence
What can be inspected—and what cannot be claimed.
- Scenario coverage
- 3 visible paths
Complete request, missing data, and simulated delivery failure each have a declared on-screen outcome.
- Approval boundary
- 0 tasks before approval
The reference keeps simulated delivery impossible until the named approval event is recorded.
- External side effects
- None
The public project runs locally in the browser and does not contact a CRM or create a customer record.
- Commercial result
- Not claimed
No lead-volume, booking, labor, response-time, or revenue outcome is attributed to this reference.
06 / Outcome and handoff
A working, testable reference that lets a reviewer inspect where a bounded automation validates, pauses, fails, retries, and records its result.
Services connected to this work
Technologies used
- Astro
- TypeScript
- Finite-state workflow
- Idempotency
- Playwright
Planning a controlled automation?
Define the stops before connecting the systems.
Bring one workflow, the person who approves it, and the failure that must never become an invisible retry.
Book a 20-minute fit call