Fill the evidence map with enough signal to find better AI bets.

This is a builder-focused quick reference: fill order, section cheat sheet, and the interview sprint loop. For the full product guide — concepts, workflow, context lenses, reading results, and multi-day programs — see the user guide. For consultant-led interviews and evidence elicitation prompts, use the consultant interview guide.

The builder turns what you know about a company into a structured model. You do not need every field — 101 evidence-backed plays are tested as you add the facts that support them. On Review, green chips in Pattern coverage mean a pattern is already grounded; expand Not supported yet for section-level evidence guidance on what to strengthen next. On Evidence, the evidence preview gives a compact readout (supported patterns, top gaps, leading candidate) without the full board in your way.

For most companies, an honest model is a multi-person, multi-day discovery program, not a form you finish in one sitting. Work Source → Evidence → Review one step at a time: add facts → Analyze → close the top gaps → repeat. You get value on a partial model; missing support is a roadmap, not a failing grade.

Fast start

1. Step 1 · Source — set Company context (SME lens, department lens,

data-maturity lens, peer lens) when they help; Load an example, Auto-map, generate a pre-assessment starter, or resume a saved model.

1. Continue to Evidence — set Archetype and resource level in Company;

the builder reorders sections and adapts gap questions to your company stage.

1. Use Build your evidence map (+ Offering, + Process, …) or load from auto-map

(`.txt`, `.md`, `.html`, `.pdf`, `.csv`, `.xlsx`, …), including annual and quarterly reports. New sources propose merge patches — review before apply. Auto-map is a starting draft only — do not stop there. If you use Generate pre-assessment starter, the app keeps the result in a starter workflow: a company-specific first read, 2-3 unranked AI-use-case directions, operational hypotheses, and the gaps that decide whether to run the bounded free workshop and move to a paid sprint — not the unlocked Review board yet. Each direction shows the visible company fact, what AI could do, the possible business effect, and what the workshop must prove before it becomes a recommendation. Download working paper is the advisor copy. Prepare client send checks your brand, lets you drop thin directions, and downloads a client brief you can actually forward. The app saves the pre-assessment automatically. If the fast first read is usable but too thin, it checks cited external pressure in the background and adds that context to the same pre-assessment; you do not wait for that slower scan before reviewing the initial result.

1. Watch the evidence preview update as you edit (debounced Analyze, no LLM).

When ready, Analyze & Review board — see full coverage, ranked candidates, and Improve the model gaps. Add internal pains, data access, bottlenecks, and abstractions — sharper evidence produces sharper candidates. When a blank-sheet pain question will not work, save the model and open Pain Discovery from the header. Use Map from evidence on high-priority gaps when facts live in CRM/ERP but shouldn't be uploaded raw. Use Develop use cases on Review when you want full use cases and packaging for the candidates you checked (after the highest-impact gaps are closed). Use Plan adoption when you need to know what must be established, in what order, and through which route.

Auto-map: draft, not done

Auto-map (website crawl, pasted notes, or file upload) typically captures roughly half to two-thirds of a useful model from public-facing material. It rarely includes:

• Linked pains with severity and cost
• Accessible data flags on high-volume processes
• Bottleneck skills on real workflows
• Project abstractions — the reusable patterns behind defensible bets

Do not rely on auto-map alone. After import:

1. Run Analyze immediately to see which patterns are already supported and

which evidence areas still need work.

1. Work the top gaps in Improve the model — add internal facts, interview

owners, or use Map from evidence for privacy-preserving inputs.

1. Re-Analyze after each enhancement session until high-severity gaps close.

Generic candidates on a thin auto-mapped graph are expected. Company-specific, defensible bets appear once the evidence map reflects how the business actually operates.

For `.csv` and `.xlsx` uploads, Auto-map can produce a first artifact before the full model is complete: deterministic file findings, a file-grounded AI use case, an Open live dashboard action, and downloadable dashboard/one-pager HTML. Use that when you want a week-one pilot that starts from the uploaded file alone.

Annual and quarterly reports can also produce a cited financial profile for review. Comparable asset-utilization, working-capital, and margin signals become explicit opportunities instead of being left as background reading.

Workstation capture: draft workflows, opt-in

