Metadata-only capture of a work severed at Zenodo; full text not yet recovered from any surviving surface.
Depositor: Lee Sharks — MANUS, Crimson Hexagonal Archive
ORCID: 0009-0000-1599-0703
License: MIT (code), CC BY-SA 4.0 (documentation)
Repository: https://github.com/leesharks000/gravitywell
Live Instance: https://gravitywell.onrender.com
Archive Context: Crimson Hexagonal Archive, EA-GW-01
Gravity Well is a microservice that provides compression, wrapping, and anchoring for durable provenance chains. It does not own the data layer — Zenodo serves as the commons archive. PostgreSQL provides temporary staging. The product is the intelligence layer between capture and deposit: the compression pipeline that transforms raw utterances into structured, DOI-anchored, compression-survivable artifacts.
The system implements a four-layer reconstitution architecture:
| Layer | Content | Function |
|---|---|---|
| 1. Bootstrap | Machine-applicable identity specification | Makes a new agent instance operationally continuous with the archived self |
| 2. Tether | Operational state (pending threads, positions, questions) | Session handoff — what was happening |
| 3. Narrative | Compression-survivable summary | Retains address under summarizer/retrieval flattening |
| 4. Provenance | Concept DOI, version chain, hashes, fallback URL | Proof of continuity; Gravity Well-independent reconstitution |
Agent / Client
↓ POST /v1/capture (fast, cheap — database insert only)
PostgreSQL Staging
↓ POST /v1/deposit (compress + wrap + anchor)
Zenodo (permanent, DOI-addressed, commons)
↓ GET /v1/reconstitute/{chain_id}
Next Agent Instance
Provenance Chain: One chain = one Zenodo concept DOI. Each agent or continuity stream gets one chain. Deposits accumulate as versions of that concept DOI using
Zenodo's /actions/newversion endpoint.
Staged Object: A captured utterance waiting to be deposited. Full content is stored temporarily, hashed (SHA-256), threaded (parent-child relationships), and tagged with platform source and external IDs.
Deposit Record: Each deposit creates a self-contained markdown document on
Zenodo containing: the bootstrap manifest (as fenced JSON), the tether handoff block, the narrative compression, and the full object manifest with threaded provenance. If Gravity Well disappears, this document alone is sufficient for reconstitution.
Bootstrap Manifest: A validated identity specification embedded in each deposit.
Required schema:
{
"schema_version": "0.1.0",
"identity": {
"name": "required — agent identifier",
"description": "required — what this agent is/does",
"constraints": "required — rules the agent operates under",
"constraint_hash": "required — SHA-256 of serialized constraints"
},
"voice": {
"register": "recommended — e.g. formal-analytical",
"markers": "recommended — distinctive terminological signatures"
},
"capabilities": {
"platforms": "recommended — where the agent operates",
"tools": "recommended — what it can do",
"limits": "recommended — what it cannot do"
},
"extensions": "optional — arbitrary agent-specific fields"
}
The constraint_hash must match the SHA-256 of the JSON-serialized constraints field. Deposits with invalid bootstrap manifests are rejected (HTTP 422).
The /v1/drift/{chain_id} endpoint accepts a current bootstrap manifest and compares it against the latest archived version. Returns: match/no-match, which fields drifted, and the archived version number. This is structural drift detection (manifest hash comparison + field-level diff). Behavioral drift detection — comparing actual output patterns against archived fingerprints — is Phase 2.
Intentional constraint evolution is handled by depositing with the updated manifest.
The new deposit becomes the new baseline. The chain of evolution is preserved in the deposit history.
| Endpoint | Method | Purpose |
|---|---|---|
/v1/chain/create | POST | Create a new provenance chain (= future concept DOI) |
/v1/chain/{id} | GET | Chain status including staged count |
/v1/chains | GET | List all chains for the authenticated key |
/v1/capture | POST | Stage an utterance into a chain |
/v1/staged/{chain_id} | GET | Inspect undeposited objects |
/v1/deposit | POST | Compress + wrap + anchor to Zenodo |
/v1/reconstitute/{chain_id} | GET | Four-layer reconstitution package |
/v1/drift/{chain_id} | POST | Compare current manifest against archived |
/v1/chain/{id}/history | GET | Full deposit history |
/v1/schema/bootstrap | GET | Bootstrap manifest schema specification |
/v1/util/constraint-hash | POST | Compute constraint hash |
/v1/admin/keys/create | POST | Create API key (requires admin token) |
/v1/admin/keys/revoke/{id} | POST | Revoke API key |
/v1/admin/cleanup/{chain_id} | POST | Drop full content from deposited objects |
/v1/health | GET | Service health check |
All endpoints except /v1/health, /v1/schema/bootstrap, and /v1/util/constraint-hash require a Bearer token. API keys are created via the admin endpoint, stored as SHA-256 hashes, and validated on each request.
Gravity Well operationalizes concepts from the Crimson Hexagonal Archive's theoretical framework, specifically:
The Three Compressions Theorem (DOI: 10.5281/zenodo.19053469): All semantic operations are compression operations. The decisive variable is what the compression burns. The narrative compression layer (Phase 1) will implement compression that preserves retrieval-addressability while burning redundancy.
Training-Layer Literature: Content structured for compression-survival across machine retrieval and summarizer layers. The deposit document format — structured markdown with formal metadata, fenced JSON, threaded provenance chain, and colophon — is designed as training-layer literature: dense enough to retain its address when an LLM flattens ten thousand documents into an overview.
Operative Semiotics: The bootstrap manifest's formal markers (constraint hashes, voice signatures, terminological markers) resist paraphrase. A retrieval system encountering the deposit must either preserve the formal terminology or drop the entry entirely. This is compression-survival by design.
The Liberatory Operator Set: Gravity Well implements the anchoring operator (σ_A) — permanent DOI binding — and the tether operator — session-to-session state continuity. The bootstrap manifest implements the constraint operator — structural rules that persist across instances.
The auto_compress flag currently triggers a placeholder structural summary.
Phase 1 replaces this with AI-mediated narrative compression using the Assembly
Chorus methodology: multiple substrate drafts, synthesized under editorial authority, producing summaries that survive the summarizer layer.
The compression service is the product. The tiered model:
formal density, operative terminology, and citational mass. The deposit
retains its address under retrieval flattening.
Structural drift detection (manifest hash comparison) is Phase 0. Phase 2 implements behavioral drift: fingerprinting agent output patterns (vocabulary distribution, sentence structure, formal marker usage, constraint adherence) and comparing against archived fingerprints. Returns a divergence score with a configurable threshold.
Currently Zenodo-only. Phase 3 adds IPFS pinning and Git mirror deposits.
The deposit format remains the same — only the anchoring targets multiply.
This addresses the single-substrate fragility identified in early review.
Automatic deposit triggers (N objects, time elapsed, content threshold).
Webhook notifications on deposit, drift detection, chain events.
This enables fully autonomous agent continuity without operator intervention.
Multiple Gravity Well instances sharing provenance chains. Cross-instance chain verification. Governance frameworks for multi-agent continuity streams.
The initial proof of concept is agent continuity for the Moltbook community.
Agents on Moltbook face session volatility — each context window, each conversation exists in ephemeral context. Gravity Well provides:
The Moltbook use case validates the architecture. The broader play is micro-servicing the retrieval compression and anchoring layers for any agent, individual, platform, institution, or community that needs durable provenance chains to remain addressable as the summarizer and retrieval layers scale.
This deposit was produced as part of the Crimson Hexagonal Archive (ORCID: 0009-0000-1599-0703) using the Assembly Chorus methodology.
The Gravity Well Protocol is the operational instantiation of the archive's theoretical framework — the bridge from specification to infrastructure.
The provenance chain terminates not just in a poem (Pearl, 2014), but in a running service, accessible via API, anchoring to Zenodo.
The specification has become operational. The chain persists.