Skip to main content
AgenticTruthApply for an audit

Methodology

This is how we score a review, what counts as evidence, how the engagement runs, and what we need from you to do the work properly.

Scoring dimensions

Every review is scored out of 10 on each of six weighted dimensions. Weights are fixed across engagements so scores are comparable over time.

Positioning clarity

15%
  • Can a first-time visitor tell what the product does in one screen?
  • Does the value proposition match the actual feature set?
  • Is the competitive context addressed or ignored?

Core flow completion

25%
  • Can a new user complete signup, first value, and the primary action without help?
  • Where does the flow break, stall, or silently fail?
  • Are error and empty states handled, or do they dead-end?

Interface consistency

15%
  • Do type, color, and spacing follow a system, or drift screen to screen?
  • Do interactive elements behave consistently across the app?
  • Is responsive behavior broken on any common breakpoint?

Trust and credibility signals

15%
  • Are there broken links, placeholder text, or dead integrations a user would notice?
  • Does the product look maintained, or abandoned?
  • Are claims on the page backed by anything a user can verify?

Performance and accessibility

15%
  • Load time and responsiveness on a throttled mobile connection
  • Keyboard navigation and screen-reader landmarks on core flows
  • Color contrast and touch target sizing

Operational readiness

15%
  • Is there any error tracking or analytics in place at all?
  • Would the team know if the core flow broke in production?
  • Is there a technical-risk review flag when repository access is arranged separately?

Evidence classes

Every finding in a report carries one of these four labels so you know exactly how confident we are.

VERIFIED

We reproduced the issue ourselves, on the record, with a screenshot or recording attached.

OBSERVED

We saw the behavior during the review but did not isolate a root cause.

INFERRED

The evidence points strongly to a conclusion we could not directly reproduce (e.g. a backend limit inferred from client behavior).

NEEDS ACCESS

We flagged a likely issue that requires authenticated or repository access to confirm.

Workflow

  1. 01

    Scope confirmation

    We confirm package, flows in scope, access needed, and timeline before any review starts.

  2. 02

    Access handoff

    You provide access through a separate secure channel — never through the application form.

  3. 03

    Structured review

    We walk every in-scope flow on desktop and mobile, recording evidence and scoring each dimension.

  4. 04

    Report and prioritization

    Findings are written up with evidence class, effort band, and a fix now / next / later ranking.

  5. 05

    Findings call

    We walk through the report live and answer questions about tradeoffs and sequencing.

What we need from you

  • Confirm which flows and packages are in scope before the review starts.
  • Provide access through a separate secure channel — the application form never collects credentials.
  • Make a technical contact available if repository review is part of the engagement.
  • Review the report and flag anything that looks factually wrong before acting on it.

We never ask for passwords, access tokens, repository credentials, or payment data in the application form. Access is arranged after qualification through a separate secure channel.