08 — Assumptions & open questions

What we do not know yet, stated plainly — and what each answer would change.

Everything here about the current estate is an assumption, because we have not inspected it. Collected as a checklist with status, reason and the decision each answer would move — the agenda for a first working session.
8.1

Standing assumptions behind this document

Executive

If any of these is wrong, the corresponding sections change rather than merely losing detail.

Assumptiontechnology environment

We have taken the described environment at face value — a collaboration and automation estate, reporting and semantic platform, planning platform, cloud warehouse, spreadsheet models with live business logic, general integration and scripting capability — without verifying versions, licence tiers or actual usage.

Assumptionorganisational readiness

We assume named owners can be identified for data domains and definitions, and appetite exists for a capability that refuses unsafe questions. Both are organisational conditions that materially affect what can be delivered.

Hypothesiswhere the effort actually sits

Dominant effort sits in the foundations — definitions, permissions, knowledge curation, evaluation — not model integration. The conversational surface will look easiest while being most dependent. We'd test and revise this openly.

Hypothesishighest early return

Hardening and monitoring the existing automation estate likely offers the fastest measurable return — no new user trust, no new data governance needed. A hypothesis about typical estates, not this one; the automation inventory would confirm or refute it within days.
8.2

Access and environments

These determine when work can start, not how it is designed. They have the longest lead time.

Path to a non-production environment with representative data — and realistic timeline.

blocker if false
Why it matters / what it changes

Why: Every design decision below can be made on paper; none can be validated without it.

Changes: Sets the start date of the first slice and whether early work is real or preparatory.

Can queries run under a delegated end-user identity, not only a service principal?

blocker if false
Why it matters / what it changes

Why: Permission inheritance is a hard requirement for any conversational analytics surface.

Changes: If only service identities are possible, the capability must be redesigned or deferred.

Which source systems are API-reachable, export-only, or neither?

to confirm
Why it matters / what it changes

Why: Determines integration effort and whether a temporary bridge is needed.

Changes: Directly changes effort estimates and the operational risk profile.

Constraints on data processing location and retention of prompts/traces/outputs.

to confirm
Why it matters / what it changes

Why: Trace design and model routing depend on it; retrofitting is expensive.

Changes: Affects architecture at the orchestration and logging layers.

8.3

Data and semantic layer

The quality ceiling of every AI surface is set here.

How many measures are certified today, with owner/description/lineage complete?

to confirm
Why it matters / what it changes

Why: This is the effective answerable-question surface on day one.

Changes: Determines whether the first slice is a build or a certification exercise.

Where do two authoritative metric definitions coexist, and who adjudicates?

blocker if false
Why it matters / what it changes

Why: Contested definitions stall dependent features indefinitely without a tie-break authority.

Changes: Drives governance work needed in parallel with engineering.

What data-quality controls exist today, and their current pass rate?

to confirm
Why it matters / what it changes

Why: Establishes whether promotion gates are new work or an extension of existing work.

Changes: Affects foundation-stream scope.

Refresh latency of the reporting layer, and what as-of semantics an answer should state.

to confirm
Why it matters / what it changes

Why: Users comparing an answer to a report at a different point in time is a common trust failure.

Changes: Affects answer presentation and caching design.

8.4

Legacy logic and documents

The two places where discovery findings most often change the plan.

Can historical calculation runs be reproduced from their recorded inputs?

blocker if false
Why it matters / what it changes

Why: If overrides were applied outside the model, the golden-master approach needs redesigning.

Changes: Changes the parity strategy and effort for the calculation vertical.

Who can adjudicate an unexplained legacy rule?

blocker if false
Why it matters / what it changes

Why: Rule adjudication is on the critical path and needs a decision-maker, not a forum.

Changes: Determines whether parity testing can complete.

How heterogeneous is the document estate (template, vintage, language, quality)?

to confirm
Why it matters / what it changes

Why: Extraction accuracy varies far more by heterogeneity than by model choice.

Changes: Drives extraction effort, validation-queue sizing, accuracy expectations.

Volume and time budget available for human validation of extracted fields.

to confirm
Why it matters / what it changes

Why: Reviewer throughput is a real system constraint; thresholds must be set against it.

Changes: Determines confidence thresholds and rollout pace.

8.5

Platform capability

Native capability moves quickly — verify against the tenant, not documentation or prior experience.

What can native agent / semantic-model querying do in this tenant and licence tier today?

to confirm
Why it matters / what it changes

Why: Sets the configure-versus-build line — the largest single swing factor in effort.

Changes: Could remove or add substantial build scope in the conversational vertical.

Which model providers/versions are approved, and who approves a change?

to confirm
Why it matters / what it changes

Why: Model pinning, fallback strategy and evaluation cadence all depend on it.

Changes: Affects orchestration design and operational process.

Existing automation estate: how many flows, owned by whom, failure history?

assumption
Why it matters / what it changes

Why: Hardening critical existing automations frequently returns more value than new builds.

Changes: Determines the first workflow-automation backlog.

Current knowledge-management practice, and who owns content today?

blocker if false
Why it matters / what it changes

Why: A knowledge system without named owners degrades within months regardless of architecture.

Changes: Determines whether the knowledge vertical is viable near-term.

8.6

Ways of working and expectations

Organisational answers that shape delivery as much as any technical one.

Which engagement scenario fits: embedded, build-and-handover, platform-first, or hybrid?

to confirm
Why it matters / what it changes

Why: Determines team shape, governance and how handover is engineered from commit one.

Changes: Shapes the whole delivery plan.

Named business and technical owners per capability — have they accepted?

blocker if false
Why it matters / what it changes

Why: An unaccepted owner is not an owner, and the definition of done depends on one existing.

Changes: Gates release for every capability.

Is there a fixed external date anything must land against?

to confirm
Why it matters / what it changes

Why: A real deadline changes sequencing legitimately; an assumed one degrades quality for no reason.

Changes: Determines whether scope or evidence flexes under pressure.

Appetite for a capability that refuses questions it cannot answer safely.

assumption
Why it matters / what it changes

Why: This is the central trade-off of the whole programme and should be agreed explicitly, in advance.

Changes: Sets refusal thresholds, launch scope and how success is judged.

8.7How we would run the first two weeksImplementation