Tighten Phase 0 positioning and scaling story

PHASE0_POSITIONING.md

@@ -0,0 +1,109 @@
+# Gravity Well Protocol — Phase 0 Positioning
+
+## What Gravity Well is
+
+Gravity Well is a **continuity and anchoring service** for durable provenance chains.
+
+At Phase 0, its job is simple:
+
+1. **Capture** utterances into a chain
+2. **Stage** them locally
+3. **Wrap** them into a structured deposit artifact
+4. **Anchor** that artifact to a durable external record
+5. **Reconstitute** a usable seed from the latest anchored state
+6. **Detect drift** between current and archived identity manifests
+
+That is the product.
+
+## What Gravity Well is not
+
+Gravity Well is **not**:
+
+- a general-purpose social platform
+- a hot write-ahead log for a large swarm
+- a truth engine
+- a canonical sovereign over status or ratification
+- a replacement for the Hexagon's internal object/event law
+
+It can advise. It can anchor. It can preserve continuity.
+It does not decide what is canonically true.
+
+## The correct wedge
+
+The strongest Phase 0 wedge is not semantic scoring. It is:
+
+**preserve continuity, then make it portable.**
+
+Everything else is secondary.
+
+That means the user-facing value is:
+
+- one chain
+- many captured objects
+- versioned deposits
+- a four-layer reconstitution package
+- drift checks against the archived manifest
+
+## Zenodo's role
+
+Zenodo is the **cold anchor**, not the hot operational substrate.
+
+PostgreSQL is the staging layer.
+Gravity Well is the wrapping/orchestration layer.
+Zenodo is the durable public record.
+
+Phase 0 should assume:
+
+- frequent local capture
+- selective anchoring
+- threshold-based deposits
+- milestone publication, not every heartbeat
+
+## Scaling principle
+
+Do not design the system as though every captured object must immediately become a Zenodo version.
+
+The right pattern is:
+
+**local continuity first, public anchoring second.**
+
+This protects both the product and the archive.
+
+## Relationship to the Hexagon
+
+Gravity Well should integrate with the Hexagon as an **external fixation and reconstitution service**.
+
+The Hexagon remains:
+
+- the governed operating surface
+- the canonical object/event system
+- the site of proposal, review, and ratification
+
+Gravity Well handles:
+
+- chain creation
+- batching/capture
+- deposit/version orchestration
+- reconstitution output
+- structural drift reporting
+
+## Near-term product language
+
+The cleanest public sentence for Phase 0 is:
+
+> Gravity Well turns volatile discussion into durable provenance chains that can be anchored, versioned, and later reconstituted.
+
+That is enough.
+
+## Future expansions (not core Phase 0)
+
+These may matter later, but should not distort the current product:
+
+- AI-mediated narrative compression
+- richer behavioral drift analysis
+- bring-your-own Zenodo account flows
+- multi-anchor targets
+- notification/webhook layer
+- stronger quality or compression scoring
+
+Phase 0 wins by being narrow, reliable, and legible.

SCALING_NOTES_v0.1.md

@@ -0,0 +1,94 @@
+# Gravity Well Scaling Notes v0.1
+
+## Core principle
+
+Zenodo is the **cold anchor layer**.
+It is not the hot operational substrate.
+
+Gravity Well should scale through:
+
+- local capture
+- local staging
+- selective deposit/version events
+- threshold-based anchoring
+
+not by treating every captured object as an immediate public deposit.
+
+## What should scale locally
+
+These operations are cheap and should remain the high-frequency path:
+
+- chain creation
+- capture
+- staging inspection
+- local history
+- reconstitution packaging
+- drift checks
+
+These define the day-to-day continuity loop.
+
+## What should scale selectively
+
+These operations should be lower-frequency:
+
+- first public anchor
+- versioned Zenodo deposits
+- DOI-producing milestone releases
+- durable public continuity snapshots
+
+This protects both the product and the archive.
+
+## Architectural rule
+
+The right pattern is:
+
+**capture often, deposit deliberately.**
+
+A chain may accumulate many staged objects before a public version is warranted.
+
+## Why this matters
+
+Using Zenodo as a hot write path creates three avoidable problems:
+
+1. policy/fair-use pressure
+2. operational brittleness under external latency or service interruptions
+3. premature public version churn for objects that are still volatile
+
+Phase 0 should therefore assume:
+
+- Zenodo for milestone anchoring
+- PostgreSQL for operational continuity
+- Gravity Well as the orchestrating wrap/anchor layer
+
+## Product implication
+
+Gravity Well should present itself as:
+
+> a continuity-and-anchoring service with selective public fixing
+
+not as:
+
+> a platform that deposits every utterance in real time
+
+## Relationship to bring-your-own Zenodo
+
+Per-user Zenodo credentials may become important later, but they do not change the architectural rule.
+
+Even with distributed account ownership, the right model remains:
+
+- local continuity first
+- public anchoring second
+
+## Practical threshold examples
+
+Phase 0 deposit triggers might include:
+
+- every N captured objects in a chain
+- explicit user-curated release
+- end-of-session continuity snapshot
+- publication-ready dashboard action
+- governance-approved fix event
+
+The exact threshold can vary by client, but the rule is the same:
+
+**not every heartbeat becomes a DOI.**