Stripe feature changes and existing subscriptions
Does attaching a Stripe feature to a product immediately entitle existing subscribers?
Stripe documents that product feature changes create active entitlements for existing subscriptions at the next billing-period start. A changed product definition therefore does not establish that every existing customer already has the feature. Compare the subscription period, feature mapping and current customer entitlement inventory before provisioning.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Do not infer immediate access for existing subscribers from a product-feature attachment alone.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Stripe entitlement recovery after webhook loss
Can a provisioning service recover a Stripe customer feature inventory without replaying every missed webhook?
Stripe documents listing current active entitlements by customer for startup and reconciliation after webhook delivery failure. The response is paginated and uses feature lookup keys. This supports reconstructing the current declared feature inventory; it does not prove that the application applied it or that earlier access was correct.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Refuse historical-access or successful-provisioning claims from a current entitlement list alone.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Stripe meter acceptance and later validation
Does accepting a Stripe meter event prove that its usage was successfully aggregated for billing?
Stripe processes meter events asynchronously. Aggregated summaries and upcoming invoices can lag received events, and processing errors can produce meter error-report or no-meter events. Retain event identity and reconcile processing outcomes before treating an accepted request as a complete billable usage record.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Neither immediate absence from a summary nor request acceptance proves final aggregation or invoice inclusion.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Stripe late usage and invoice finalization
Will an accepted late Stripe meter event necessarily update a finalized invoice or appear on the next one?
Stripe distinguishes meter-event acceptance from invoice inclusion. Its timestamp window can permit an event after the related invoice finalized, while the event appears in summaries without updating that invoice or entering the next one. Threshold invoices have an earlier receipt cutoff. Match event receipt, service period and invoice lifecycle.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Do not claim a finalized or future invoice includes usage solely because Stripe accepted its timestamp.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Stripe billing-credit applicability
Does a Stripe billing-credit balance pay every type of subscription charge?
Stripe billing credits apply to eligible subscription items linked to meter prices. They are applied after discounts and before taxes and invoice credit balance. Legacy usage-record prices and non-metered charges are outside the documented supported scope. Match credit applicability and eligible invoice lines rather than treating a balance as universal payment coverage.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- An available credit grant does not establish coverage of every line, tax or outstanding balance.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Stripe credit notes and billing-credit restoration
Does issuing a Stripe credit note restore billing-credit grants previously consumed by an invoice?
Stripe documents different outcomes for voiding an invoice and issuing a credit note. Voiding reinstates applied grant balance, but already expired credits expire again immediately. A credit note does not refund the applied grant; restoring those billing credits requires a new grant. Reconcile the actual grant ledger and correction type.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Do not equate an invoice correction or credit note with restored spendable billing credits or a cash refund.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Stripe shared credit grants and invoice order
Can invoice creation order predict which Stripe subscription consumes a shared billing-credit grant first?
Stripe applies a grant eligible for multiple invoices to the invoice that finalizes first. Subscription invoices finalize independently, so their finalization order is not guaranteed. Within one invoice, eligible lines consume credit in their listed order. Reconcile actual allocation rather than assuming creation order or equal sharing.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Refuse predicted per-subscription credit allocation without finalized invoice and credit application evidence.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Auth0 rotation overlap and concurrent retries
Does an Auth0 rotation overlap window permit replay of any earlier refresh token?
Auth0 describes an optional rotation overlap period to tolerate concurrent exchanges. During that leeway, reuse detection does not apply to the immediately previous token; exchanging the second-to-last token triggers detection. The configured window and exact token generation matter when deciding whether a retry is tolerated.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- No safe-replay claim for arbitrary old tokens or assurance that the buyer configured the documented overlap.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Auth0 token revocation and grant scope
Does unlinking one Auth0 device revoke every refresh token for the user and application?
Auth0 distinguishes refresh-token revocation from deleting its authorization grant. The tenant revocation setting controls whether related tokens are invalidated with the grant; with the setting disabled, unlinking a device revokes its associated refresh token while leaving the grant intact. Verify the endpoint, setting and grant identity before claiming broader offboarding.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Do not infer all-device revocation or immediate expiry of existing access tokens from one device unlink.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
GitLab fine-grained job-token exceptions
Does a GitLab job-token fine-grained allowlist restrict every API endpoint the token can use?
GitLab lists endpoints without fine-grained permissions and states that permissions on an allowlist entry do not restrict those endpoints. A fine-grained rule list is therefore not a complete description of token authority. Review the documented exceptions together with the triggering identity, project access and applicable GitLab version.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- This does not establish unauthenticated access or bypass of every other project and user authorization check.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
GitLab group allowlists and later project membership
Can a GitLab group allowlist authorize a newly added nested project without editing the allowlist?
GitLab documents group allowlist matching across projects in the group and all nested subgroups. The match is evaluated whenever a job uses the token, so projects added later are included without an allowlist change. Permission reviews must include group membership over time as well as effective user and operation permissions.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Group membership is not proof that the triggering user has the target permissions or that a specific call succeeded.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
GitLab job-token pushes and missing validation pipelines
Does a successful GitLab job-token push prove that the target revision started a validation pipeline?
GitLab documents that pushes authenticated with a CI/CD job token do not trigger CI/CD pipelines. Enabling job-token push permission and recording a successful push therefore establish neither a pipeline start nor validation of the resulting revision. Retain independent pipeline evidence if validation is a release condition.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- A successful push is not evidence of a tested revision, and documentation does not prove the buyer enabled push access.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude Priority Tier cost-report scope
Does the Claude Cost API report all Priority Tier charges alongside token usage?
Claude documents Priority Tier usage in the usage endpoint through the service_tier dimension, but excludes Priority Tier costs from the cost endpoint because the billing model differs. A cost response alone is not a complete charge inventory when Priority Tier is used. Reconcile the applicable billing evidence separately.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Missing Priority Tier costs in this endpoint do not mean zero charges or a confirmed invoice discrepancy.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude code execution and token-report completeness
Can the Claude Messages usage endpoint alone account for code-execution charges?
Claude documents code-execution costs in the cost endpoint under a Code Execution Usage description, while code execution is not included in the usage endpoint. A Messages usage export cannot by itself establish complete tool charges. Reconcile the cost report and invoice scope with token usage for the same organization and period.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- No exact invoice or total-task-cost conclusion from token usage alone; applicable charges and adjustments remain buyer evidence.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude null API-key and workspace attribution
Should a Claude usage reconciliation discard rows with null API-key or workspace identifiers?
Claude documents that Console playground usage has a null API-key identifier even when grouped by that dimension, and the default workspace has a null workspace identifier. Such rows can represent documented usage populations. Preserve them with their documented meanings rather than dropping them as missing or assigning them to a guessed customer.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Null identifiers do not identify an independent user, customer or a verified responsible team.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude session budgets and final spend
Is a Claude Managed Agents max_list_cost budget an exact upper bound on final session cost?
Claude documents that the model request crossing a session budget completes, potentially exceeding the cap by one model request per thread. Its returned tool calls still run and their search and runtime costs count. The budget bounds starting new work rather than guaranteeing an exact final charge; retain the usage snapshot and stop reason.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- No exact charge ceiling, invoice amount or verified stop behavior is established by a configured budget alone.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Claude thread totals and session runtime cost
Should summed Claude Managed Agents thread costs equal the session list cost exactly?
Claude documents independently rounded thread figures that exclude the session running-time cost. Session active_seconds counts overlapping thread activity once, and the session figure governs its budget. Differences between summed thread costs and session cost therefore require scope and rounding reconciliation rather than an automatic double-billing conclusion.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Documented aggregation differences neither prove nor disprove an actual invoice error.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OpenAI Agents usage and provisional accounting
Does null or unchanged OpenAI Agents session usage prove that no cost was incurred?
OpenAI describes Agents API session and turn usage as best-effort: it can be null when unknown and recorded values may change as accounting arrives. These counts are not a final bill. Treat missing usage as unestablished, retain observation times and reconcile later accounting before concluding zero consumption or final cost.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- No zero-cost, finalized-invoice or complete usage conclusion from an absent or provisional usage field.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OpenAI Agents token subsets and double counting
Should reasoning and cached tokens be added to OpenAI Agents input and output totals?
OpenAI documents cached tokens as a subset of input_tokens and reasoning tokens as a subset of output_tokens in Agents usage. Adding those detailed categories again to the parent counts double-counts recorded tokens. Preserve the subsets for applicable pricing analysis while keeping the totals and component categories distinct.
Documentation reviewed 2026-10-28. Primary source.
Boundaries
- Token arithmetic alone does not establish the final charge, complete task cost or applicable model rates.
- Buyer implementation, live runtime enforcement, settled payment, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review