How we work.
This page describes the mechanisms defined in the source and their scope. Product, claim, evidence-level, lifecycle and expired-surface counts are computed from recorded data; live jobs require separate execution evidence.
Evidence levels
Every recorded claim is tagged with a level. Not a quality ranking — a scope label, so a reader can tell 'we read the code and counted' apart from 'our own copy says so'.
The product's own data says so; nobody independently re-checked it. The weakest level — and it is never dressed up as more.
The runtime code was read and counted; the claim rests on the code itself.
Run against a real environment and measured; the result is recorded with its date.
Confirmed by someone outside YULA.
Product state machine
4 states, each of which mechanically changes something. A state that changes nothing is a label — listing it here as a stage would be the theatre this page exists to avoid.
Sorts first on the product index; every screenshot must carry sourceBuild and capturedAt or the build fails.
Same evidence rules as live; sorts after it on the index.
Rendered in its own collapsed section, and its primary link may not point at a store URL — a product you cannot download must not look downloadable.
Drops out of the default product index; the record survives, the shelf space does not.
Public claim policy
Recorded claims, linked statistics, screenshots and case studies have automated checks. Free-form promotional copy is reviewed separately.
- A structural gap fails the build: a claim with no source, scope, owner or date cannot ship.
- Dates must be zero-padded — one missing zero (2026-9-18) would keep a claim from ever expiring until the year turned.
- Expiry does NOT fail the build, it changes the page: a lapsed claim is not false, it is unverified — never deleted, shown as awaiting re-verification.
- A stat card may not print a figure the claim it links to does not contain.
- An unreleased product may not show a fabricated screen; every screenshot carries the build it came from and the date it was taken.
- A prose scan looks for 12 statements that turned out false in the past, by name, and stops them coming back.
- The case-study gate: no permission, baseline, artifact, measured outcome, failure lesson and validity date — no case.
Privacy and security
The contact form, funnel measurement and email delivery have separate controls. The privacy page describes the data categories and their purposes.
- When new contact submissions are disabled, the form endpoint returns 503. Delivery of previously accepted notifications depends on separate mail configuration and execution of the queue worker; closing intake does not cancel pending mail.
- Consent is not a checkbox but its own record, stamped with a dated notice version — knowing someone agreed cannot answer what they agreed to.
- Funnel measurement refuses free text: field values are constrained and query strings are removed from page paths. Raw records have a 30-day retention period and a job that removes expired records; completed deletion in production is confirmed through execution records.
- Data requests include email-address verification. Verifying the address does not mean that an access, correction or deletion request has been fulfilled.
- The site is configured with a CSP that restricts content sources and headers that prevent other sites from framing it. General pages and the email-verification page use different CSP rules.
The AI/human boundary
This site is largely written by AI sessions. The boundary is not left vague — it is bound to a risk class.
- Founder gate: store submission, pricing, real money, account ownership, legal questions and irreversible decisions belong to a human only.
- Security, payment, migration and privacy work requires an independent review before acceptance; nobody approves their own work. That review does reject in practice — the record contains rounds that were turned down more than once.
- 'Done' is not a percentage: work ends only when it reaches ACCEPTED, and it cannot get there without an evidence row.
- Steps needing a person, a device or a calendar are recorded as EXTERNAL GATES, with the required action and completion evidence stated explicitly.
Current limitations
This section is the price of the page. One that describes how we stay honest while omitting where we currently are not would be the exact failure it claims to prevent.
- The prose scan runs on every build, but its cross-repository targets exist only locally and in CI — the deploy that serves this page runs a narrower version of it.
- A case study does not supply its own number: it names which of a registry claim's verified figures it reports, and the numeral you see is read from the registry. The same rule covers the title, the metric label and the 'what changed after' section, because those read as claims. Baseline, constraint, decision summaries, artifact labels, the permission scope and the failure lesson stay free prose — a number is ordinary there. The known edge: an identifier-shaped string such as 'Accuracy-95' is accepted as a label.
- Product detail pages use verification dates for store and availability surfaces; expired availability assertions show a re-verification notice. Verification windows have closed for 4 recorded surfaces. This check does not cover every piece of promotional copy.
- Link reachability is not blocking in CI: a dead store URL raises a warning, it does not fail the pipeline.
- CI includes lint, type checking, tests, a build and dependency checks. Results are assessed against the relevant change and run record; local checks do not establish a production release.
- The default deployment configuration schedules the mail job once a day. This is not a delivery-time commitment; sending depends on mail configuration, the provider and successful job execution.
Related: product transparency · case studies