Ask · Transformation.ai

Ask the hub. Get an answer that cites its sources.

Every answer names its sources from the hub, rates its confidence, and states what it doesn't cover. If we can't cite it, we say "I don't know" — because a wrong answer from a research hub is worse than no answer.

Demo · 5 real answers

What an answer looks like.

Five questions a transformation lead actually asks. Five answers drawn directly from published content. Select any question to see the full answer — sources, confidence, limits, and next step included. This is the format the retrieval API will produce.

Question · Pilot stage

Where should we start with AI transformation?

Start with a workflow, not a tool. Pick one where work is repetitive, information-heavy, or slow. Map its data in, its transforms, its integrations, and its outputs before you automate anything. Set a baseline. That is the Pilot stage, and it produces everything the next stage depends on.

Organizations that start with tool selection usually rebuild the workflow map later at higher cost — and after the tool is already in production, which makes every subsequent change a negotiation rather than a design choice.

Confidence
High

This answer is drawn directly from published roadmap and playbook content. The claim that tool-first starts cost more is from the roadmap's documented trap for the Pilot stage.

What this answer doesn't cover

It doesn't tell you which workflow to pick. That depends on your data readiness, team skills, and risk appetite — the AI Readiness Assessment is where that decision gets made.

Question · Pilot stage

How do we know whether a pilot worked?

Three tests. First, does it beat its baseline on task time, quality, or cost under real working conditions — not in a demo? Second, is the human-in-the-loop intervention rate stable and low enough to be sustainable? Third, can you point to the workflow map — data in, transforms, integrations, outputs — that made the result reproducible?

If any of those three is missing, you haven't proven a pilot; you've proven a demo. This is the single most-common reason pilot results don't survive contact with a leadership review.

Confidence
High

The three-test framework is stated verbatim in the measurement playbook. The "3 in 5 pilots start without a baseline" claim is from the 2026 Baseline survey (n=340).

What this answer doesn't cover

It doesn't cover what to do when the pilot succeeded but scaling is blocked. That's an Expand-stage problem — the playbook's section on adoption past the enthusiasts is the place to go next.

Question · Autonomate

How far can we safely take autonomy?

As far as the guardrails already in place — not one tier past them. Autonomy is tiered, not binary: L0 agent suggests, human acts; L1 agent acts with approval; L2 agent acts and escalates exceptions only; L3 agent self-improves within an evaluation ceiling; L4 agent proposes new workflows — anything past L2 requires full guardrails.

Every workflow must have three things before moving up a tier: a kill switch wired to the registry, an audit trail of every action taken, and a stated evaluation ceiling. Most organizations stop at L2 in their first year, deliberately — not because the model can't go further, but because the operating model can't yet.

Confidence
High

The L0–L4 tiers are defined verbatim in the Autonomate roadmap stage. The three preconditions for moving up a tier are stated in the governance playbook and in the roadmap's "advance condition."

What this answer doesn't cover

It doesn't tell you which tier a specific workflow can safely sit at. That depends on the cost of an error, reversibility, and how well you've instrumented outcomes — a workflow-specific assessment the hub doesn't yet offer. It's in the pipeline.

Question · Pilot + Expand

How do we budget AI for 2027?

Budget on workflow volume, not seat counts. Per-seat pricing has a clean property — cost scales with headcount, and headcount is controllable. Per-workflow-volume pricing scales with the workflows you run, which means it's bounded by workflow discipline, not the org chart.

Most 2027 budgets haven't absorbed that yet. The seat line stopped constraining cost, and nothing replaced it — so usage becomes an unpriced overage. The fix is a per-workflow volume × unit cost estimate plus spend alerts at 80% of budget, before rollout, not after.

Confidence
Medium

The direction of the pricing shift is documented. The claim that most 2027 budgets haven't absorbed it is an editorial read on published survey data — not a directly surveyed fact. Treat this as the framework to check, not a number to quote.

