---
Title: GTS-SPEC: Graph Transport Substrate Wire-Format Specification
Subtitle: Normative wire-format specification for append-only RDF 1.2 graph transport
Type: Technical specification
Order: 100
DOI: 10.67342/6pta6imnmw/v1
Date: 2026-06-18
Updated: 2026-06-18
Version: 1
WorkId: 6pta6imnmw
PublicationVersion: 1
License: MIT OR Apache-2.0
CanonicalUrl: https://blackcatinformatics.ca/publishing/gts-spec.md
SourceUrl: https://github.com/Blackcat-Informatics/gmeow-gts/blob/main/docs/GTS-SPEC.md
CitationUrl: /publishing/gts-spec.csl.json
Summary: The GTS-SPEC defines the Graph Transport Substrate wire format: CBOR Sequence segments, deterministic CBOR headers and frames, BLAKE3 id/prev chains, transform catalogs, RDF 1.2 fold semantics, opaque-node degradation, media types, HTTP serving rules, and conformance scopes.
---

# GTS-SPEC

GTS-SPEC is the normative wire-format specification for GTS, the Graph
Transport Substrate. It defines how RDF 1.2 datasets and content-addressed
binary payloads are carried in a single append-only CBOR Sequence, verified
through deterministic frame hashes and folded into a logical graph.

## Publication and Version Identity

| Field | Value |
| --- | --- |
| DOI | `10.67342/6pta6imnmw/v1` |
| BII publication version | `1` |
| Upstream document version | `0.9-draft` |
| Wire-format major version | `1` |
| Status | Working draft |
| Published | `2026-06-18` |
| Publisher | Blackcat Informatics Inc. |
| Source document | `https://github.com/Blackcat-Informatics/gmeow-gts/blob/main/docs/GTS-SPEC.md` |
| Source repository | `https://github.com/Blackcat-Informatics/gmeow-gts` |
| License | `MIT OR Apache-2.0` |

The BII publication version follows the Blackcat Informatics Crossref suffix
policy: a stable z-base-32 work id plus an integer version component. The
upstream specification document keeps its own technical draft label,
`0.9-draft`, because wire-format stability and package release versions are
separate artifacts.

## Scope

GTS-SPEC defines:

- wire-format conformance for CBOR Sequence structure, deterministic CBOR
  encoding, segment boundaries, header grammar, frame grammar, content-id
  preimages, and signature/hash preimages;
- reader conformance for parsing, chain verification, payload resolution, fold
  behavior, diagnostics, opaque-node handling, and resource-bound behavior;
- writer conformance for deterministic output, valid headers and frames,
  correct content identifiers, codec declarations, and signing inputs;
- tool, profile, and deployment conformance where operations such as
  composition, archive handling, HTTP serving, range requests, and media-type
  publication impose stricter rules than local file validity.

Baseline GTS readers need the GTS wire-format rules, codec catalog, and RDF
term/fold semantics. They do not need GMEOW vocabulary, OWL reasoning,
domain-specific profiles, or agent-memory conventions.

## Abstract

GTS is an ontology-independent binary container and transport format for RDF
1.2 datasets and referenced binary payloads. A GTS file is a CBOR Sequence of
one or more append-only segments. Each segment contains a deterministic CBOR
header followed by deterministic CBOR frames linked by BLAKE3 content
identifiers. The logical dataset is obtained by a deterministic fold over the
segment sequence. The format supports partial readability, opaque encrypted or
unknown-codec frames, append-only suppression, optional signatures and
encryption, and cross-language conformance through a shared vector corpus.

## Key Normative Areas

| Area | Specification content |
| --- | --- |
| File structure | Multi-segment composition, streaming/progressive reads, and accretive versus streamable layout states. |
| CBOR conventions | Deterministic CBOR for hashed or signed material, map-key discipline, byte-string handling, and CBOR Sequence framing. |
| Header and frames | Segment headers, frame maps, frame types, transform/public/recipient/payload fields, predecessor links, ids, and optional signatures. |
| Graph fold | RDF 1.2 term ids, quads, annotations, quoted triples, reifiers, opaque nodes, suppression, duplicate handling, and value-union semantics. |
| Transform catalog | Mandatory core codecs, durable codec identifiers, stackable transform chains, unknown codec behavior, and capability separation. |
| Integrity and confidentiality | BLAKE3 frame self-hashes, id/prev chains, COSE signatures, COSE Encrypt0, and opacity invariants. |
| Profiles and tools | Files profile, stream vocabulary, composition rules, archive tooling, nested GTS, and transform targets. |
| Publication and deployment | Media type, file extension, file identification, HTTP serving semantics, immutability-aware caching, and range behavior. |
| Conformance | Versioned vector corpus, reader and writer classes, diagnostics, release-stamped manifest artifacts, and conformance claim structure. |

## Relationship to the GTS Project

The project page at `/projects/gts/` is the human-oriented GTS publication and
software project surface. This publication record identifies the standalone
technical specification document and its publication-version metadata. The
source specification is maintained in the `gmeow-gts` repository alongside the
Rust, Python, Go, and TypeScript engines that gate against the shared
conformance corpus.