How to export structured data from the platform

The platform stores data at multiple layers — raw ledger tiles, entity records in the DataGraph, wiki content, and location intelligence datasets. Exporting that data means choosing the right layer for your use case and the appropriate export format. This guide covers the four main export paths and when to use each.

For the layered data model, see service-content. For the underlying ledger storage, see service-fs-architecture.

[edit]Prerequisites

A paired device with appropriate tier access (INPUT for ledger; USER for read-only exports)
An active Totebox session (see open-first-totebox-session)
Knowledge of which data layer you are targeting

[edit]Export path 1: Entity data from the DataGraph

Use this when you need structured records about people, organisations, projects, or services.

Call query_datagraph to identify the entity, then call get_entity_context to retrieve the full entity profile. The returned JSON object is the authoritative entity record. Copy or pipe it to your destination system.

For bulk exports, the service-fs API provides a read_since operation that returns entity-linked records from the ledger in chronological order.

[edit]Export path 2: Wiki articles as Markdown

Use this when you need article content for downstream publication, processing, or indexing.

Wiki articles are plain Markdown files with YAML frontmatter, stored in the media-knowledge-* git repositories. Export them by reading the files directly, or by using the knowledge instance's export endpoint if it is configured:

GET /export/<category>/<slug>
Accept: text/markdown

The response is the raw Markdown file including frontmatter. No authentication is required for content marked audience: vendor-public.

[edit]Export path 3: Location intelligence datasets as GeoJSON

Use this when you need cluster or archetype spatial data for GIS applications.

The GIS gateway serves pre-built GeoJSON files at:

GET /data/archetype-<name>.geojson

Where <name> is one of: vwh (Vertical Warehouse), pks (Parking Structures), or the main cluster file. These files include tier classifications, co-location signal fields, and enrichment attributes.

For the data schema and field definitions, see pointsav-gis-engine.

[edit]Export path 4: Ledger tiles for audit

Use this when you need tamper-evident records for compliance, legal discovery, or third-party audit.

Use the service-fs verify CLI or the read_since API to export C2SP tlog-tiles:

service-fs export --from <checkpoint-id> --format tlog-tiles --out <output-file>

The resulting file is plain text, verifiable with a SHA-256 utility, and readable without any PointSav tooling. See verify-worm-ledger for the verification procedure.

[edit]Choosing the right path

What you need	Use export path
Information about a named entity (person, project, service)	1 — DataGraph
Article content for publishing or indexing	2 — Wiki Markdown
Spatial cluster data for a map application	3 — GeoJSON
Tamper-evident records for compliance or audit	4 — Ledger tiles

[edit]Key takeaways

The DataGraph is the right path for named entity data — it holds verified, current records
Wiki Markdown exports include frontmatter; strip it or process it before sending to downstream consumers that expect plain prose
GeoJSON files are pre-built and served statically; they update when the nightly rebuild runs
Ledger tile exports are self-verifying with a SHA-256 utility; no live service is needed after export

[edit]See also

service-content — the Gravity Engine and the five-layer data model
service-fs-architecture — the WORM ledger that stores the raw record layer
verify-worm-ledger — how to verify the integrity of an exported ledger tile
pointsav-gis-engine — the GIS engine and its data schema
query-the-datagraph — how to look up entity data before exporting