After the first Analyze, Add more evidence → Workstation capture drafts `processes`, `assets`, and possible scarce `skills` from an employee's own app/window activity — opt-in, local-first, review-only. With ActivityWatch running locally, click Import from ActivityWatch for a one-click draft. For a hosted Foundry, run the tray agent (`python -m collector.capture_tray`) on each workstation; it pushes only a redacted summary, and your Workstation capture tab shows what has crossed the graduation gate (Ready to review) versus what is still accumulating evidence (Still watching). Same review-before-apply panel as Auto-map. Full setup, including denylists and the CLI path: `docs/WORKSTATION_CAPTURE.md` in the repository.

Pre-assessment starters

The starter workflow is for advisor reuse before the free, bounded Validation workshop. It uses the same source intake as Auto-map but changes the output boundary:

• save the first-pass model as a starter
• keep the Review board locked while the artifact is still free / pre-Analyze
• promote the same saved company record into the normal workflow when you are

ready to run Analyze live

In the workspace card, Pre-assessment starters are listed separately from normal company models until promotion.

Multi-day discovery (what works today)

Use this loop across sessions and contributors:

Important: the model lives in the browser until you Save to server (Step 1 · Source → Saved models / Pre-assessment starters) or copy the YAML tab into a shared file. A refresh without saving loses in-progress work. When signed in, saved models are private to your account.

For the full multi-person workflow strategy and product roadmap, see the user guide and supporting resources.

Recommended fill order

Work top to bottom, but prioritize facts that improve the most downstream recommendations. With an archetype set, the builder may reorder sections (e.g. segments first for greenfield startups).

Pattern coverage (101 patterns)

After Analyze on Review, the coverage panel lists supported patterns individually. Unsupported plays are a distinct count; evidence-area chips show how many of those plays cite each area. The same play can appear in several areas, so those chip counts do not add up to the unsupported total.

Categories span internal workflow improvement, messy exception loops, physical and R&D work, analytics and revenue, financial-report signals, software estate, buying/selling and marketplace transactions, constraints, prerequisites, and external innovation. You do not need every box green — aim for the patterns that match real leverage on this company.

Relationships (edges)

Links between sections are as important as the nodes themselves:

• Offering → serves → Segment — who buys what.
• Offering / Process / Project → uses → Asset — what data or tech grounds the work.
• Offering → reuses → Project — proven capability you productize.
• Process → bottlenecked_by → Skill — where expert judgment gates throughput.
• Process → uses → Data asset — required for Automate/Augment feasibility.
• Initiative → advances → Goal and Initiative → scopes → Process — what

a program is meant to change.

• Process → owned_by → Role and **Process → requires_decision → Decision →

decided_by → Role** — accountability and approval structure.

• KPI → measures → Process — the explicit operating measure.
• Contract → governs → Process, creates_obligation → Obligation, and

counterparty → Account — reviewed post-signature context.

• Process → located_at → Location and **Offering → delivers_via →

Location/channel** — footprint and delivery route.

Use the checkboxes in core sections and typed endpoint pickers in Strategy, governance & footprint. The builder rejects invalid source/target combinations and preserves other valid loaded edges on save.

Section cheat sheet

• Offerings — products/services you sell; delivery `bespoke` + data helps the system spot sales and packaging opportunities.
• Segments — customer groups; pair with offerings and data for retention and forecasting.
• Projects — past delivered work; the abstraction field is the reusable pattern.
• Processes — internal workflows; volume + repetitiveness drive automation; workflow names and pains help the system recognize real exception-heavy workflows; data drives feasibility.
• Skills — people capabilities; `med`/`high` scarcity marks bottlenecks.
• Assets — data (records), tech (platforms), physical (equipment). For tech, fill tech profile fields when you know legacy, security, or reliability posture. For datasets/data products/models/AI systems, fill the optional Data & AI governance profile only from reviewed evidence. Only tick accessible when usable now.
• Pains — where time/money leaks; always attach to a node when you can.
• Constraints — regulatory, budget, risk, talent, stack — each can surface targeted follow-on work (including software modernization and integration when stack is the bottleneck).
• Strategy, governance & footprint — an optional collapsed group for goals,

