How Railor handles claims, sources and your data.

Where claims come from

Railor reads published provider material — documentation, help centres, pricing pages, status pages, official announcements and public APIs — and normalizes it into a capability graph. Sources are fetched politely: robots policies and site terms are respected, rate limits are honoured, authentication boundaries are never crossed, and protections such as CAPTCHAs are never bypassed.

What a claim carries

Every published capability points at an evidence record: source URL, source type, the time it was retrieved, the time it was last verified, an excerpt, and a confidence score. Confidence starts from the source type — an official API outranks a third-party blog — and decays with age, so a stale “supported” cannot outrank a fresh check.

What Railor will not do

• • Infer a capability that no source states, or present a model's guess as verified.
• • Invent pricing, limits or coverage. Unpublished means “not published”, not zero.
• • Silently pick a winner when two sources conflict — both are shown and reviewed.
• • Claim to replace a regulated provider's KYC/KYB obligations.
• • Publish adoption metrics it has not measured.

Your workspace

Corridors, monitors, readiness answers and API keys belong to your organization, not to an individual account. Authorization is enforced server-side on every route. API keys are stored as hashes; a live key is displayed once at creation and never again.