Skip to documentation
eli.aidocs

Platform

Export & offboarding

At the end of an engagement you can hand the client a complete, portable copy of their knowledge base — and then delete the workspace with a compliance-grade cascade. Both are service-layer operations, not UI conveniences you could forget.

The export tarball

An export is a .tar.gz of the client-facing knowledge base, with a manifest stamped with the schema version and an as-of timestamp. It contains:

  • Vault markdown — every document as its .md file.
  • The entity graph as JSONL — entities, relations (from canonical_relations), mentions, and relation evidence.
  • Golden sets — items, assertions, citations, and tags.
  • A manifest — workspace id/name, schema version, and generation time.

Cost/margin data is excluded by construction

A client deliverable never ships the consultant's economics. Excluded by design: llm_calls, spend_counters, extraction cost, provider_credentials, config_snapshots, and budgets. "Export = zip the vault" would have shipped the consultant's cost and margin data to the client — this is the fix.

Create an export

  1. Start the export

    POST /api/w/:workspaceId/export creates a workspace_exports row and builds the archive. A disk preflight verifies there's enough free space (with headroom) before writing. The row moves running → ready (or failed).

  2. Download it

    GET /api/w/:workspaceId/export/:id/download streams the finished tarball. List prior exports with GET /api/w/:workspaceId/export.
export contents (illustrative)bash
manifest.json
documents/northwind/interviews/cfo-2026-03.md
documents/…
graph/entities.jsonl
graph/relations.jsonl
graph/mentions.jsonl
golden/items.jsonl

Offboarding delete

Workspace destruction removes and verifies the application's workspace-scoped database and vault content. The registry is derived from the current schema and checked against the live PostgreSQL catalog before any delete:

Schema-derived, fail-closed destruction. The receipt is complete only when every purge target recounts to zero and the workspace vault was removed.
  • All 79 current workspace tables are discovered from the schema. Only audit_log and destruction_records are retained; the other 77 are ordered by foreign keys, purged, and independently recounted.
  • That includes documents, revisions, chunks, vectors, graph evidence, conversations, agent/eval history, connector/data-call records, schedules, webhook configuration, policy records, and semantic-cache entries.
  • Vault files are removed from disk. A vault failure produces ok: false even when the database purge completed. The retained incomplete record keeps the original export id, so a normal retry can finish vault removal after workspace_exports has already been purged.
  • The same database transaction explicitly deletes non-tenant SSO provider rows, encrypted client secrets, verified-domain claims, and linked OAuth account tokens. This is required because the Better Auth organization row remains as the audit anchor.
  • A dated destruction record written, referencing the backup-retention window, plus an audit_log entry.

Export-before-delete is enforced in the service layer

The guarantee is not "the UI reminds you." The service layer enforces export-before-delete, and a compiled-schema/live-catalog mismatch fails before deletion. The completion receipt requires every one of the 77 purge targets to be empty and the vault removal to succeed. SSO secrets, claims, and linked tokens are explicitly purged and counted separately. The delivered export tarball, Better Auth organization, memberships/roles, retained audit/destruction evidence, pg-boss queue state, and managed database backups are explicit retention or operational boundaries; they are not silently included in the application-data erasure claim.

Endpoints

  • GET/POST /api/w/:workspaceId/export — list / create an export.
  • GET /api/w/:workspaceId/export/:id/download — download the tarball.
  • POST /api/w/:workspaceId/workspace/destroy — the offboarding cascade (owner-gated).

For infrastructure-level backups (Postgres, vault files, retention), see Backup & data.