FFrameAlpha
Technical approachDiscussion pointsWho am I

04 — Delivery model

Structure the engagement around evidence gates, not calendar dates.

The risk is not that engineering takes longer than expected — it is that a capability reaches users before anyone can demonstrate it is correct.
4.1

Three engagement scenarios

Executive

Genuine alternatives with different cost, speed, ownership and risk profiles — the right one depends on discovery findings.

Scenario A

Embedded squad

Model
We work inside existing teams as senior capacity, following existing tooling and governance.
Strengths
Fastest context, continuous knowledge transfer, low disruption.
Costs & risks
Throughput bounded by host team's capacity and cadence.
Best fit
Internal teams are strong; constraint is capacity, not direction.

Scenario B

Build and hand over

Model
We own delivery end to end, then transfer to a named internal owner against a handover standard.
Strengths
Highest velocity, consistent standards, easiest to bound.
Costs & risks
Handover is the whole risk without a named receiving owner.
Best fit
Internal capacity is unavailable and a receiving owner exists.

Scenario C

Platform first, then verticals

Model
A foundation stream builds shared capabilities; verticals then ship in parallel on top of it.
Strengths
Lowest total cost at scale, consistent behaviour everywhere.
Costs & risks
Slowest visible output first phase; needs sponsorship.
Best fit
Transformation is committed across multiple projects.

Design decision — a pragmatic hybrid

A small foundation stream (C) alongside one embedded vertical (A), with handover standards (B) applied from day one rather than at the end.
4.2

Phases and exit criteria

A phase ends when its evidence exists, not when its time box expires. Durations are planning placeholders.

P02–4 wks

Discovery & baseline

  • · Non-prod access granted
  • · Sources & permissions documented
  • · Baseline metrics captured
  • · First archetype selected

Gate — assumption register reviewed

P14–8 wks

Thin vertical slice

  • · One capability, real data, non-prod
  • · Eval suite passing threshold
  • · Traces visible
  • · Permission test passing

Gate — next-slice estimate grounded in this one

P23–6 wks

Hardening & first release

  • · Monitoring & alerting live
  • · Runbook rehearsed by someone else
  • · Rollback executed once in test
  • · Owner accepted

Gate — limited user group onboarded

P3Ongoing

Scale across verticals

  • · Shared components reused, no forks
  • · Standards documented & applied
  • · Marginal effort falling per vertical

Gate — adoption trending against baseline

P4Steady state

Operate & improve

  • · Scheduled eval runs, published
  • · Knowledge review cadence operating
  • · Drift & cost within thresholds

Gate — backlog fed by real usage

Assumption — access latency

The largest schedule risk is elapsed time to obtain environment and data access, not build effort — we would start it on day one in parallel with discovery.
▸Why a thin vertical before anything broad
The first slice is not a pilot to prove AI works — that is not in doubt. It exists to discover the specific, local frictions no architecture document can predict: how permissions actually resolve, how clean the data really is, how long an approval genuinely takes, where a definition is contested. Every subsequent estimate depends on those findings, which is why we would resist committing detailed timelines for later verticals before P1 completes.
4.3Definition of done for an AI-bearing featureImplementation
4.4Ways of workingImplementation