What this answer doesn't cover

It doesn't cover vendor-specific contract terms, negotiated discounts, or the fixed platform fees that sit alongside token pricing. Those vary too much by procurement and buyer leverage to state as a general rule.

Question · Executize

Do we need an AI center of excellence?

Sometimes — and when it hurts, it hurts more than it helps. A central team pays for itself when AI work is scattered across functions, compliance risk is high, or shared infrastructure is missing — data pipelines, evaluation harnesses, procurement leverage. It destroys value when it becomes an approval gate.

Most organizations do best with a small central team owning standards and shared services, and business functions owning their own workflows. The size of the central team is not the point; what it owns is.

Confidence
Medium

The general principle is stated in the strategy playbook. The claim that it "hurts when it becomes an approval gate" is an editorial judgment from observation across published case studies — not a surveyed fact. Reasonable practitioners could disagree.

What this answer doesn't cover

It doesn't tell you the exact org design. Whether the CoE sits under the CDO, CTO, COO, or transformation office is contextual — and the answer changes at 200 employees versus 20,000. The playbook's org-model section walks through the tradeoffs.

The format

Anatomy of an answer

Five parts, in order. If we can't complete all five, we don't publish the answer — we say "I don't know" and log the question. That's the whole product.

  1. Direct answer

    The claim, stated plainly, in the first two sentences. No warm-up.

  2. Sources cited

    Internal links, per claim. If a claim can't point at a page, it doesn't ship.

  3. Confidence rated

    High, medium, or low — with what would raise it. The reader judges trust.

  4. Limits named

    What the answer doesn't cover. Bounds beat certainty.

  5. Next step

    The one page to open next. Not three. One.

Scope

What we answer. What we refuse.

The refusals are what make the answers auditable. Without them, "we cite our sources" is a style choice; with them, it's a scope.

We answer

  1. Roadmap and stage questions.

    "Where are we? What's the next artifact? What does an advance condition look like?"

  2. Workflow mechanics.

    "How do we map a workflow? What are the data inputs we should track? How is HITL set?"

  3. Measurement and ROI.

    "What's a defensible baseline? How do we justify a pilot to finance?"

  4. Governance and risk.

    "What tier of review does this workflow need? What must exist before autonomy goes up a level?"

  5. Definitions.

    "What does executize mean here? What's the difference between a pilot and a scale-up?"

  6. Roadmap-adjacent news.

    "What did last week's pricing change mean for our stage? What's the implication of the EU AI Act for a Pilot-stage team?"

  7. Where to find things.

    "Which playbook covers this? Which tool applies at this stage? Where's the baseline data?"

We refuse — five categories

  1. Vendor predictions.

    "Which of these three vendors will win?" We don't know, and neither does anyone claiming to. We can tell you how to evaluate a vendor, not who wins.

  2. Business advice about your company.

    "Should we fund this?" That decision requires context we don't have. We can give you the framework; the call is yours.

  3. Medical, legal, or investment advice.

    We're not credentialed for that. Ask your doctor, lawyer, or CFP. Any answer we gave would be malpractice with better typography.

  4. Rankings we haven't published.

    "Who's the leading AI platform right now?" If it's not in research, we don't have an opinion we can quote — and a made-up ranking is worse than a refusal.

  5. Facts we can't source.

    "What's the average cost per token this week?" If we can't cite a page that states it, we don't state it. This is the rule that makes the other four refusals credible.

Honest architecture

How retrieval will work

