Usage and billing
GrayPass bills according to the meter and allowance in the production agreement. Each meter counts qualifying logical units. Use those units and their contractual window to reconcile an invoice.
Your agreement selects one meter for its shared usage pool. Usage follows contractual monthly windows, exact decimal rates, and deduplication of the same logical unit. Read commercial model for the annual platform fee and invoices for collection.
Assured Actions
An Assured Action is a persisted, qualifying production decision in a live environment. The meter covers enforce decisions when permitted for the environment. Qualifying live shadow decisions count under a production agreement unless an explicit free production-shadow term applies. See action modes for the distinction between observation and protected execution.
The final decision can be allow, challenge, hold, or deny. A decision resulting from insufficient evidence, identified by decision.insufficient_evidence, is an abstention and does not create a billable unit.
The unit follows the logical action. Idempotent retries, a challenge and its resulting child authorization, and proof retrieval or verification share that logical action's single unit.
A new logical operation with a different identity can be a separate unit. Preserve stable idempotency for one business intent and reject payload changes under the same identity in your application.
Active Brainprint months
An Active Brainprint month is one subject for which GrayPass produced a qualifying assurance profile during the contractual monthly window. The profile must have sufficient evidence. The first qualifying assurance records or references the durable evidence of that qualification; the same subject contributes at most one unit to the selected pool in that window.
The same subject can contribute one unit in the next window after producing a new qualifying assurance there. Creating a subject, completing enrollment, or submitting raw or accepted evidence frames does not alone create this unit. An insufficient-evidence assessment also does not count.
A session status or assessment read can produce and record qualifying assurance. Both GET /api/v1/sessions/{id}/status and GET /api/v1/sessions/{id}/assessment can therefore create Active Brainprint usage under the agreement's shadow-use terms. The status read preserves enrollment state and reports assurance; request action authorization separately. Repeated qualifying reads for the same subject in one contractual window share one subject/window unit. Use health endpoints for monitoring and request status or assessments for their intended integration purpose.
Inclusion and exclusion table
Usage eligibility follows the environment, effective action mode, and agreement. Use live shadow mode for the production evaluation workflow; sandbox enforcement exercises the complete proof flow. The table also defines enforce-meter semantics for environments permitted to use that mode.
| Activity | Assured Actions meter | Active Brainprint months meter |
|---|---|---|
| Subject creation or enrollment | No unit. | No unit from enrollment alone. |
| Browser evidence submission | No unit from the frame itself. | No unit from the frame itself. |
| Sandbox development activity and evaluation agreement activity | Excluded from production overages. | Excluded from production overages. |
| Qualifying live shadow decision | Counts unless covered by an explicit free production-shadow term. | A qualifying assurance can activate the subject unless excluded by that recorded shadow term. |
| Qualifying enforce decision, when permitted for the environment | Counts as one logical action. | A qualifying assurance can activate the subject for the window. |
| Insufficient-evidence result | Excluded. | Excluded. |
| Retry of an existing logical action | No duplicate unit. | No duplicate subject/window unit. |
| Challenge continuation and resulting proof | Part of the existing logical action. | No duplicate subject/window unit. |
Record a free production-shadow period explicitly in the agreement, including its ending boundary.
Live credentials produce live-environment traffic, including requests from a development machine. Select the intended environment and agreement scope before running tests against a service.
Contractual monthly windows
Windows are UTC, start-inclusive and end-exclusive. They are calculated from the original service-start anchor. For a January 31 start, the next boundary is the final day of February and the following boundary returns to March 31. The original anchor remains in effect after February's shorter month.
For example, an agreement beginning at 12:00 UTC on January 31 has a first window ending at 12:00 UTC on the final day of February. An eligible event one instant before the ending boundary belongs to the first window; an event exactly at the boundary belongs to the next. A timezone-offset date is normalized to the same UTC instant before assigning its window.
Agree a production service start on a whole UTC minute. That exact start determines the contractual usage boundaries. Signature timestamps retain their actual precision for conversion-credit checks.
Use Billing for the contractual usage ledger and Settings for calendar-month diagnostics. Their different boundaries can produce different totals. Replays retain their original logical event time, agreement binding, and usage identity.
Allowances and arithmetic
For a window, additional units are the eligible units above the included allowance, with a minimum of zero. The charge is additional units multiplied by the contracted decimal unit rate, rounded once at the invoice line to cents using half-up rounding. Rates support up to six decimal places. Event amounts retain precision until that invoice-line rounding step.
Use this symbolic check against an invoice:
additional_units = max(eligible_units - included_units, 0)
usage_line = round_half_up(additional_units × contracted_rate, 2 decimals)
Use the rate and allowance recorded for that agreement and window. Each window retains its applicable terms when a later change is approved. The included monthly allowance resets at the next window, with unused units expiring at the current window's end.
Estimates, close, and corrections
The Billing view shows current usage, the included allowance, the contractual window, and an estimated additional charge. Current estimates can change as eligible work is recorded and reconciled. Final invoicing uses the closed window and its agreed economics.
GrayPass reconciles the agreement, usage identities, window, and totals before releasing a usage invoice. A discrepancy can leave the invoice held for review. Replays retain the same logical usage unit. Corrections appear as adjustments so you can reconcile the original charge and its resolution.
If a total looks wrong, record the tenant, environment, agreement reference, UTC window, affected authorization or subject references, and your expected result. Contact founders@graypass.org. Send references and a minimal description first, rather than personal data or complete request payloads.