Pilot tracks

One workflow.
A boundary worth proving.

We are developing three focused pilot tracks. Each engagement starts with a bounded workflow, agreed success criteria and an evidence review. These are development paths, not completed customer deployments.

01 / Final Gate

Controlled
tool actions.

Core prototype · pilot scoping

Evaluate an authorization boundary before a selected tool action. Define who can authorize it, the permitted scope, when execution must stop and what evidence the decision must leave.

Possible starting point: one file operation or one sandboxed API action. The pilot should remain small enough to demonstrate both permission and refusal.

  • A named owner and an explicit action scope.
  • Agreed cases where missing or stale authorization must stop the action.
  • A review of the decision record and the observed external effect.

02 / Governed remediation

Governed
remediation.

Proposed integration · pilot scoping

Explore AI-assisted code remediation in an isolated workflow. Review proposed changes and validation results, with human authorization before any agreed merge or deployment step.

Possible starting point: one authorized repository and one class of security finding, using a non-production environment.

  • A reviewable change proposal with validation results.
  • Clear separation between passing a test and permission to merge.
  • No autonomous merge or deployment within the proposed pilot scope.

03 / FlowRouter

Policy-bound
routing.

In development · pilot scoping

Explore how a selected workflow can continue, request verification, escalate or stop under defined policy. Make route decisions and blocked actions visible for review.

Possible starting point: a controlled comparison of permitted local, verification and cloud routes, with explicit constraints on what data may leave the environment.

  • Agreed routing rules and data boundaries.
  • Expected decisions for the same defined input and policy state.
  • Recorded reasons for continuation, verification or refusal.

How we scope a pilot

Small enough to inspect.
Meaningful enough to matter.

  1. 01Name the action

    Where does AI work create an external effect?

  2. 02Set the authority

    Who may approve it, within which scope?

  3. 03Define refusal

    What must cause the action to stop?

  4. 04Agree the proof

    What result and record will be reviewed?

Scope, timetable, fees and acceptance criteria are agreed individually. No pilot availability, result or production readiness is implied by these descriptions.

Start with one workflow

Where does AI output become action?

Define the action, name the authority and agree what evidence would demonstrate control.

Discuss a pilot