Export structured data from the platform
Prerequisites
- Access to the DataGraph MCP tools, for entity exports
- Read access to the relevant
media-knowledge-*git repository, for wiki exports - Network access to
service-fsand your module identifier, for ledger exports - A device paired to the workspace (see Pair a new device)
Purpose
Pick the right export path for what you're actually trying to get out of the platform — entity records, article content, or audit-grade ledger history each have a genuinely different real mechanism.
Procedure
Path 1: Entity data from the DataGraph
Use this for structured records about a person, organization, project, or service.
- Call
query_datagraphto identify the entity, thenget_entity_contexton its identifier to retrieve the full profile — see Query the DataGraph for the exact tool signatures. - The returned object is the authoritative entity record. Copy or pipe it to your destination.
There is no separate bulk-export operation for entity data beyond repeated get_entity_context calls — treat it as a lookup interface, not a bulk dump tool.
Path 2: Wiki articles as Markdown
Use this for article content you need for downstream publication, processing, or indexing.
Wiki articles are plain Markdown files with YAML frontmatter, stored directly in the media-knowledge-* git repositories. Read or export them the same way you'd export any file from a git repository — clone or pull the relevant repo and read the files you need directly. There is no separate HTTP export endpoint; the git repository itself is the export surface.
Path 3: Ledger entries for audit
Use this for tamper-evident records for compliance, legal discovery, or third-party audit.
Page through GET /v1/entries?since=<cursor> against your service-fs instance until the response is empty, then fetch GET /v1/checkpoint to anchor what you exported to a specific tree_size/root_hash. See Read the command ledger for the full procedure and Verify a WORM ledger entry for confirming what you exported hasn't been altered. The exported entries and checkpoint are both plain JSON, verifiable with a standard SHA-256 utility — no proprietary tooling required.
Choosing the right path
| What you need | Use path |
|---|---|
| Information about a named entity (person, project, service) | 1 — DataGraph |
| Article content for publishing or indexing | 2 — Wiki Markdown |
| Tamper-evident records for compliance or audit | 3 — Ledger entries |
Note: if you're looking for a spatial/GIS export path (co-location clusters, archetype data), that's a separate system this guide doesn't cover — check the GIS-specific documentation for your deployment rather than assuming the generic paths above apply there.
Expected outcome
The data you need, exported through the path that actually matches how the platform stores it — not a fabricated unified export endpoint that doesn't exist.
Verification
For entity data, confirm the returned profile's freshness matches your expectation (see Query the DataGraph). For wiki content, confirm the frontmatter block parses and the slug matches what you expected to export. For ledger entries, verify the checkpoint's tree_size covers every cursor you exported.
Rollback
All three paths are read-only. Nothing to undo.
Next steps
- Query the DataGraph — the full entity-lookup procedure
- Read the command ledger — the full ledger-reading procedure
- Verify a WORM ledger entry — confirm exported ledger entries haven't been altered
See also
- service-content — entity extraction and knowledge-graph host — the service that maintains the DataGraph
- service-fs — the WORM ledger backbone — the WORM ledger these entries come from