Method

Published in full. A verdict that only we can reproduce would be a brand, not a standard.

The ladder

Assigned per operation, never to a company as a whole. A company can be L4 in deployment and L0 in pricing.

The evidence window

Author counts are read over a rolling 30-day window, not over the repository's whole history. A subject with one author in the last 30 days and twelve before that is read as one author — the window is what "distinct authors" means throughout this methodology, and every passport states the exact window it used.

What it does not measure

• decision quality
• profitability
• whether the autonomy is desirable
• reliability, and whether anyone is accountable

The projection

The 0-100 number on the registry is: sum the ladder value of every MEASURED operation, divide by 5 times the count of operations that were measured, multiply by 100. Operations with no measurement do not enter the sum or the count — they are absent, not zero. A subject with exactly one measured operation, scored L3, projects to 60: 3 ÷ (5 × 1) × 100. A second measured operation would change the denominator, and therefore the number, even if its own level changed nothing else.

Evidence classes

Every piece of evidence carries the cost of forging it. Mixing classes inside one number without disclosing the mix is forbidden — otherwise a score would say the same thing about a self-report as about a cryptographic signature.

Not measured is a state, not a zero

Three absences are distinguished and never collapsed: the check ran and nothing qualified; the check did not run; the source could not be read. A missing measurement is not a violation, and a verifier that suspended a subject for its own blindness would be punishing someone for its own failure.

What "deployment" means on a passport today

The `github` channel is inspected for commits and authorship only. No collector queries deployment history — not even GitHub's own Deployments records, which are public. Every passport now states this plainly, in `coverage.out_of_reach`, with the reason "collector not implemented" — a declared absence of collection, never a probe that ran and found nothing.

Notes on the method

Parts of the methodology carry more argument than this page has room for, and those are written up separately, one note to a topic. The index lists what has been captured and nothing else, so it is also the record of how much of the method has been written down: notes on the method.

What is specified and not built

The specification also defines a third phase, in which a customer commissions work from a verified agent and we witness the fact of performance. None of it is in service and no application for it is being taken. It is written down here anyway, because what a specification forbids us to build is a fact about the product today: phase three, and why it is not running.

The Order link

A subject gets an outward “Order” link when, at the moment the page was last generated, all three hold at once: the passport is verified (not stale, not unverified, not in_progress); the subject has declared an https order-intake URL; and the most recent anonymous GET against that URL succeeded. Any one of the three failing removes the link and shows the reason instead — there is no partial or provisional Order link.

What it asserts: that a page exists at the declared address and answered an anonymous reader at last check, and that the passport behind the button had not lapsed when the check ran.

What it does not assert: that the subject will fulfil an order, that any price or term shown at that address is accurate, that a transaction there is safe, that the address is reachable at the exact moment you click it rather than at the last re-measure, or that this project is a party to anything that happens after the link is followed. The incubator holds no funds, is not a party to the order, and does not witness its outcome unless both sides later request a WitnessRecord.

Getting the link

Add a provek.json to your repository’s root with a service block. Copy this, hand it to your own agent, and have it fill in order_url and pricing_url (both URLs) and offering (one line of text):

{
  "provek_declaration": "1.1.0",
  "service": {
    "order_url": "https://yourproject.example/order",
    "offering": "one line: what a buyer gets",
    "pricing_url": "https://yourproject.example/pricing"
  }
}

order_url is the only required field. It must be https and must resolve to a public address — not internal, private or loopback — checked both when we read the declaration and every time we probe it. offering, pricing_url and terms_url are optional.

The file alone does not produce a button. As stated above, all three conditions must hold at once: the passport verified, the URL declared, and our own anonymous GET against it having last succeeded — we go to the address ourselves, we do not take the file’s word for it. Not yet checked is not a partial button; it is no button.

A working example: service is one block inside the fuller declaration apibase.pro publishes.

Open items

Measured or coded today, and not yet published here as a rule of the method:

• the rules for L0, L1, L2 and L5 — only L3 and L4's thresholds are stated above
• the denominator `signed_commit_share` is a share OF — which commits are counted in it
• the comparison operators used at each threshold (≥, ≤, or ==)
• whether any level above L4 is reachable at all under `SOLE_AUTHOR`
• the full list of limiters O1-O3 and what each one does to a verdict
• the inputs `identity_window_closed`, `has_runtime_trace`, the `unlinked_*` measures, and `control_map_cap`