# Orca > Orca is a read-only knowledge corpus of payment rail reason codes (returns, rejects, return requests) for people and AI agents. Every record states what a code means, what to do about it, its return windows, its basis and confidence, and a trust tier that says whether anyone has checked it. This snapshot holds 777 records across 50 rails: 28 draft, 749 corroborated, 0 verified, 0 superseded, plus 360 rail facts. Snapshot 2026-09-20, built 2026-09-26. ## What Orca is and is not - Orca describes payment rules. It is not legal advice, it does not move money, and a reply from it does not authorize a payment, a reversal, or a compliance determination. - Orca is not a payment processor, a router, or a fraud tool. It informs the systems and agents that do that work. - Records cite rulebooks by section and edition. They do not reproduce rule text. Check the governing authority's current text before acting on anything that matters. ## Trust tiers - draft: written by an agent and not checked by anyone. Drafts are published, and every one is marked draft. Treat a draft as a lead, not a fact. - corroborated: a validator checked the record, including its return window, against one or more named public sources. Each source carries its URL, source class, date, and who checked. Where the governing authority does not publish the spec, the record is marked `currency.primary_not_public` and needs at least two independent sources on different hosts. - verified: a human checked the record against the governing authority's own current text. No record is verified yet. - superseded: the rule changed. The old record stays, and currency.superseded_by names the current one. ## Source classes (strongest first) - authoritative_primary: the governing body's own text (for example the Federal Reserve, EPC, BCB, ISO). - public_primary: a public operator or regulator publication that is not the rulebook itself. - secondary: bank guides, processor documentation, industry references. A corroboration against a secondary source is still a corroboration, but it is weaker, and it is not a verification. ## Rail facts A reason code answers "this came back; what does it mean". A rail fact answers "what can happen on this rail, what can I undo, and who decides", without knowing any code. Each rail fact is one record about one of twelve fixed questions: finality, settlement, hours, limits, return, recall, refund, liability, consumer-law, messages, participants, decision-points. It holds the question, a short statement, a list of detail lines (each with its own citation and whether it rests on a rule, a law, operator guidance, or observed practice), a required list of exceptions, and the same basis, confidence and currency block a reason code carries, so a fact is drafted, corroborated and superseded the same way. A rail with no record for a facet has a gap there; a rail where a path does not exist says so in a record, cited. ## Rails - [Apple Pay (pass-through wallet)](apple-pay/index.html): Apple, through the Apple Developer Program License Agreement and the Acceptable Use Guidelines for Apple Pay on the Web, for the wallet's own rules; the card network, the card issuer and the merchant's acquirer for the payment itself. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 2 draft, 10 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-20. - [New Payments Platform (Australia)](au-npp/index.html): NPP Australia Limited. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 1 draft, 11 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-20. - [NPP Payment Initiation Reason Codes (Australia)](au-npp-reject/index.html): NPP Australia Limited. 33 records: 0 draft, 33 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-20. - [Bancontact (Belgian debit card scheme and Bancontact Pro)](bancontact/index.html): Bancontact Company SA/NV (card scheme rules, not public; Bancontact Pro and Bancontact Pay terms, public). 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-19. - [BLIK](blik/index.html): Polski Standard Płatności S.A. (PSP). 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-19. - [Boleto (Brazil payment slip arrangement)](boleto/index.html): Banco Central do Brasil (BCB). 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-19. - [Canada ACSS (Automated Funds Transfer)](ca-acss/index.html): Payments Canada. 21 records: 8 draft, 13 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-18. - [Swiss Interbank Clearing (SIC)](ch-sic/index.html): SIX Interbank Clearing on behalf of the Swiss National Bank. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 1 draft, 11 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-18. - [SIC Instant Payments (SIC IP)](ch-sic-ip/index.html): SIX Interbank Clearing on behalf of the Swiss National Bank. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-18. - [SIC IP Payment Rejections](ch-sic-ip-reject/index.html): SIX Interbank Clearing on behalf of the Swiss National Bank. 17 records: 1 draft, 16 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-18. - [SIC IP Return Requests](ch-sic-ip-return-request/index.html): SIX Interbank Clearing on behalf of the Swiss National Bank. 6 records: 0 draft, 6 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-18. - [SIC IP Return Request Rejections](ch-sic-ip-return-request-rejection/index.html): SIX Interbank Clearing on behalf of the Swiss National Bank. 7 records: 0 draft, 7 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-18. - [Swiss Payment Standards Status Report Reasons](ch-sps-status/index.html): SIX Interbank Clearing (Swiss Payment Standards). 41 records: 0 draft, 41 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-18. - [Austria eps-Überweisung](eps/index.html): PSA Payment Services Austria GmbH. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-19. - [eps Payment Messages](eps-error/index.html): PSA Payment Services Austria GmbH. 14 records: 2 draft, 12 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-19. - [eps Refunds](eps-refund-error/index.html): PSA Payment Services Austria GmbH. 11 records: 0 draft, 11 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-19. - [eps Payment Confirmations](eps-status-reason/index.html): PSA Payment Services Austria GmbH. 11 records: 0 draft, 11 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-19. - [FedNow](fednow/index.html): Federal Reserve. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 1 draft, 11 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-17. - [GCC AFAQ (cross-currency payments)](gcc-afaq/index.html): SAMA (Saudi participant rules); GCC central banks via GPC (system). 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-18. - [GCC AFAQ Payment Rejections](gcc-afaq-reject/index.html): SAMA (rules for Saudi direct participants); GCC central banks via GPC (system). 27 records: 0 draft, 27 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-18. - [AFAQ Returns (SAMA rules for Saudi participants)](gcc-afaq-return/index.html): Saudi Central Bank (SAMA), for its direct participants; AFAQ is owned by the six GCC central banks and run by the Gulf Payments Company. 77 records: 0 draft, 77 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-18. - [Google Pay (pass-through wallet)](google-pay/index.html): Google LLC, through the Google Pay API Terms of Service and the Google Pay and Wallet APIs Acceptable Use Policy, for the wallet's own rules; the card network, the card issuer and the merchant's card acquiring bank for the payment itself. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 2 draft, 10 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-20. - [UPI (Unified Payments Interface)](in-upi/index.html): Reserve Bank of India. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 2 draft, 10 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-20. - [Mastercard](mastercard/index.html): Mastercard. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-19. - [Mastercard Decline Response Codes (partial)](mastercard-decline/index.html): Mastercard. 38 records: 0 draft, 38 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-19. - [SPEI (Mexico peso interbank electronic transfers)](mx-spei/index.html): Banco de México. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-20. - [Malaysia DuitNow](my-duitnow/index.html): Bank Negara Malaysia. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 1 draft, 11 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-18. - [Nordic Credit Transfer Instant (NCT Inst)](nct-inst/index.html): Nordic Payments Council. 46 records: 0 draft, 46 corroborated, 0 verified, 0 superseded. 12 rail facts: 10 draft, 2 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-18. - [PayPal (staged wallet)](paypal/index.html): PayPal (regional entities; US: PayPal, Inc.). 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-19. - [PayPal Dispute Reasons](paypal-dispute/index.html): PayPal (regional entities; US: PayPal, Inc.). 10 records: 1 draft, 9 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-19. - [Philippines InstaPay](ph-instapay/index.html): Bangko Sentral ng Pilipinas. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 2 draft, 10 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-18. - [Philippines PESONet](ph-pesonet/index.html): Bangko Sentral ng Pilipinas. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 1 draft, 11 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-18. - [Pix](pix/index.html): Banco Central do Brasil. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 2 draft, 10 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-17. - [Pix Payment Rejects](pix-reject/index.html): Banco Central do Brasil. 45 records: 0 draft, 45 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-17. - [Pix Returns (Devolucao)](pix-return/index.html): Banco Central do Brasil. 4 records: 0 draft, 4 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-17. - [RTP](rtp/index.html): The Clearing House. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 1 draft, 11 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-17. - [RTP Payment Rejects](rtp-reject/index.html): The Clearing House. 59 records: 0 draft, 59 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-19. - [RTP Return Request Reasons](rtp-return-request/index.html): The Clearing House. 7 records: 4 draft, 3 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-17. - [Saudi Arabia sarie (instant payments)](sa-sarie/index.html): Saudi Central Bank (SAMA). 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 3 draft, 9 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-18. - [SEPA Credit Transfer](sepa-sct/index.html): European Payments Council. 43 records: 0 draft, 43 corroborated, 0 verified, 0 superseded. 12 rail facts: 2 draft, 10 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-17. - [SEPA Instant Credit Transfer](sepa-sct-inst/index.html): European Payments Council. 41 records: 0 draft, 41 corroborated, 0 verified, 0 superseded. 12 rail facts: 1 draft, 11 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-17. - [SEPA Direct Debit B2B](sepa-sdd-b2b/index.html): European Payments Council. 24 records: 0 draft, 24 corroborated, 0 verified, 0 superseded. 12 rail facts: 1 draft, 11 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-17. - [SEPA Direct Debit Core](sepa-sdd-core/index.html): European Payments Council. 24 records: 1 draft, 23 corroborated, 0 verified, 0 superseded. 12 rail facts: 1 draft, 11 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-17. - [Faster Payments (UK)](uk-fps/index.html): Pay.UK Limited. 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 4 draft, 8 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-20. - [Faster Payments Rejection Codes](uk-fps-reject/index.html): Pay.UK Limited. 8 records: 0 draft, 8 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-20. - [Faster Payments Return Reasons](uk-fps-return/index.html): Pay.UK Limited. 8 records: 0 draft, 8 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-20. - [US ACH](us-ach/index.html): Nacha. 90 records: 11 draft, 79 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-16. - [Visa](visa/index.html): Visa (Visa Core Rules and Visa Product and Service Rules). 0 records: 0 draft, 0 corroborated, 0 verified, 0 superseded. 12 rail facts: 0 draft, 12 corroborated, 0 verified, 0 superseded. Snapshot 2026-09-19. - [Visa Authorization Declines](visa-decline/index.html): Visa (Visa Core Rules and Visa Product and Service Rules). 42 records: 0 draft, 42 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-19. - [Visa Disputes](visa-dispute/index.html): Visa. 23 records: 0 draft, 23 corroborated, 0 verified, 0 superseded. 0 rail facts. Snapshot 2026-09-19. ## Data - [corpus.json](corpus.json): every record on every rail in one JSON file. `rails` lists each rail's metadata (name, governing_authority, snapshot, known_gaps). `entries` holds the reason codes and `facts` holds the rail facts; each record names its own `kind`. A rail fact carries `facet`, `name` (the question), `statement`, `details` (label, value, citation, rests_on), `exceptions`, `applies_to`, plus the same `basis` and `currency` as a reason code. The fields an agent needs on a reason code: - `uid`: the entry's name across the whole corpus, `:`. `related` holds uids, so a link may point at an entry on another rail. - `rail`: the rail id, matching a directory above. `rail_name`, `governing_authority` and `snapshot` are copied onto every entry from that rail, so one entry read on its own says whose rule it states. - `id`: the code as the authority writes it (R01, AC01). An id with an @date suffix is an earlier meaning that stopped applying on that date. - `source_class`: the strongest class among the entry's own corroboration sources, and null while nothing has checked it. - `effective_status` and `effective_status_reason`: what the entry is worth today. An entry whose only sources are secondary and whose newest check is more than 24 months before the corpus snapshot reads as `draft` here, while `currency.status` still says what it was recorded as. Read effective_status before relying on a record. - `boundaries`: what this answer depends on and Orca does not hold, derived by the build from the record itself, never written by hand. Each is { kind, label, needs, detail, from }: `needs` is what you would have to know, `detail` is what the record says about it, and `from` is the field or the Rule uid it was read from. `kind` is scope (the record's own eligibility narrows it), eligibility (a condition on a Rule it rests on), window (an effective date that has not arrived or has passed at the snapshot), not_public (the governing text is not one Orca has read), judgement (its caveat names a call a bank, a fraud or sanctions check, or a lawyer makes) or jurisdiction (its caveat makes the answer country-specific). An empty list means the record has nothing to qualify; it is not a claim that no condition exists anywhere. 385 of 1137 records carry at least one. - `name` and `summary`: what the code means, in plain words. - `facts.return_windows`: a list of { action, by, deadline }: who may act and by when. - `basis`: { sources, confidence }. Confidence is high only when the claim follows directly from a cited authoritative source. - `currency.status`: draft, corroborated, verified, or superseded. Read this before relying on a record. - `currency.corroboration`: the list of sources a validator checked, each { source_url, source_class, source_title, checked_on, checked_by, notes }. Empty until someone checks the record. - `currency.primary_not_public`: true when the governing authority's own text is not the source: it does not publish the spec, or not under terms Orca can use. Such a record rests on at least two independent published sources on different hosts, never reaches high confidence, and cannot be verified without a licensed or human check. - Also useful: `currency.effective_since`, `currency.source_edition`, `currency.superseded_by`, `retry`, `related`. - [core.json](core.json): the same rules in Orca Core form, for apple-pay, au-npp, au-npp-reject, bancontact, blik, boleto, eps, eps-error, eps-refund-error, eps-status-reason, google-pay, in-upi, mx-spei, pix, rtp-reject, uk-fps, uk-fps-reject, uk-fps-return, us-ach. corpus.json above is projected from these records and says the same thing in its own shape. Every record has a `class` (Rail, Role, TransactionType, Exception, ReasonCode, Rule, RuleSource, Mandate; a rail fact keeps `kind: rail-fact` and lists its Rules in order) and typed `relations` ({ type, to, evidence, note }), so one Rule, such as a return window, is a single record that every code it governs points at. Each relation carries a computed `status`: verified when its record is verified, corroborated when one of its evidence sources is among the sources a validator checked on that record, draft otherwise; `effective_status` applies the same 24 month staleness as entries. `used_by` on each record lists the links that point at it. A corroboration names a RuleSource uid; the RuleSource record holds its URL, class and edition. - [products.json](products.json): 6 product views with a page on 5 rails (au-npp:txn.mandate-payment, blik:txn.recurring, in-upi:txn.recurring, pix:txn.pix-automatico, pix:txn.pix-cobranca, uk-fps:txn.standing-order-payment). A product is built on a rail (Pix Automatico, PayTo) and has an object of its own: an authorisation, a lifecycle or a code set. It is not a rail and has no directory; each view is derived by the build from records core.json already holds, and lists them: the TransactionType, the authorisation (a Mandate with its typed constraints and the Rules it is governed, cancelled and disputed through), the states, the code sets, the Rules grouped by facet with any typed time window, limit or fee, the facets it inherits from the rail (linked, never restated, and never asserted to apply unchanged) and the rail facts that list a rule specific to it. Nothing in a view is written by hand, and a view has no status of its own: every record in it carries its own effective_status and source_class. One product: `data/products//.json` under a `product` key; its page: `/.html`. `thin` lists the 0 products that hold too few records to render a page, with the reason; the floor is 5 Rules and is a page threshold, not part of the definition, which `definition` and `derivation` state in full. `candidates` lists transaction types with rules and no anchor of their own. - [conflicts.json](conflicts.json): the source-conflict register, 19 places where public sources disagree on a claim Orca makes (16 resolved, 2 unresolved, 1 superseded). Each conflict has an `id`, the `question`, the `records` it touches (uids) and `affects` (the same uids with rail, rail_name, kind, name and effective_status, so corpus.json is not needed to read it), at least two `sides` (a `position` in Orca's words and its `sources`), and a `status`: resolved and superseded carry a `resolution` ({ finding, sources, on }) resting on at least one text that is not secondary; unresolved carries `open`, what would settle it. A source is a RuleSource uid, described in `rule_sources` (name, url, source_class, edition), or a url with title and class; either way with the `section` read and `read_on` and `read_by`. Before relying on a record that a conflict affects, read the conflict; an unresolved one means public sources disagree and the governing authority's text has not settled it. - [data/rails.json](data/rails.json): the rails index, and the place to start if you do not want the whole dump. It lists every rail with its counts and the path to that rail's own file. One rail: `data/rails/.json`, the rail's metadata with all of its entries and facts. One record: `data/records//.json`, that record alone under a `record` key, unchanged from corpus.json. A uid is `:`, so us-ach:R10 is data/records/us-ach/R10.json; no lookup is needed to build the path. This snapshot publishes 1137 record files and 50 rail files. - [Data page](data.html): what is published, what each file is for, the licence, the snapshot, and how to fetch one record. - [Rail index](index.html): the human-readable pages. Every published JSON file, including corpus.json, core.json, conflicts.json and every file under data/, carries `format_version` (1), `built`, `snapshot`, `commit` (the build's git commit, or null where git could not say) and `license`, so a file read on its own says what it is, when it was true, and how it may be used. ## Licence and attribution Orca's data is published under the Creative Commons Attribution 4.0 International licence (CC-BY-4.0, https://creativecommons.org/licenses/by/4.0/). Copy it, change it, build on it, commercially or not. Credit Orca and name the snapshot date you used: every published JSON file carries a `license.attribution` string ready to quote. The full statement is [LICENSE-DATA.md](LICENSE-DATA.md). Reference material about published payment rules. Not legal, compliance or financial advice. Orca cites rulebooks by section and edition and does not reproduce them; rights in the cited documents stay with their authors. ## Agent access - A hosted agent endpoint (a remote MCP server) is not yet available. Fetch one record from data/records//.json, one rail from data/rails/.json, or everything from corpus.json. - [changes.json](changes.json): what changed. The last 20 commits that changed something in the corpus, newest first, 2026-09-21 to 2026-09-26. Each carries its commit, its date, its rails, a count per kind, and the items themselves: records `added`, `removed` and `superseded`, `meaning`, `action` and `deadline` changes, tiers `promoted` and `demoted`, `sources` added, re-read or dropped, records newly `stale`, `gap` lines, and `other` for a field the build does not recognise. Read `method` first: it says what counts as a change. The comparison is on parsed JSON at named field paths with whitespace collapsed and key order ignored, so a reformat produces nothing and is counted under `files_reformatted`; 0 commits here changed formatting only. It is derived from the repository's git history at each build and stored nowhere between builds. There is no "changed since a date" query; the full history is in the repository. Per-record dates sit in `currency.effective_since`, `currency.last_verified` and each corroboration's `checked_on`. - [data/upcoming.json](data/upcoming.json) and [data/upcoming.xml](data/upcoming.xml): the change calendar, what is coming and when. `dated`: 21 record(s) with a typed future date (`takes_effect`, `stops_applying` or `replaced_by`, with the successor named). `mentioned`: 60 date(s) named only in a record's own `effective_note`, not a typed field; the record's statement is still the one in force. `passed`: 0 date(s) that have arrived with nothing superseding the record yet, the watch's own debt. `expected`: a watch expectation, empty until a rail's meta.json holds one. Each entry carries its dates, sources and trust. The Atom feed holds one entry per `dated` and `mentioned` item, for a feed reader or a GRC platform to subscribe to. This is what Orca holds a date for, not a claim that every rail change is here. - Snapshot date: 2026-09-20. Rules change. Check each record's currency block and the rail snapshot before relying on it.