Astvyr
VERIFICATION

The author of a change is never its only reviewer.

In most AI workflows the same model that wrote the change also declares it correct. Astvyr separates the two: an independent verifier rebuilds the change from the approved contract and tries to break it.

EIGHT LEVELS

Verification is a ladder, not a checkbox.

Each level answers a different question, and each one produces evidence with provenance and a timestamp.

01

Deterministic

Types, lint, build, schema and unit tests with provenance and hashes.

02

Behavioural

Integration, API contract, browser end-to-end and mobile journeys.

03

Security

Secrets, SAST, dependencies, IaC, containers and permission checks.

04

Data and migration

Backward compatibility, data survival and a rehearsal for high-risk changes.

05

Performance

Latency and resource regression with a confidence interval.

06

Reliability

Fault injection, retries, idempotency and recovery.

07

Cost

Model, compute and infrastructure delta against the Mission budget.

08

Production

Canary metrics, observation window and the outcome itself.

INDEPENDENT VERIFIER

A separate context window, and often a different model.

For higher risk classes the verifier may run on a different provider entirely, with adversarial and hidden checks the builder never sees.

Pass

Criteria are covered by independent evidence.

Fail

A criterion is provably broken.

Inconclusive

Evidence is missing or stale. It is never silently converted into a Pass.

Needs human judgment

The trade-off belongs to a person, and the residual risk is recorded.

RULES
  • Self-reported success is not evidence: a claim without a runner or tool signal is rejected.
  • Flaky tests are separated from real regressions, and a false pass is never hidden.
  • Post-release incidents are traced back to the checks that missed them.
  • The acceptance contract maps to objective proof: a test, a metric, an audited event or a formal manual scenario. “It seems to work” is not proof.
EVIDENCE BUNDLE

Fourteen manifest groups, nine artifact types, eight quality checks.

A sealed bundle is a manifest plus artifacts. A missing item is visible: no score hides a gap.

MANIFEST GROUPS

IdentityIntentActorsContextChangesExecutionChecksEvidenceFindingsRiskReleaseOutcomeEconomicsIntegrity

ARTIFACT TYPES

TestBuildSecurityPerformanceVisualOperationalApprovalProductionDecision

QUALITY CHECKS

  • AuthenticityThe source is who it claims to be.
  • IntegrityHashes and signatures match; mutation invalidates the bundle.
  • RelevanceThe artifact actually addresses the criterion.
  • FreshnessThe evidence is recent enough for the decision.
  • IndependenceHigh-risk claims need a verifier separate from the author.
  • CompletenessEvery criterion is covered or explicitly declared missing.
  • ReproducibilityThe run can be repeated from the recorded envelope.
  • PrivacyNo secret or unnecessary customer content is inside.

The bundle is sealed: hashes and a signature chain bind it to an immutable release candidate. Any mutation invalidates it, and every affected release is flagged for review.

EVIDENCE LIFECYCLE

From a planned criterion to an invalidated artifact.

Evidence is created on purpose, validated against policy, sealed to an immutable release candidate and then either retained or expired under tenant policy. Corruption, a compromised source or a wrong assumption invalidates it and sends every linked release to review.

PLANNED → COLLECTING → VALIDATING → ACCEPTED / REJECTED → SEALED → RETAINED / EXPIRED / LEGAL_HOLD → INVALIDATED

RELEASE CONFIDENCE

An explanation, not a guarantee.

Release confidence is an explainable risk assessment. It shows what contributed, and what evidence is missing. It never replaces a gate.

Mission success rate

Accepted outcomes divided by eligible Missions, tracked by cohort and task class.

False green rate

Declared safe or successful, but failed acceptance or caused an escape. The key trust KPI.

Human rework ratio

How much work a person has to redo, tracked without weakening outcomes.

Retrieval critical recall

Must stay above the threshold for high-risk tasks.

< 0.5%False green rateTarget on monitored production missions
> 70%Accepted mission rateWithout a full manual rewrite
100%Contract complianceRelease gate for executable output
0Policy bypass toleranceAny occurrence leads to a release stop
ADVERSARIAL

What the red team tries to break.

Eight attack classes are exercised continuously, not once a year.

Repository prompt injection

Tool confusion, including look-alike tools and unsafe defaults

Context poisoning, where false documentation becomes trusted knowledge

Data exfiltration through encoded output, covert channels or log leakage

Privilege escalation by requesting a broader identity

Evidence forgery, including synthetic logs and skipped checks

Denial and cost attacks: infinite loops, huge context, fork bombs, expensive routing

Cross-tenant retrieval, tested with canary secrets and isolation fuzzing

TRUST

A green check is not proof. Evidence is.

Independent runners, signed artifacts, freshness checks and a named owner for every criterion.