initiatives, roles, decisions/approvals, KPIs, contracts/obligations, and sites or channel types. Goals, initiatives, KPIs, and decisions unlock the Strategy & Capital pack when that pack is enabled. Asset ownership, approval, and KPI links also enrich Data & AI Governance. Contracts, obligations, legal-owned processes, and counsel approval links support Legal & Contract Governance. Finance-owned workflows, approval gates, source assets, KPIs, and locations support Finance Planning, Treasury & Tax without adding a separate finance object graph. HR/legal-owned workflows, reviewed skills, obligations, locations, approvals, aggregate KPIs, and privacy/appeal controls support Workforce Lifecycle without a workforce profile or employee record table. Reviewed facility profiles, physical-asset capital-maintenance state, site links, owners, approvals, KPIs, obligations, and source evidence support Assets, Facilities, Energy & Sustainability. Never infer occupancy, lease, meter, energy, EHS, emissions, condition, cost, or approval state. Record only evidence-supported facts. Named channel partners remain Accounts with `kind: channel`.

Hover any ⓘ icon in the form for field-level help.

Interview sprint (the loop that grounds the model)

Every Analyze returns an Interview Sprint panel — interviews are a first-class part of discovery, the mechanism that turns assumptions into grounded facts. It runs a repeatable loop:

`auto-map -> generate interview agenda -> conduct interviews -> extract/update evidence graph -> analyze -> fix gaps -> repeat`

• Agenda — ask first: the highest-leverage questions; **Copy agenda as

Markdown** to share before a call.

• Gap checklist: severity, why it matters, and the questions to ask. Click

the status pill to cycle Open → Captured → Done across a multi-day program.

• Open in builder: jump to the section that closes the gap.
• Conduct interview: open Map from evidence for that gap, capture

evidence, extract proposals, review, and apply.

Applying proposals re-Analyzes the model, marks the gap Captured, and shows progress. Repeat until high-severity gaps are gone, then Develop use cases (and Plan adoption if you need foundations, order, and route). Analyze uses no LLM. Your model and sprint checklist autosave to this browser.

Plan adoption can raise a second question type: missing foundations and diligence questions tied to that plan. These open on Interview Sprint's Adoption readiness filter, not as unlabeled discovery gaps. Show all gaps stays on Discovery evidence; the readiness filter talks about questions. Navigation is explicit in both directions: Resolve readiness questions from the plan, Return to readiness questions after adding Evidence, and Back to adoption plan from the question view. Once all are reviewed, Update adoption plan replans against the latest evidence.

Use Open evidence map or Download evidence map at any point to create a self-contained HTML exhibit of reviewed graph facts, recorded source classes, cited financial metrics, open gaps, and the current ranked opportunities. It is viewable offline without the app; it is a proof-of-process export, not a complete review-history audit log.

Download PDF on Review builds a customer-safe AI Opportunity Review from the ranked board and a cited company digest. It requires active Sprint or Custom access for the current workspace, and the server refuses the export when sendability checks fail.

High-severity gaps (no linked pain, a high-volume process with no accessible data, a project with no abstraction) hurt ranking the most — close those first. Candidate cards also show Evidence that would strengthen this plus an Add in builder shortcut, so you can improve a specific opportunity without hunting through the form.

Map from evidence (Private Evidence Discovery)

When facts live in internal systems, you may not want to upload raw CRM/ERP records. The Interview Sprint → Conduct interview → Map from evidence flow closes gaps from privacy-preserving inputs:

Workflow: pick a gap → choose a tier → add observations → Extract → review proposals in Evidence review → apply only selected patches → re-Analyze. Raw evidence is not persisted; only human-approved facts merge into the graph.

For stricter boundaries, teams can run the LLM against a customer-controlled endpoint (`LLM_RUNTIME=vpc_local`) so extraction never crosses a public API.

Analyze vs Plan

Use the feasibility / moat slider (or Risk appetite) to tilt toward quick wins vs defensible bets.

After Analyze, check Include in Plan on the candidate cards you want to take forward. The default selection is the top five non-generic candidates; the selection bar gives you Top 5, All, and Clear shortcuts. Prerequisites for checked candidates are included automatically. Use the How far should use-case development go? slider to decide whether you only need the roadmap or want to continue through blueprint, scaffold, validation, mock execution, human pilot, and production handoff.

Next-step engagement paths

Review is for understanding and challenging the ranking. It now offers two outcome-led next steps instead of presenting commercial packages as peer settings:

• Validate the shortlist opens the Validation workshop page, which explains

