Discussion Points — AI Transformation

01

Problem statements

P1

Answers cannot be trusted

No traceable definition or source.

P2

Logic lives in spreadsheets

Undocumented, unversioned, person-dependent.

P3

Knowledge is scattered

Rules live in inboxes and decks.

P4

Effort is duplicated

Every project rebuilds the same plumbing.

Why — why these and not 'we need AI'

None of these are model problems. They are definition, permission, ownership and reuse problems — a model does not close them.

02

Approach in one line, then in five moves

One governed spine. Thin verticals on top, each provable in a phase.

01

Frame

Agree the question and the success test.

02

Baseline

Cost, cycle time, error rate — before building.

03

Thin slice

One use case, end to end, in production.

04

Harden

Evaluation, permissions, audit, rollback.

05

Scale

Each next vertical costs a fraction.

03

Key pillars

Computed numbers

Language is generated. Arithmetic never is.

Inherited permissions

Systems act as the asking person.

Provenance by default

Definition, filters, as-of time, source.

Evidence over impression

A scored suite decides what ships.

04

Foundations before verticals

FOUNDATIONS — built once, reused by everything

enables ↓

VERTICALS — weeks each, once the above exists

Hover a block for a one-line summary — click it for the reasoning and what we are assuming.

Built onceThin verticalNeeds all four foundations

05

Architecture at a glance

Cutting across all five: identity, audit trail, cost control and version history. These are the difference between a demo and a system.

Hover a block for a one-line summary — click it for the reasoning and what we are assuming.

06

Implementation and Delivery

S1

Embedded squad

We work inside existing teams.

Best when: Capability exists but is stretched.
Time to first value: Fast
Main risk: Progress tied to host-team capacity.

S2

Build and hand over

We build, then transfer ownership.

Best when: Speed now matters more than in-house depth.
Time to first value: Fastest
Main risk: Knowledge leaves with the team.

S3

Foundation first

Spine first, verticals in parallel after.

Best when: Several projects are already committed.
Time to first value: Slower, then compounding
Main risk: Foundations feel invisible early on.

Design decision — what we would suggest

Start narrow and vertical to earn trust, but build that first vertical on foundation components from day one — so the second project inherits rather than repeats.

Hypothesis — open for discussion

Sequencing depends on who can approve a definition and how quickly data access can be granted. Both are unknown to us today and are the first questions we would want answered.