Functional, Visual, and Accessibility Evidence in One Run

Functional, Visual, and Accessibility Evidence in One Run means each evidence type describes the same execution timeline without being reduced to one blended score. A functional assertion can pass while accessibility fails. A screenshot can change while the outcome remains correct. A visual match can hide a broken control. The release Decision must preserve those distinctions.

One timeline, separate evidence records

Every evidence item should identify:

• Journey and immutable Journey Version;
• Run and attempt;
• declared context cell;
• step and Observation;
• evidence kind and status;
• capture time, source references, and content hash;
• applicable component, rule, protocol, target, or baseline identity.

That shared identity makes cross-evidence reasoning possible. The records remain independently queryable and reviewable.

Functional evidence answers outcome questions

Functional evidence shows whether an observable checkpoint matched the intended consequence. It can include assertion results, completed actions, API consequences, domain state, network outcome, or a supported external side effect.

Strong functional evidence is specific. “The click succeeded” is weak. “The invitation exists for the declared recipient, has pending status, belongs to the intended workspace, and is visible to the owner” is closer to the business outcome.

When it fails, inspect state and target evidence before labeling the product defective. The wrong authenticated actor or a stale selector can produce the same failed assertion for different reasons.

Visual evidence answers presentation questions

Visual evidence binds the source Observation, baseline Observation, comparison-context hash, viewport, mask policy, image hashes, and difference views. It helps reviewers understand geometry, content, styling, clipping, responsive containment, and intended presentation change.

It cannot independently establish that the Journey outcome occurred or that the interface is accessible. An approval must say what the reviewer accepted and why.

Accessibility evidence answers participation questions

Automated accessibility evidence records engine and rule versions, targets, occurrences, component ownership, and affected criteria. Manual evidence records protocol, evaluator, result, and notes for behaviors automation cannot settle.

The evidence can create or update barriers, remediation records, verification events, exceptions, conformance assertions, and scoped statements. It should never become a detached percentage that loses the affected Journey and context.

State and target evidence explain ambiguity

State evidence compares the actual actor, role, permissions, plan, data, locale, theme, viewport, clock, flags, and dependencies with the State Capsule. Target evidence records whether an intended interaction target resolved uniquely and safely.

These evidence types prevent common false conclusions:

• a role mismatch is not fixed by increasing retries;
• an unintended locale is not harmless pixel noise;
• a missing target is not necessarily a product regression;
• a volatile clock is not an intended visual redesign;
• a privacy leak is not acceptable because functional assertions passed.

Classify the Run without flattening it

A Run can report an overall consequence such as passed, failed, blocked, unsupported, or incomplete while preserving each evidence result. The classification should explain which evidence caused the consequence.

Evidence combination	Likely consequence
Functional pass, visual exact, accessibility pass	Eligible for ordinary Review, subject to policy and coverage
Functional pass, visual changed, accessibility pass	Visual intent Review required
Functional pass, visual exact, accessibility failed	Accessibility barrier blocks or requires authorized scoped exception
Functional failed, state mismatch	Repair or correct State Capsule before judging product
Functional failed, target missing	Repair target contract and rerun affected cell
Any privacy/policy failure	Quarantine affected evidence and block publication
Infrastructure exception with otherwise valid setup	Retry under policy while retaining the first attempt

No row implies automatic release approval. Coverage, authority, expiry, and downstream impact still matter.

Review subjects and Decisions

Route evidence into explicit subjects such as functional failure, visual change, accessibility barrier, state repair, target repair, intended product change, accepted risk, privacy violation, downstream output impact, and release readiness.

An attributable Decision records the actor and authority, subject, exact evidence, outcome, rationale, scope, effective time, and supersession. Different subjects may require different owners. A design approval cannot silently resolve a privacy violation; an automated scan cannot grant its own exception.

Downstream lineage

When the product change is approved, identify dependent Renditions and Publications. A help article might need a new screenshot. A support procedure might require different recovery instructions. Training captions might need updated terms. A marketing visual may be stale even when the product Run passed.

Lineage makes the impact visible. It does not auto-publish private Run artifacts or bypass content Review. Public output must be intentionally derived, sanitized, approved, and delivered through the supported channel.

Example: invitation Journey

Consider an owner inviting a member in a mobile, dark, fr-FR context.

• Functional evidence confirms the intended recipient is pending in the correct workspace.
• Visual evidence shows the localized dialog reflowed but remained contained at 390×844.
• Automated accessibility evidence reports the dialog has a name and no rule failures in scope.
• Manual evidence confirms focus enters the dialog, proceeds in a meaningful order, and returns to the trigger.
• State evidence confirms the actor is an owner, the locale is fr-FR, and the correct feature flags are active.
• The reviewer approves the visual change and accessibility evidence for this Journey Version.
• A linked help-center screenshot becomes refresh-due because the approved Observation changed.

The example remains understandable because every record shares the Journey, version, context, checkpoint, and Run.

Implementation sequence

1. Define the outcome and immutable Journey Version.
2. Declare a State Capsule and representative contexts.
3. Bind working native execution.
4. Select meaningful checkpoints.
5. collect functional, visual, accessibility, state, target, and policy evidence as applicable.
6. Preserve initial failures and retries.
7. Route exact subjects into Review.
8. Record attributable Decisions.
9. calculate outcome, context, Decision, and lineage coverage separately.
10. publish only sanitized approved consequences.

Continue with Accessibility Testing Across User Journeys, Full-Journey Visual QA, or the internal three-context Journey study.