Coupa order transmission and supplier acknowledgement
Does a sent Coupa purchase order establish supplier acknowledgement or completed confirmation?
Coupa exposes separate transmission, acknowledgement and confirmation fields. A sent transmission is not the same field as supplier acknowledgement or completed confirmation.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Require the stage-specific record before treating an order as acknowledged, confirmed or fulfilled. Transport status does not establish goods receipt.
- 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
Coupa invoice creation and approval submission
Does creating a Coupa invoice through the API submit it for approval?
The documented create action makes a draft invoice. A separate submit action sends a draft for approval.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not count a created draft as submitted, approved or payable without evidence of those later stages.
- 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
Coupa invoice approval and bypass provenance
Does approved Coupa invoice status prove each configured approver reviewed it?
The invoice API documents actions that bypass all approvals or the current approval. Status alone therefore does not establish which reviewers acted.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Require reviewer and action evidence for a claim of independent approval; neither status nor API availability grants authority to bypass controls.
- 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
Coupa modified invoices and restarted approval chains
Can an earlier Coupa invoice approval chain be reused after restart_approvals?
The documented restart action clears the current chain and generates a new chain for a modified invoice.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not apply an earlier chain to the amended invoice without reconciling its replacement and current decisions.
- 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
Coupa payment export and accounting acknowledgement
Does marking a Coupa Pay payment exported prove the supplier was paid?
The Payments API uses exported as an integration marker and separately exposes payment status. Its PUT operation is limited to marking export.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Treat export as an accounting handoff marker. Do not infer settlement, exactly-once ERP posting or supplier receipt from that flag.
- 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
Coupa external payment and tracking handoff
Does pay_externally in Coupa independently verify an external payment?
The action marks an invoice payable paid and stops Coupa tracking. Separate actions stop or restart tracking without representing payment verification.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Require independent payment evidence before relying on a mark-paid action. A tracking handoff is not a bank confirmation or continuing monitoring guarantee.
- 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
Coupa payment details and invoice allocation
Can a Coupa payment header total be assigned to one invoice without inspecting payment-details?
The API documents payment-detail rows with invoice identifiers, invoice references, payment amounts and currencies.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Reconcile the detail population before allocating a total. These fields do not establish complete allocation, matching tolerances or final settlement.
- 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 Issuing budget aggregation and overshoot
Is an Issuing spending limit a strict instantaneous maximum for an agent budget?
Stripe documents best-effort spend aggregation with a possible delay, and later tips or fees that can exceed a limit.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not claim a hard real-time cap from these controls. Reconcile delayed and adjusted amounts against the separate spending mandate.
- 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 Issuing category limits and permitted merchants
Does an Issuing spending limit for one merchant category block every other category?
A category-scoped limit applies only to its categories. Category restrictions use the separate allowed or blocked category controls.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not treat a scoped amount rule as an exclusive merchant allowlist. Compare both rule types with the purchasing mandate.
- 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 Issuing replacement cards and shared limits
Does replacing an Issuing card reset its spending-limit history?
The documented card limits extend across the replacement chain, while cardholder limits apply across that cardholder's cards.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not budget a replacement as an independent fresh allowance without reconciling the documented shared scope.
- 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 Issuing capture after card restrictions change
Does deactivating an Issuing card block capture of an already approved authorization?
The captured documentation excludes capture from current card-status, spending-control and real-time authorization checks.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not infer cancellation of earlier authorized exposure from a later card restriction. Obtain capture and recovery evidence separately.
- 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 Issuing refund linkage and invoice attribution
Does an Issuing refund authorization link reliably identify the original purchase?
Stripe describes refund linkage as inexact: the authorization can be unrelated or absent.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Require corroboration before assigning a refund to an invoice. A missing link is not proof no refund occurred.
- 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 Issuing refund reversals and amount direction
Does every Issuing transaction with type refund add a credit?
A refund reversal retains type refund but has a negative amount, unlike a standard positive refund.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Preserve amount direction when reconciling credits. Type alone must not cause a reversal to be counted as another 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 Issuing force capture and missing authorization
Does absence of an approved Issuing authorization prove no capture can occur?
Stripe documents captures following a decline or without an authorization; a transaction can therefore lack an authorization link.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not infer either spending authority or absence of debit from the authorization population alone. Investigate unmatched captures.
- 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 Issuing fallback decisions and callback health
Does approved=true prove the agent authorization callback successfully decided the purchase?
On a missing or invalid response, configured fallback can decide the authorization. Stripe directs users to request-history error reasons when assessing callback health.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not attribute a fallback decision to the agent policy. Confirm feature availability: Autopilot behavior is documented as public preview.
- 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 Issuing pending amount and decision-time evidence
Should an Issuing decision use the initial top-level amount instead of pending_request.amount?
The request stores the requested amount in pending_request while initial top-level amount is zero. The top-level fields change after the response.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not approve a supposedly zero-cost request from the initial top-level amount, or reconstruct the original request solely from later state.
- 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 Issuing partial and multiple capture accounting
Can one Issuing authorization be reconciled using only one capture transaction?
Merchants can partially or repeatedly capture an authorization. The held amount depends on the authorization and all linked captures.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Reconcile all captures before declaring the purchase complete or the remaining hold zero. Repeated capture records are not inherently duplicate execution.
- 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 Issuing declines before the agent callback
Does no Issuing authorization-request callback mean no purchase was attempted?
Spending controls run before the synchronous callback and can decline a request before it is sent, producing a declined authorization-created event.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not infer no attempted purchase from the callback stream alone. Review pre-callback outcomes and collection completeness.
- 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 trigger-token user authority
Whose project permissions does a GitLab pipeline trigger token use?
GitLab documents that a pipeline trigger token impersonates the creating user’s project access and permissions. Possessing the token is not independent evidence that the intended delegated action has owner approval.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Require the creator, current target access and intended delegation to agree. Do not infer narrowly scoped authority from the token’s pipeline-trigger label.
- 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 downstream pipeline initiating-user permission
Does a successful upstream GitLab pipeline prove that its user may start a downstream project pipeline?
For multi-project pipelines, GitLab requires the user creating the upstream pipeline to be able to start pipelines in the downstream project. A trigger job can fail when that user lacks the required permission.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Check the initiating user and target-ref access before relying on downstream creation. Upstream success alone does not establish cross-project authority.
- 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 trigger success and downstream completion
Does a passed GitLab trigger job prove its downstream pipeline completed successfully?
By default, a trigger job passes when the downstream pipeline is created. GitLab provides a trigger strategy to reflect downstream status; default trigger success alone does not report the downstream execution outcome.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Require the linked downstream result or an applicable status-propagating strategy before declaring downstream work complete.
- 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 multi-project cancellation boundary
Does starting a replacement upstream GitLab pipeline automatically stop its earlier multi-project downstream work?
GitLab documents that multi-project downstream pipelines are not automatically cancelled when a new upstream pipeline starts, even when interruptible is configured. Cancellation in the downstream project has its own context.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Verify the downstream state independently before assuming superseded upstream work cannot still execute. A replacement upstream pipeline is not evidence of downstream cancellation or rollback.
- 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 forwarded-variable masking boundary
Does forwarding a masked GitLab variable to another project preserve its masking configuration?
GitLab warns against forwarding masked variables to multi-project pipelines because the masking configuration is not passed downstream. The value could be revealed in downstream job logs.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not treat upstream masking as a downstream secrecy guarantee. Require an approved downstream secret mechanism and avoid exposing secret values in 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
GitLab forwarded-variable precedence
Can a GitLab downstream project’s variable value override a forwarded upstream value of the same name?
GitLab documents that upstream variables take precedence over same-name downstream variables. Forwarded variables become trigger variables with high precedence, so local downstream configuration alone may not identify the effective value.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Reconcile precedence and permitted overrides before treating downstream configuration as the effective policy. Do not include secret values in public records.
- 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 merge-request artifact ref identity
Does fetching downstream artifacts by branch name identify the upstream merge-request pipeline’s artifacts?
GitLab instructs merge-request artifact consumers to use the merge-request ref path through CI_MERGE_REQUEST_REF_PATH. Using the branch name retrieves artifacts from the latest branch pipeline instead of the merge-request pipeline.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Require the intended merge-request ref and artifact identity. A matching branch name is not sufficient evidence that the artifact came from the reviewed merge-request pipeline.
- 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
GitHub reusable-workflow environment secret selection
Does passing a repository secret to a reusable workflow establish the secret value used by a job with an environment?
GitHub documents that a called workflow’s job-level environment secret takes precedence over a same-name repository or organization secret. The caller must still pass the secret by name or inheritance; an unpassed secret can resolve to an empty value unless required. A required flag checks that the caller passes the secret, not that its value is nonempty.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Check both secret admission and environment selection before relying on the credential source. Do not infer a live credential value or successful authentication from workflow syntax.
- 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
GitHub attestation reusable-workflow signer policy
When a GitHub attestation uses a reusable workflow, which workflow identity must a verifier constrain?
The GitHub CLI identifies the reusable workflow as the signer for attestations produced through reusable workflows. Verification policy can constrain the signer workflow or repository; the caller repository alone does not fully specify the permitted signer.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Require a deliberate expected signer policy. Do not treat a valid attestation associated with the caller as approval of every reusable workflow signer.
- 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
GitHub offline attestation repository-name binding
Can offline GitHub attestation verification detect that a repository name was later renamed or reused?
The GitHub CLI documents that offline bundle verification compares names recorded when the certificate was created. Without current GitHub API lookup it cannot detect later repository renaming or name reuse.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Refuse a current-owner identity claim based only on offline name matching. Keep historical signing identity distinct from present repository ownership.
- 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
GitHub attestation predicate trust boundary
Does a successfully verified GitHub artifact attestation establish that all provenance predicate claims are trustworthy?
The GitHub CLI warns that, apart from certificate information and verified timestamps, an attestation’s contents can be influenced by the workflow that produced it. A compromised producing context can falsify predicate data; verification must include trust in that context.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not infer predicate truth from signature validity alone. Require an appropriate trusted-builder policy and leave unsupported build claims unresolved.
- 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
GitHub private attestation transparency-log scope
Should a GitHub private-repository attestation be assumed to have the public Sigstore transparency-log evidence?
GitHub documents different Sigstore instances: public-repository attestations use the public instance, while private-repository attestations use GitHub’s instance without a transparency log. The private instance federates with GitHub Actions.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Identify the signing instance before requiring or claiming public log inclusion. A private attestation does not satisfy a public-transparency requirement merely because it is signed.
- 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
Sigstore bundle informational digest input
Can a verifier use the message digest inside a Sigstore bundle as proof of the artifact’s own digest?
The Sigstore bundle specification marks message_digest as informational. A verifier must obtain or compute the digest for the artifact being verified rather than trusting that field to identify the supplied artifact.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not substitute a self-reported bundle digest for a digest of the intended artifact. Refuse artifact identity where independently bound input is missing.
- 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
Sigstore bundle DSSE single-signature profile
Does a Sigstore bundle’s DSSE envelope establish a multi-signer quorum?
The documented Sigstore bundle profile restricts its DSSE envelope to a single signature and an in-toto Statement payload type. Generic DSSE support for multiple signatures does not make a Sigstore bundle a threshold-approval proof.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Apply the specific bundle profile rather than generic DSSE possibilities. Obtain separate threshold-policy evidence before claiming multi-party approval.
- 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
Cosign annotation verification subset semantics
Does verifying specified Cosign annotations reject an attestation or signature that contains additional annotations?
Cosign’s verification documentation says each requested annotation must match. Additional annotations are permitted, so matching selected key/value pairs establishes a required subset rather than exact equality with a complete allowed annotation set.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- If policy forbids additional keys, obtain a separate complete-set comparison. Do not describe successful requested-key checks as exact annotation-schema enforcement.
- 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
Sigstore Rekor timestamp trust and version
Can Rekor’s signed integrated time be treated as an immutable independently trusted signing timestamp?
Sigstore documents that Rekor v1 integratedTime uses Rekor’s internal clock and is not included in the append-only log node, despite being signed. Rekor v2 uses a separate timestamp authority. Timestamp trust must therefore be evaluated by version and evidence type.
Documentation reviewed 2026-10-29. Primary source.
Boundaries
- Do not treat a signed v1 integratedTime as an independently trusted immutable timestamp. Establish the applicable time source and validation policy; no timestamp proves business completion.
- 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