Fit
The workload meets the agreed criteria inside the tested scope. The evidence supports an adoption or deployment-scope decision.
Clarté Workload Fit Pilot
One workload. Ten business days. A defensible decision.
In a fixed-scope engagement, determine whether one real analytical workload fits Clarté and produce the evidence required for an adoption, deployment-scope, or no-go decision.
The pilot is a paid, fixed-scope engagement. You buy the decision and the evidence behind it — not open-ended engineering hours, and not a migration.
ONE WORKLOAD · TEN BUSINESS DAYS · THREE HONEST OUTCOMES
Who it is for
For teams that can name the workload.
The pilot works when the ingredients already exist. Five signals tell us a pilot is worth proposing.
- 01A named workload and a named ownerOne analytical workload with one accountable person behind it — not a general platform ambition.
- 02A live triggerA contract renewal, a cost programme, a customer-controlled hosting requirement, or a new workload with a date attached.
- 03Kubernetes and object storage acceptedThe pilot runs in a customer-approved cluster, or in the documented reference environment.
- 04Able to start within weeksPrerequisites you can assemble now, and stakeholders who can attend a decision review.
- 05A fixed scope, honestly acceptedIncluding the possibility that the answer is not fit. The pilot produces a decision, not a guaranteed adoption.
Fixed scope
Eight numbers define the whole engagement.
Scope is agreed in writing before anything runs. These numbers are the entire engagement — nothing silently grows.
- 1
- representative dataset or approved workload slice
- 1
- useful analytical journey
- 3
- representative queries, at most
- 2
- identity roles with different access
- 1
- row, column, or dataset-access policy
- 1
- agreed environment
- 1
- measured concurrency level
- 10
- business days once prerequisites are ready
ANYTHING BEYOND THESE NUMBERS IS A NEW AGREEMENT, NOT SCOPE DRIFT
What you bring
The pilot starts when these are ready.
Seven prerequisites gate the start date. The ten business days count from the moment they are ready — not from the moment the agreement is signed.
- 01A named technical owner for the pilot.
- 02Dataset access, or an approved representative slice.
- 03Representative SQL, or a precisely described analytical question.
- 04Current workload measurements where available.
- 05Success criteria agreed before the run starts.
- 06An approved Kubernetes environment, or agreement to use the documented reference environment.
- 07Availability from identity and infrastructure owners if those integrations are in scope.
What you receive
An evidence pack, not a slide deck.
Every deliverable is written to be inspected — by your security owner, your infrastructure owner, and the person who signs the decision.
01 / Method
A reproducible environment and test method — every measurement states how it was taken.
02 / Workload
A description of the dataset and the query shapes that were exercised.
03 / Performance
Cold and warm query measurements for the agreed queries.
04 / Resources
Working-set, memory, and tested-concurrency observations where measurable.
05 / Governance
Allowed and denied access evidence — the policy proven from both sides.
06 / Audit
Query-to-audit correlation evidence for the governed session.
07 / Operations
Operational fit notes for the target environment.
08 / Recommendation
A written fit, conditional fit, or not-fit recommendation.
09 / Next decision
A proposed next decision — not an open-ended feature backlog.
Outcomes
Three honest outcomes.
The pilot succeeds when it produces a defensible decision. All three outcomes qualify.
Conditional fit
The workload is promising, but one named integration, operating constraint, or proof item needs resolution before the decision.
Not fit
A different architecture is more appropriate for this workload — and the evidence shows why, before a migration instead of after one.
A not-fit result is not a failed pilot — it is a defensible decision. The pilot is priced for the decision and the evidence, not for a preferred answer.
Not included
What the pilot deliberately excludes.
A fixed scope is only credible if the boundary is public. These sit outside it — by design, not by omission.
An enterprise-wide migration
The pilot tests one workload. It does not move an estate.
Unlimited datasets or user groups
One dataset, one journey, up to three queries, two roles.
Custom feature development
The pilot evaluates the platform as it ships.
Compliance certification
The pilot produces evidence you can inspect, not a certification or an audit outcome.
Guaranteed scale, latency, or cost outcomes
Numbers are measured inside the tested scope, never promised ahead of it.
Open-ended integration work
Integrations in scope are named before the start — identity and infrastructure owners included.
How it runs
Four checkpoints, one decision date.
The engagement moves through four checkpoints. The clock starts when the environment and data are ready.
- 01Scope agreedDataset, journey, queries, roles, policy, environment, success criteria, and the decision date — fixed in writing.
- 02Environment + data readyPrerequisites land: access, the approved slice, and the agreed Kubernetes environment. The ten days start here.
- 03Run + measureCold and warm runs, the tested concurrency level, and allowed and denied governance behaviour — all recorded.
- 04Decision reviewThe evidence pack and written recommendation are reviewed together: fit, conditional fit, or not fit.
SCOPE → READY → RUN + MEASURE → DECISION · TEN BUSINESS DAYS FROM READY TO DECISION
Next step
One workload in. One decision out.
Bring the workload, the owner, and the trigger. The pilot brings the platform, the method, and a named decision date.