Validation and evidence

Decision

Claims advance one level at a time. Delivered capability is not observed behavior. Observed behavior is not a measured business outcome. Private evidence is not public proof.

Use this page as the canonical source for evidence status. Service pages may summarize the conclusion, but they must link here and must not strengthen the wording.

Evidence ladder

Marker	Status	What it means	Allowed language	Minimum record
0	Hypothesis	A buyer value, workflow behavior, or outcome is plausible but not yet demonstrated	“We expect,” “designed to,” “can influence,” or “target”	Named claim, rationale, owner, and next test
1	Delivered capability	The control exists in a delivered implementation with a defined boundary	“FZF built” or “the implementation supports”	Scope, acceptance evidence, known limitations, and source
2	Observed workflow behavior	The capability behaved as stated in a live or representative run	“In this run…” followed by the exact observation	Dated run, population, exceptions, logs or records, and recovery details
3	Measured outcome	A stable definition and baseline show a result over an agreed period	“The measured result was…” with timeframe and attribution limits	Baseline, after-state, method, outside factors, and client acceptance
P	Public proof	Level 1, 2, or 3 evidence may be disclosed in approved wording	Only the approved claim, context, and underlying level	Written permission, approved name or anonymization, source link, and review date

Levels 0–3 describe evidence strength. P is a publication overlay, not a stronger causal level. A public capability example does not become a measured outcome merely because it is published.

Current claim register

Staffing Billing Control

Claim	Capability delivered	Behavior observed	Outcome measured	Public proof	Approved internal interpretation
One run coordinated 80 invoice records; 76 continued while four exceptions stopped	Yes	Yes	No	Yes	Supports exception isolation and controlled stopping in that run
Delivery resumed after an outbound-provider interruption without duplicate sends	Yes	Yes	No	Yes	Supports resumable, duplicate-safe recovery in that run
Staffing Billing Control reduces approved-time-to-delivery or held invoice value	Partly	Not established	No	No	Hypothesis. Establish a buyer-approved baseline and observation period
Staffing Billing Control improves cash, DSO, factoring acceptance, or billing headcount	Not established as an outcome	No	No	No	Unsupported. Do not state as achieved or guaranteed

The public source for the observed run is FZF’s staffing invoice automation field note. The four stopped records were three OCR identity mismatches and one known incorrect invoice. The run does not prove a dollar benefit, lower DSO, fewer rejections, faster payment, or headcount savings.

Staffing Workers’ Compensation Control

Claim	Capability delivered	Behavior observed	Outcome measured	Public proof	Approved internal interpretation
FZF built a control surface for claim state, assignments, recurring obligations, alerts, documents, communications, safety records, reporting, and audit history	Yes	Not established here	No	No	Supports implementation capability only; source is private
The implementation preserves human review for ambiguous intake, alert resolution, and consequential decisions	Yes	Not established here	No	No	Supports the designed authority boundary, not a broad production outcome
The service prevents avoidable claim cost, improves return-to-work timing, or increases claims handled per FTE	Not established as an outcome	No	No	No	Hypothesis. Pair direct process measures with contextual outcomes
FZF may name the client or publish a private delivery as a case study	—	—	—	No	Not permitted without explicit written approval

The private delivery includes explicit limits. It has no direct third-party-administrator integration. Other external-system connections and production-hardening work remain bounded by the delivered scope. It does not support claims of regulator certification, predictive outcomes, or autonomous compensability, medical, employment, litigation, reserving, or closure decisions.

Claim-writing rules

1. Write the smallest true claim. Preserve population, period, environment, and exceptions.
2. Keep capability, behavior, and outcome separate. “The system routes exceptions” does not prove “the client reduced labor.”
3. Pair direct and contextual measures. Use approved-time-to-delivery beside DSO, or overdue actions beside claim cost. Do not attribute the contextual result without a method.
4. Keep null and negative results. They change the scorecard and prevent repeated weak experiments.
5. Do not aggregate unlike runs. Different clients, rule sets, periods, or definitions need explicit normalization.
6. Do not borrow permission. Private delivery, repository access, or an internal client name does not authorize public identification.
7. Time-limit proof. Record the review date and recheck claims when workflow, implementation, or client context changes.

Validation experiment rules

Every experiment must have a short written contract before work starts:

Field	Rule
Claim	Test one precise buyer, behavior, or outcome claim
Population	Define accounts, records, workflow path, and exclusions
Baseline	Name the definition, source, owner, period, and known quality limits
Intervention	State what FZF changes and what remains outside its control
Primary measure	Choose one direct measure that can decide the test
Context measures	Track broader business results and outside factors without assuming attribution
Threshold	Set the promote, revise, or stop result before observing data
Duration	Use a period long enough to include normal exceptions and recovery cases
Evidence	Preserve logs, samples, acceptance records, and decision notes
Permission	Record whether use is private, anonymized, or public

Prefer paid behavior over compliments, observed workflow behavior over stated intent, and client-owned baselines over FZF estimates. In message tests, change one value angle at a time and judge qualified meetings and paid Sprints—not opens, clicks, or generic replies.

Service promotion gates

Evidence is one part of the portfolio decision. The score and promote/hold/retire rules remain canonical in Portfolio prioritization.

Candidate → validated service concept

• The primary buyer, high-consequence job, workflow boundary, and retained authority are explicit.
• Independent buyer evidence supports the consequence and a usable baseline.
• At least one core capability reaches Level 1: delivered capability through a prior delivery, prototype accepted against representative data, or paid Sprint output.
• Integration and recovery risks are known well enough to scope a fixed-price Build.
• Unsupported outcome language is recorded before sales messaging is approved.

Validated service concept → active sales motion

• Paid buying behavior supports demand; interviews alone are insufficient.
• At least one central workflow claim reaches Level 2: observed workflow behavior or the proposal clearly labels it as a delivery target.
• The buyer accepts a measurement contract for the first Build or Run period.
• Delivery capacity, security, authority, and commercial boundaries pass review.
• Positioning passes the 4 U’s check.

Outcome claim → public proof

• The claim reaches Level 3: measured outcome with stable definitions and attribution limits.
• The client approves the exact wording, identity or anonymization, metrics, period, and channels.
• FZF stores the supporting source and review date.
• Public copy states outside factors and avoids guarantees.

Next validation priorities

1. Billing: obtain a buyer-approved baseline for approved-time-to-delivery, held value, exception age, completeness, and manual touches; observe the same definitions after implementation.
2. Workers’ compensation: validate budget and urgency with independent risk leaders; select one bounded path such as injury intake, work-status follow-up, or packet completeness; measure direct behavior before making cost claims.
3. Proof permission: ask early, but separate permission from delivery acceptance and outcome measurement.
4. Candidates: spend learning effort in the order and against the unknowns listed in Portfolio prioritization.