Review & proof
A result is stronger when you can see why it passed.
Ysra separates implementation from review and binds evidence to the candidate that was actually checked. When it can’t prove something, it says so.
The same claim cannot approve itself.
Four rules
What makes the evidence mean something.
Acceptance criteria become the contract
What you asked for — and the acceptance criteria you gave — define what review checks. Not what the implementation happened to do.
Evidence is bound to one candidate
Checks, screenshots, and findings attach to the exact files that were checked. Stale evidence cannot approve different code.
Checks and reviewers have different jobs
Deterministic checks — tests, types, lint, build — report facts. Independent reviewers judge the outcome against the request. Product policy decides what passes; no vote ships software.
Partial work stays inspectable
An incomplete result is preserved, labelled, and deliverable as what it is — never rewritten into a success.
Honest failure
Not every red is a bug.
Failures are classified before anything happens next. Only real product findings send code back for repair. An unavailable browser or reviewer is never silently turned into a code defect — or into a pass.
- ProductThe candidate doesn’t do what was asked.Back to repair
- TestThe check itself is wrong or flaky.Fix or flag the check
- ReviewerA review step failed or disagreed with the evidence.Re-review, not rewrite
- InfrastructureA browser, runtime, or service wasn’t available.Marked unverified
- Missing evidenceThere is no proof either way.Marked unverified
Independent review
Specialist review, scaled to the risk.
Ysra’s Review Council assesses a candidate against the acceptance contract and the surfaces the change touches. Low-risk changes get a light path; changes to authentication, payments, persistence, migrations, external APIs, deployment, or background jobs get more depth.
Which specialists run depends on the change and the review profile. Not every specialist runs on every task, and review can be advisory or required by policy.
- Changed behaviour and blast radius
- Code correctness
- Repository architecture
- Native tests, lint, typecheck, and build
- Requirements acceptance
- API behaviour
- Browser workflows
- Security boundaries
- Visual and accessibility obligations
- Deployment or job reliability
- Evidence completeness and candidate identity
Browser evidence
The journey, replayed.
For runnable web products, browser verification keeps the scenario, the navigation steps, screenshots, the viewport, and the requests observed — with a clear pass, fail, or unverified.
- Draft Q4 plan
- Review onboarding copy
- Call the venue about Friday
↻ reloaded · 200 OK · item still present
The Build Report
When Ysra can’t prove a requirement, it says so and keeps the candidate.
Partial and unverified states are first-class results, not error screens. You decide whether to resume, deliver as unverified, or stop.
Build Report
Organization invites
- 01
Native checks
Uses the repository’s own test, type, lint, and build commands.
SHELL✓ passed - 02
Browser workflows
Exercises applicable user journeys in the running candidate.
BROWSER✓ 4 of 4 steps - 03
Independent review
Reviews the requested outcome separately from implementation.
REVIEW✓ no findings - 04
Exact candidate identity
Keeps evidence attached to the files that were actually checked.
IDENTITY✓ 7f3a2c1 - 05
Honest stops
Preserves partial work and says what remains unverified.
PARTIAL◐ 1 unverified
Illustrative Build Report. Labels match the product; the session is fictional.
Judge the work by its evidence.
Start a software task and read the Build Report — including the parts that didn’t pass.