the facilitated evidence review, participants, deliverables, exclusions, and commercial next step. The workshop stops at Analyze and a bounded shortlist validation record; selecting it grants no paid product access. The free workshop does not rank opportunities, compare scorecards, or produce economics/adoption sequencing.

• Turn the shortlist into a decision plan opens the Opportunity sprint

page. A user can request Sprint for the current workspace, but only a site administrator can activate it. A request cannot replace an active engagement or a pending Custom assignment. An activated workspace can return with the standard sprint configuration applied: system-data graph, critique, and dossiers on; agent stages off; depth at Roadmap. The configuration does not execute any action.

The server—not a browser preset—enforces these workspace entitlements. Develop use cases and Plan adoption require active Sprint or Custom access. Under Sprint, agent blueprint, scaffold, pilot, and production stages require a separately approved Pilot handoff for each saved-model candidate. Approving one candidate never unlocks the others. Custom remains the explicit workspace-wide exception. Analyze remains available. Advanced engagement configuration appears only for Custom-entitled workspaces (plus site administrators and auth-disabled local development); it is not a third standard offer.

Plan adoption compares rollout sequences. It is not Pilot executions, which test agent behavior on mock cases. Agent-behavior simulation stays with a later pilot handoff.

What raises agent readiness

The Agent blueprints option attaches a deployment-readiness status to each selected opportunity, computed from your graph (not the LLM). The same facts that sharpen candidates also justify creating an agent — to move a blueprint from *needs discovery* toward *ready*, add a clear pain case, usable evidence at decision time, company-specific grounding, prerequisite work that is already handled, and enough operational detail (owner, approval boundary, past examples) to seed evaluation.

Strategy/commercialization plays (e.g. adjacent growth or packaging ideas) are intentionally capped at *prototype only* — they are product ideas, not operational agent loops.

What improves scaffold quality

The Agent scaffolds option builds pilot-ready material (runtime contract, eval suite, gap workflow, pilot package) on top of the blueprints. Beyond what raises readiness above, the following evidence makes the scaffold concrete and safe to pilot:

• Sample records (a few redacted tickets, invoices, RFQs) — seed golden and

edge-case evals instead of purely synthetic ones.

• Named tools/systems the agent would touch (CRM, ticketing, ERP) — realistic

tool contracts, permission manifest, and mock connectors.

• Write vs draft-only permissions — the human-approval workflow and

least-privilege scopes hinge on this.

• Approval boundaries (what needs human sign-off) — shape approval steps and

unsafe-action checks.

• Past successful cases / resolutions — become golden cases and before/after

metrics for the pilot.

Scaffolds are pilot accelerators, not live deployments — scaffolding plus a validation loop to prove an agent before any production rollout.

What improves pilot-validation quality

The Pilot validations option checks whether a scaffold is actually complete and safe enough to run a mock pilot with — never against a real system. Beyond what improves scaffold quality above, the following evidence raises the readiness verdict from *needs evidence* toward *ready for mock eval*:

• A named mock connector per tool — closes the gap that otherwise leaves

a tool's stub "uncovered" in the mock connector pack.

• A pass/fail rubric alongside golden cases — without one, the golden

cases exist but can't be judged, so the eval run plan isn't runnable.

• A human-approval workflow for every write/action tool — this is the one

gap that alone forces the verdict to *unsafe to pilot*, regardless of everything else.

• Closed evidence tasks from the readiness gap workflow — open tasks keep

the verdict at *needs evidence* even when everything else checks out.

• Unsafe-action checks — expected wherever a write/action tool exists;

their absence is flagged as a gap in the eval suite.

Pilot validation never talks to a real customer system — it proves a scaffold is worth building against one.

What improves mock pilot execution quality

The Pilot executions option actually runs a `ready_for_mock_eval` validation's eval plan against mock connector stubs — offline only. Beyond what improves pilot-validation quality above, the following evidence raises the odds the mock run passes rather than fails or blocks:

• Fixture-shaped sample inputs and expected outputs on every case — a

case missing an expected output can't be graded and is scored `fail`, not skipped.

• A case that actually exercises every unsafe-action check — a check that

is declared but no case shares its keywords with shows up untested, and pairs with any write/action tool to force `unsafe to run`.

• A realistic, parseable `minimum_pilot_threshold` (e.g. "90% precision")

— without one, the run conservatively assumes a 100% pass requirement.

