Original research
Research designed to be reproduced, challenged, and cited.
Source-disciplined frameworks for measuring AI adoption, operating systems, CRM migration, and workflow automation. Observed evidence stays separate from modelled scenarios, and numeric findings are published only when their source, population, period, and calculation can be reproduced.
Reproducible
Every published figure states its population and period
Separated
Observed measurements never blended with projections
Gaps stated
Absent evidence reported as absent, not estimated
Introduction
What these reports are, and what they deliberately are not.
Each report here is a measurement framework rather than a set of industry statistics. It states what to measure, over which population, across what period, and by what calculation — so that a team can run it against their own systems and get a number they can defend.
That is a deliberate choice, and it costs us the most quotable kind of content. A report that opens with "73% of businesses report AI success" travels further than one that explains why that figure is unreproducible. We publish the framework and hold the number until the evidence supports it.
The practical use is internal: run the framework against your own runtime, and you get a baseline that is comparable to your own later readings. That is more useful for a decision than a cross-industry average computed over a population you are not in.
- Format
- Measurement frameworks
- Evidence standard
- Reproducible or unpublished
- Cost
- Free, no signup
- Best paired with
- Interactive tools
Why this exists
Most AI research cannot be reproduced by the people reading it.
The dominant format in this category is a percentage with no denominator. It is memorable, it is citable, and it cannot be checked — the population, the period, and the calculation are usually absent, which means a reader cannot tell whether it applies to them.
The second problem is blending. Observed measurements and modelled projections get presented with identical styling, and within one hop of the source the distinction is gone. A projection quoted as a measurement is worse than no figure at all, because it carries unearned confidence.
The third is selection after the fact. A population chosen once results are visible produces a number that cannot be defended under questioning, however carefully the arithmetic was done.
You're likely here because
- You need a defensible baseline rather than a citable statistic
- A vendor figure does not state its population or period
- Two internal teams compute the same metric differently
How to choose
Which framework to start with.
These are ordered by the question you are trying to answer, not by publication date.
If
You are deciding whether to start with AI at all
If
You are evaluating whether your tools work as one system
If
A CRM migration is on the table
If
Automations exist and nobody can prove they helped
If
You need to brief a board on the market
How it works
How to apply any of these without manufacturing numbers.
Every framework here follows the same measurement discipline. The order matters: a baseline captured after the change is an estimate, and should be labelled as one.
Step 01
Define the outcome
State the business result and the start and end state before any activity is counted. A measurement without a defined completion point cannot be reproduced by anyone else.
Step 02
Capture the baseline
Record current performance before changing the process. This is the step that cannot be done retrospectively without guessing, and the one most often skipped.
Step 03
Instrument the runtime
Collect first-party execution, workflow, and connector evidence, keeping observed measurements separate from estimates at the point of capture.
Step 04
Qualify before publishing
Hold any numeric finding until its source, population, period, and calculation are reproducible. Publish the qualitative conclusion in the meantime.
Step 05
Re-measure on a cadence
Repeat on a fixed interval against the same definitions, so the result is a trend rather than a single favourable reading.
Research frameworks
Published frameworks — 5 in total.
Research report
2026 SMB AI Adoption Report
A first-party research framework for measuring how small and midsize businesses move from AI experimentation to repeatable operating outcomes.
Read methodology →
Research report
2026 AI Operating System Report
A research framework for evaluating context, tools, workflow state, controls, and measurable outcomes as one operating system.
Read methodology →
Research report
2026 CRM Migration Benchmark
A reproducible benchmark framework for CRM migrations based on data mapping, workflow dependencies, integrations, validation, and rollback readiness.
Read methodology →
Research report
2026 Workflow Automation Report
A measurement framework for workflow automation focused on completion, cycle time, exceptions, intervention, and recovery.
Read methodology →
Research report
2026 Business AI State of the Market
A source-disciplined framework for tracking the market shift from isolated AI tools toward connected, governed business execution.
Read methodology →
Scope
What this research does not do.
- It does not publish cross-industry benchmark percentages as observed fact.
- It does not survey a panel; the frameworks are designed for first-party runtime evidence.
- It does not replace sector-specific regulatory or compliance guidance.
- A framework applied to poor-quality source data produces a reproducible number that is still wrong.
FAQ
Questions about this collection.
Why are there so few numbers in the reports?
Because we publish a figure only when its source, population, period, and calculation are reproducible. Where that standard is not met, the framework says so rather than filling the gap with a plausible estimate.
Can I cite these?
Yes. Cite the framework and the definitions. If you run it against your own data, the resulting figure is yours and should be attributed to your population and period rather than to UbiGrowth.
How is this different from the benchmarks section?
Research frameworks define how to measure something. Benchmarks define what a comparable reading looks like and how to produce one. In practice most teams use a research framework first and a benchmark framework when they want to compare across periods.
Do I need to be a customer?
No. The frameworks are free and are designed to be run against whatever systems you already have, including none of ours.
How often are these updated?
When the underlying measurement approach changes, rather than on a publication calendar. A framework reissued without a methodological reason would just be a new date on the same document.
What if the framework says something I cannot measure?
That is a useful result. An unmeasurable step usually points at a missing instrumentation or an undefined completion condition, and both are worth fixing before the metric is worth reading.
Start with ARIA
Ask ARIA about research.
You do not have to pick your way through this collection to get started. Describe the outcome you want and ARIA determines which capabilities, systems, and workflows the job needs.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Run the framework against your own systems.
A framework is only worth what a real measurement makes of it. Start with ARIA to define the outcome and the evidence it should be judged against, then measure your own runtime rather than an assumed baseline.