Four steps, in order. This is what a query will actually go through when the backend ships — no "AI magic" language, because there isn't any.

  1. Retrieve from the hub first.

    Every query is first routed to a semantic index built from the hub's own pages — roadmap stages, playbooks, use cases, research, news, glossary. The model never answers from general knowledge. If the index turns up nothing relevant, we don't invoke the model.

  2. Synthesize with citations enforced.

    The model composes the answer from retrieved passages only. Every sentence in the answer must trace to a retrieved passage; if the model tries to add a claim without a source, the sentence is dropped. Confidence is computed from the number and quality of the cited passages, not from the model's self-assessment.

  3. Refuse when out of scope.

    Before the model runs, the query is screened against the five refusal categories. If it matches, the answer is a refusal — not a "I'm sorry, but" — enforced at retrieval time, not generated by the model and caught after. Refusals are logged and reviewed weekly.

  4. Correct what was wrong.

    Every answer is dated and versioned. If a source changes, or a feedback loop flags an answer as wrong, the answer is corrected — with the original preserved in the corrections log. An answer that quotes a corrected page is itself corrected.

The editorial standards behind this →

In public

Corrections on answers

A wrong answer is a correction, not an embarrassment. Dated, linked, rationale stated. The original is preserved, and the corrections log is public.

  1. Correction Demo answer 4 — "How do we budget AI for 2027?" — the original draft cited a specific percentage for the seat-to-volume shift that we could not source. Removed. The answer now states the shift as a direction with a cited article, not a number.
  2. Addition Demo answer 3 — "How far can we safely take autonomy?" — added the exact three preconditions for moving up a tier (kill switch, audit trail, evaluation ceiling). The prior version stated "full guardrails" without naming them.
  3. Correction Demo answer 5 — "Do we need an AI center of excellence?" — corrected confidence from High to Medium. The principle is documented; the judgment about when it hurts is editorial. Rating was overclaimed.

Full corrections log →

Editorial queue

Questions we couldn't answer this week

Unanswered questions become new content, or they become permanent refusals. Nothing gets silently dropped. This is the editorial pipeline, made visible.

  • "How do we set HITL thresholds for a workflow we haven't mapped yet?" In queue
  • "What's the actual completion rate of pilots that started without a baseline?" In queue
  • "Which of the three leading vendors has the best audit trail?" Refused
  • "Do we need a change management strategy before our first pilot?" Covered — see the adoption playbook →
  • "How long does the EU AI Act classification decision actually take?" In queue
On the product

Frequently asked questions

What makes these answers different from a chatbot?

Every answer cites a published source from the hub — a roadmap stage, a playbook, a research report, a news item. If we can't cite it, we don't state it. Answers also rate their confidence and name what they don't cover, so you can judge how far to trust one. A chatbot optimizes for engagement; this optimizes for whether the answer holds up in front of your CFO.

What won't you answer?

Five categories. Vendor predictions, business advice specific to your company, medical/legal/investment advice, rankings we haven't published, and facts we can't source. Each refusal has a reason, and the reason is usually "this is beyond what the hub can honestly claim." Naming the refusals is what makes the answers auditable.

Are the five demo answers live model output?

No. The five answers above are pre-computed by the hub's editors, drawn directly from published content, and served from the HTML. They demonstrate the format that the retrieval-backend will produce when it ships — sources cited, confidence rated, limits named. We ship the shape before we ship the system, so you can judge the shape.

What happens to questions you can't answer?

They enter an editorial queue. Each week we publish the questions we couldn't answer — either because the topic isn't covered yet, or because it's a refusal category. Unanswered questions become new content (a playbook, a glossary entry, a research report) or they become permanent refusals. The queue is a product input, not a support ticket.

How do you handle a wrong answer?

Same policy as news and research. Every correction is dated, linked, and rationale-stated. Wrong answers appear on the corrections log with the original claim preserved. Answer correctness is checked against the cited source — if the source is right and the answer paraphrase is wrong, the answer is corrected; if the source itself is wrong, both are corrected.

Do you log my questions?

Questions are logged in aggregate to drive editorial decisions — what the hub should cover next. The log stores the question, its answer status, and a timestamp. No email, no identity, no IP retention beyond 30 days for abuse prevention. See the privacy policy for the full data flow.

Search and jump to

↑↓ to move Enter to search