A rider needs a usable answer about a service, including how current the underlying information is. A practical integration can connect a published service record, its latest observation and the evidence used to describe availability.
Executed synthetic walkthrough: this article includes actual light-mode OriginChainDB screenshots, the downloaded query CSV and a validated local application adapter. External industry systems were not connected.
Conceptual illustration of the synthetic application workflow. Light PNG · Dark PNG. This is not a product screenshot.
The sourced development
MobilityData published its summit takeaways on 2 October after the 22–23 September event in Montréal. The report emphasizes outcomes for riders, visibility of services in data and the work required to keep information useful. This is the source context for the application proposal below; none of the organizations in the report is presented as an OriginChainDB customer.
Read the primary source. MobilityData published the report on 2 October 2026 following the summit held on 22–23 September 2026.
The operational question
A service can appear in a catalog while its latest status is stale or missing. A binary available flag hides that distinction. The operational question for this prototype is narrower than journey planning: which catalog entries have a recent observation that an application can safely describe as current?
A tested OriginChainDB application pattern
Keep service ID, catalog revision, observation time and observation state. Define the freshness window as an application policy and preserve the source reference behind each observation. The fixture uses fictional services S1, S2 and S3, with no locations, operators or passenger data.
-
Create a fresh demonstration schema with a service catalog and a separate observation table. The recorded fixture uses catalog revision R1 for services S1, S2 and S3, and one observation per observed service. A production feed adapter must preserve source IDs and select the intended observation deterministically.
-
Inspect the stored catalog, then run the packaged LEFT JOIN report. The query keeps S3 even though no observation exists. At report minute 100 and a ten-minute window, observations before minute 90 are stale.
-
Use the console’s Export CSV action on the successful report. Run route-export.py on that actual file. The adapter checks columns, duplicate IDs and the freshness rule, then preserves the observation state with each returned row.
-
Display current, stale or no observation alongside the timestamp and the source state. A current observation still needs its actual state; freshness alone must not become an available flag.
Run the local application rule
The following executable fixture uses synthetic records and no network connection. It verifies the stated application rule without substituting a local result for a live database demonstration.
Download example.py · Expected local output
python example.py
now=100; window=10
observations={"S1":95,"S2":70}
result=[]
for id in ["S1","S2","S3"]:
seen=observations.get(id)
state="no_observation" if seen is None else "current" if now-seen<=window else "stale"
result.append({"id":id,"observed_minute":seen,"freshness":state})
assert [r["freshness"] for r in result] == ["current","stale","no_observation"]The recorded OriginChainDB report and its actual CSV export contain three rows: S1 is current at minute 95, S2 is stale at minute 70, and S3 has no observation. The local CSV adapter independently checked those classifications against the report-time policy. These are synthetic application outcomes, not live transit status.
The recorded integration walkthrough
The three stills below were extracted from actual native console recordings after private fields were blurred before encoding. They show the synthetic stored inputs, the successful operation and its returned result. Query timing visible in the console is one observation and is not a performance benchmark.
The stored service catalog preserves S1, S2 and S3. Open the image to inspect the full-size console view.
The recorded operation preserves missing observations and classifies a fixed report time. Open the image to inspect the full-size console view.
The actual three-row result matches the downloaded CSV and validated adapter output. Open the image to inspect the full-size console view.
Reproduce the SQL-to-application handoff
Setup and report SQL · Actual downloaded CSV · CSV adapter · Executed adapter result · Verification receipt.
Use a new demonstration namespace for a repeat run; do not reset an existing one. Run the setup statements separately, inspect the input rows, then run the report below. Export the complete successful result and pass that file to the adapter.
SELECT s.service_id AS service_id, s.catalog_revision AS catalog_revision, o.observed_minute AS observed_minute, o.observation_state AS observation_state, CASE WHEN o.service_id IS NULL THEN 'no_observation' WHEN o.observed_minute < 90 THEN 'stale' ELSE 'current' END AS freshness FROM academy_news_20261013_mobility.services s LEFT JOIN academy_news_20261013_mobility.observations o ON s.service_id = o.service_id ORDER BY service_id;python route-export.py export.csvThe adapter reads a local CSV, checks the application rule and emits records. It makes no network call and sends no external action. The synthetic contract CSV supplied beside the adapter is a separate offline test; it is not the live export.
Limits and evaluation
This model does not calculate routes, guarantee accessibility, predict arrival times or validate a standards feed. A production team needs a proper source adapter, timezone handling, clock policy and rules for withdrawn updates. Evaluate the workflow against historical feed gaps before presenting it to riders.
The practical next step
The useful starting point is a truthful freshness contract. This walkthrough verifies the synthetic catalog-to-report-to-CSV handoff in OriginChainDB. The next extension is a properly licensed source adapter, deterministic latest-observation selection and tests for withdrawn updates, future timestamps and real feed gaps.
Claims and remaining evidence · Local execution receipt · OriginChainDB documentation. No partnership, native industry adapter, certification, customer outcome or production deployment is claimed.
