QUESTION 01
Which repository is in scope?
The pilot needs a real repository, not a hypothetical use case.
PILOT PROCESS
What happens after the demo.
The first sale is not a vague platform promise. It is a scoped pilot with a technical owner, one repository, one or more workflows, and a concrete requirement: deterministic execution plus replay and audit visibility inside a real engineering environment.
WHAT THE PILOT IS NOT
Not this
No hosted login rollout
Not this
No broad platform migration
Not this
No claim of autonomous production orchestration on day one
STEP 01
Scope one workflow
repo, owner, constraints, and success criteria are locked first
STEP 02
Install privately
runtime, tools, and review boundary are aligned inside the customer environment
STEP 03
Run proof and review
the customer sees replay, audit output, and a rollout decision surface
DISCOVERY QUESTIONS
Every serious pilot starts with a narrow set of facts, not with a generic request form.
QUESTION 02
Who owns the workflow?
One technical owner is needed to validate policy constraints and output quality.
QUESTION 03
Which workflow breaks first?
Pick the task path where execution variance, debugging cost, or audit gaps already hurt.
QUESTION 04
What constraints matter?
Repository access, hosting boundaries, security policy, and tool restrictions shape the package.
PILOT PREREQUISITES
Before implementation starts, the commercial and technical boundaries need to be explicit.
CUSTOMER INPUTS
- Repository access and one technical owner
- One active workflow to prove first
- Tool and security constraints
- Success criteria for replay and audit visibility
EXECINSPECTOR OUTPUTS
- Installed runtime surface in the target repository
- Deterministic task flow for the agreed workflow
- Replay and audit review surface
- Handoff and next-phase recommendation
WHAT HAPPENS AFTER THE DEMO
A narrow timeline makes the first sale safer for both sides.
01
Scope the pilot
Package, repository, owner, and workflow are selected with clear constraints.
02
Install privately
The runtime is aligned in a customer-controlled repository or private environment.
03
Run the first proof
One or more workflows are executed with replay plus audit visibility in place.
04
Decide the next phase
The team decides whether to stop, extend, or move toward a larger private rollout.
EXPECTED OUTCOME
The first commercial success is operational clarity, not feature volume.
Repeatable workflow
The selected task path becomes easier to run and review with less hidden behavior.
Replay and audit surface
The team can inspect execution history instead of guessing what happened.
Sharper rollout decision
The customer can decide whether the model deserves a broader private deployment.
Clear boundaries
The pilot exposes what is ready today and what still belongs to a later product phase.
WEEK 1 DELIVERABLES
The buyer should be able to point at concrete outputs within the first week.
DELIVERABLE 01
Scoped workflow record
The repository, owner, workflow, and policy boundary are documented in execution terms.
DELIVERABLE 02
Replayable first path
At least one meaningful task path runs with event visibility and a declared node sequence.
DELIVERABLE 03
Review surface
The team can inspect what happened, what was touched, and what remains gated for review.
DELIVERABLE 04
Rollout decision
The customer can stop, extend, or widen the private rollout with evidence rather than optimism.
SAMPLE PILOT BRIEF
The first call should produce a brief that engineering and procurement can both understand.
EXAMPLE BRIEF
Auth Review Determinism Pilot
The brief is deliberately operational: repository, owner, workflow, constraints, and proof artifacts. It avoids broad AI transformation language until the first deterministic path is proven.
BOOKING INTAKE
Start the pilot review inside ExecInspector.
This form writes directly into the internal ExecInspector intake inbox. It is designed for one thing: qualifying a real repository, a real workflow, and a real owner before any pilot is scoped.