Workflows

Turn network state into a useful control variable.

Urd Atlas creates value after it is joined to something the user already cares about: app metrics, monitoring output, research tables, dashboard annotations or a shared feature store.

Core pattern

Join → gate → segment → explain.

The label is not the final product. The useful output is the change in interpretation after chain-wide network state is added to an existing workflow.

No-pipeline analyst

Start with CSV calendars, weekly summaries and the runnable notebook. Useful when the team needs a report, dashboard annotation or quick segmentation before building infrastructure.

Open Analyst Kit

Technical evaluator

Inspect public endpoints, test the join in pandas, review validation diagnostics, then decide whether subscriber artifacts are worth integrating.

Open API Docs

Production data team

Ingest daily network-state files into a warehouse, preserve methodology and availability metadata, and expose one shared feature table to analysts and systems.

Check validation

Practical workflows

What you do, what you get, and why it matters.

Each workflow starts from data the user already has. Urd Atlas adds daily network-state context and confidence metadata.

Integrate with API

Report annotation

Weekly summary text or Analyst Kit CSV.

User: Research analysts, protocol teams, newsletters and dashboard owners.
Start point: A weekly report explains usage, fees, capacity, support load or activity but lacks a consistent chain-context layer.
Use Urd Atlas: Use the weekly summary plus the regime calendar for the relevant chain.
Do this: Copy the latest summary into the report, then add a small table showing the last 30 or 90 days by network state.
Output: A repeatable paragraph and table that separate project-specific observations from chain-wide conditions.
Decision support: Helps the reader understand whether the week looked unusual in the context of the chain itself.

App metric segmentation

Regime calendar CSV or subscriber Meta file.

User: Protocol, wallet, infra or analytics teams with daily app metrics.
Start point: The team sees a change in users, transactions, support tickets, latency, failure rate or other operational metrics.
Use Urd Atlas: Join the app metric table to Urd Atlas on observation date and chain.
Do this: Gate rows by confidence, then compare the app metric across STABLE, HEATING, CONGESTED, CHEAP and UNKNOWN/DEGRADED periods.
Output: A metric-by-network-state table that can be pasted into a report or used as a dashboard control.
Decision support: Helps decide whether the next analysis should focus on app changes, chain conditions or data quality.

Model monitoring

Subscriber Meta and Derived files.

User: Teams running activity, demand, capacity, quality or anomaly models on blockchain-related operational data.
Start point: Model error rises and the team cannot tell whether this is input drift, code regression, data delay or a network-state shift.
Use Urd Atlas: Attach regime, confidence, demand, friction and capacity scores to every model-output row.
Do this: Compare error, bias, alert count and uncertainty by regime and confidence bucket.
Output: A monitoring view showing where model behavior changes under different network conditions.
Decision support: Helps set review thresholds, confidence gates, fallback behavior and retraining priorities.

Shared feature-store definition

Subscriber file delivery through /api/v1/files.

User: Teams using Snowflake, BigQuery, Databricks, dbt, Airflow, Dagster or a lightweight internal warehouse.
Start point: Each analyst defines high activity, stress or cheap network conditions differently.
Use Urd Atlas: Ingest the daily network-state schema with methodology version, determinism hash and freshness metadata.
Do this: Publish one internal blockchain_network_state_daily table joined by date and chain.
Output: A shared feature used consistently across notebooks, BI, model validation and reports.
Decision support: Reduces duplicated definitions and makes downstream analysis easier to reproduce.

Implementation pattern

The useful join should be boring.

1. Pick the chain and observation grain used by your existing data.
2. Join Urd Atlas on observation_date and chain.
3. Apply a confidence or freshness gate before summarizing.
4. Segment the metric that matters by regime or score band.
5. Write down what changed in the interpretation after the join.

import pandas as pd

metrics = pd.read_csv("my_daily_app_metrics.csv")
urd = pd.read_csv("https://urdatlas.com/api/v1/analyst-kit/ethereum/regime-calendar")

joined = metrics.merge(
    urd[[
        "observation_date",
        "chain",
        "regime",
        "confidence_score",
        "demand_score",
        "friction_score",
        "capacity_score",
    ]],
    left_on=["date", "chain"],
    right_on=["observation_date", "chain"],
    how="left",
)

usable = joined[joined["confidence_score"] >= 0.70]

summary = (
    usable.groupby("regime")
    .agg(
        days=("date", "count"),
        avg_daily_active_users=("daily_active_users", "mean"),
        avg_support_tickets=("support_tickets", "mean"),
        avg_failure_rate=("failure_rate", "mean"),
        avg_demand_score=("demand_score", "mean"),
    )
    .sort_values("days", ascending=False)
)

print(summary)

What Urd Atlas is good for

Research, reporting, monitoring and reproducibility.

The product is strongest when users need a consistent daily or weekly context layer that can be joined, audited and reused across teams. It is especially useful when the alternative is every analyst inventing a separate definition of chain conditions.

Product boundary

Not a real-time instruction layer.

BTC and ETH are published at T+1. Base and Arbitrum are weekly. That makes Urd Atlas suitable for descriptive analysis, daily or weekly monitoring, report context and point-in-time diagnostics. It should not be treated as an automated instruction or a future-state guarantee.

Next step

Start simple, then move deeper.

A new user should begin with Analyst Kit, validate the segmentation idea, then move to subscriber files or API integration when the workflow is proven.

Use without a pipeline Check validation Open API docs