• A named mock connector for every tool — the same gap that leaves a

tool "uncovered" in the validation's connector pack blocks every case in the execution run, not just that one tool.

• Closed evidence tasks and an approved runtime contract — execution

refuses to run at all while the underlying validation is `needs_evidence` or `unsafe_to_pilot`; it reports why and stops there.

Mock pilot execution proves the scaffold's wiring — tool coverage, fixture completeness, safety-check coverage, threshold discipline — is sound. It does not grade real agent reasoning: a mock connector stub is defined to echo back the fixture-declared expected output, so this is a wiring check, not a substitute for testing against a live system.

What improves human pilot quality

The Human pilots option converts a `mock_eval_passed` execution into a structured pilot plan a technical owner can execute. Evidence that raises the odds the pilot plan clears all gates:

• A named pilot cohort (`users`) — the manifest blocks if no pilot

participants are identified. Add names or team identifiers to the pilot package in the scaffold.

• Sample data requirements — specify the scope and redaction requirements

for real records the pilot needs.

• Kill / rollback criteria — explicit stop conditions are required before

a human pilot can be scheduled.

• Security review checklist — the gate blocks without a completed or

scoped security checklist.

• Success metrics (`before_after_metrics`) — measurable before/after

outcomes let the pilot produce a defensible verdict.

• A named human approval owner for write/action tools — the manifest

requires `human_approval_workflow` when any write/action tool is declared; without it, no human pilot can start.

What improves production deployment quality

The Production deployments option converts a `ready_for_human_pilot` plan into a production readiness package. Evidence that clears the production gates:

• A completed human pilot — the gate requires `ready_for_human_pilot`;

anything else blocks.

• Rollback / kill switch criteria — required at the production stage, not

just the human pilot stage.

• Monitoring plan — define alerting and observability targets before the

package is assembled.

• Security review checklist — the same checklist required for the human

pilot must also be present at the production stage.

• Sign-off checklist — named owners who must sign off before production.
• Eval plan with golden cases and a rubric — the production eval plan

converts these directly into a regression suite. Without them, the production gate blocks.

• Approval owner for write/action tools — the same requirement from the

human pilot carries through; still required in the production package.

Downloading the deployable scaffold

Once a candidate reaches a production deployment, its card gets a Download deployable scaffold (code) button — a zip of real starter files (`agent/runtime.py`, tool adapters, `.env.example`, `Dockerfile`/`docker-compose.yml`, an eval harness, `OPERATING_MODEL.md`, and a handoff README) generated deterministically from that candidate's runtime contract and connector inventory. What's inside follows an honesty boundary per tool, not one mock skeleton:

`agent/runtime.py` reasons for real by default — a genuine LLM tool-calling loop, or (for the ticket + FAQ spreadsheet shape) a real batch runtime that drafts replies from bundled data. Every write/action tool is blocked until a human sets `AGENT_APPROVE_WRITES=1`. This is a scaffold, not a live deployment: no credentials are created and nothing is provisioned — a technical owner still supplies real credentials, an LLM key, and verifies any remaining mock or best-effort adapters before running this unattended.

Delivery support vs deployment stage. Cards show what UCF can deliver (`ucf_native`, `ucf_pilot_only`, partner, external engine, advisory, out of scope) beside the evidence-backed stage. `ucf_native` means a production profile is registered — not that the zip is production-ready. The download button is enabled only for the `build_with_ucf` route. High/Medium/Low tier is scaffold-confidence, not delivery support.

Candidate scorecard (Develop use cases only)

Inside the recommended plan, Candidate scorecard rates each bet 1–5 on:

Color follows the score (green 4–5, amber 3, gray 1–2). These come from the plan selector LLM and may differ slightly from the I · F · M · Q badges on Analyze cards — read the Why these scores line when they disagree.

Tips for better output

• Be specific — "RFQ → quote turnaround" beats "operations."
• Ground with data — accessible datasets lift feasibility, moat, and quality.
• Record real pains — linked pains are the strongest impact signal.
• Watch the coverage panel — expand Not supported yet for section-level evidence guidance when planning interviews; aim for green on patterns that match real leverage, not every box ticked.
• YAML tab — save and reload the model between sessions; switching back from YAML does not re-parse unsaved edits.
• One department per session — use Company context so each contributor sees relevant prompts without drowning in the whole company.