Service Expectations, Support & Revisions
Support channel
Primary support contact: support@urdatlas.com.
Reply target: within 2–4 business days. Faster responses may happen, but this is the public expectation baseline.
Production-impacting incidents or access problems should be reported with chain, date, endpoint used, and a copy of the returned error if available.
What counts as an incident
- Published rows missing beyond expected chain cadence.
- File delivery returning incorrect entitlement decisions or malformed JSON.
- Named regime rows or scorecard outputs that are provably inconsistent with the published methodology.
- Customer-facing freshness, provenance, or revision information that materially misstates the state of the archive.
Incident and revision handling
Status updates for persistent delays or operational issues should be posted on /status.
Corrections that affect archived artifacts should be accompanied by a correction note or changelog entry explaining whether the change was docs-only, interpretation-only, a methodology change, or a historical correction.
Freshness issues, upstream data issues, methodology changes, and historical corrections are distinct classes of event and should be communicated as such.
Urd Atlas depends on AWS upstream publication timing. If AWS publishes later than usual, that delay is outside the direct control of Urd Atlas. The pipeline still checks for newly available data automatically twice daily to catch late-arriving upstream files as soon as they appear.
Buyer fit and cadence expectations
BTC and ETH are intended for near-daily regime conditioning and monitoring workflows when AWS upstream publication remains on its normal cadence.
ARB and BASE are published on a slower cadence by design and are better suited to state-aware monitoring, historical segmentation, and notebook research than to intraday execution workflows.
Urd Atlas is not an intraday execution feed. It is a descriptive regime and context product.