diff --git a/Project-Framing.md b/Project-Framing.md
new file mode 100644
index 0000000..3cd2b80
--- /dev/null
+++ b/Project-Framing.md
@@ -0,0 +1,155 @@
+A decentralized, participatory archive and storytelling network built on ActivityPub and the Fediverse.
+
+Project Framing
+
+MakingHistory is not a standalone application. It is a protocol-first component of the wider Open Media Network (#OMN) ecosystem, sharing infrastructure, governance, and code with:
+
+IndymediaBack - decentralized publishing and moderation
+
+OGB (Open Governance Body) - federated governance
+
+OMN Core - #4opens-aligned federation infrastructure
+
+The project follows two design principles, treated as hard architectural requirements rather than branding:
+
+#KISS (Keep It Simple) - build on existing standards and proven software wherever possible.
+
+#4opens - Open Data, Open Source, Open Standards, Open Process.
+
+The system avoids proprietary formats, closed governance, vendor lock-in, and unnecessary protocol extensions. New infrastructure is introduced only where existing Fediverse components cannot meet the project's needs.
+
+Architectural Principles
+
+Reuse existing software and infrastructure wherever possible.
+
+Federation before centralisation.
+
+Metadata-first: OMN is fundamentally about moving and curating metadata; media files are secondary?
+
+Human moderation before automation.
+
+Progressive enhancement, simple first, advanced capabilities layered on later.
+
+Server-first federation, with optional P2P replication and local-first caching (rather than treating any single device as primary storage).
+
+High-Level Architecture
+
+┌────────────────────────────────────────────────────────────┐
+│                      Client Layer                          │
+│                                                              │
+│  Web UI • Mobile/PWA • Exhibition/Kiosk Mode                │
+└────────────────────────────────────────────────────────────┘
+                           │
+              ActivityPub Client-to-Server (C2S)
+                           │
+┌────────────────────────────────────────────────────────────┐
+│                 MakingHistory Node                          │
+│                                                              │
+│ ┌────────────┐ ┌──────────────┐ ┌───────────────────────┐   │
+│ │ActivityPub │ │ Archive &    │ │ Story & Narrative     │   │
+│ │Actor       │ │ Media Engine │ │ Engine                │   │
+│ │Inbox/Outbox│ │              │ │ (timelines, curation, │   │
+│ └────────────┘ └──────────────┘ │  narrative assembly)  │   │
+│                                  └───────────────────────┘   │
+│ ┌──────────────────────────────────────────────────────┐    │
+│ │ Federated Moderation & OGB Integration                │    │
+│ └────────────────────────────────────────────────────────┘  │
+└────────────────────────────────────────────────────────────┘
+                           │
+            ActivityPub Server-to-Server Federation
+                           │
+         ┌─────────────────┼─────────────────┐
+         ▼                 ▼                 ▼
+    Mastodon         PeerTube        Other OMN Nodes
+
+Each archive - a family, activist group, community, museum, or organisation - operates as its own ActivityPub Actor, self-hosted on a VPS or hosted on a shared MakingHistory instance. As with PeerTube, each archive remains independently owned, portable, and federated, rather than locked into a single central database.
+
+Data Model
+
+EntityActivityPub mappingNotesArchiveActor (Group or Person)One actor per archive?Media itemDocument, Image, or Video, wrapped in CreateCarries core metadata (date, place, people, source, licence)HashtagHashtagUsed for flow filtering, discovery, curationSaved columnLocal boolean queryUser-defined dynamic view, not federatedMetadata editUpdateEvery edit becomes an auditable ActivityPub activityStoryArticle (or minimal Story extension)References existing archive objects rather than duplicating themAnnotationNoteStandard threaded commentsModerationFlag + OGB extensionsShared governance layer
+
+The model deliberately minimises custom object types, preferring existing ActivityStreams vocabulary wherever possible.
+
+Components
+
+4.1 Archive Ingest
+
+A low-friction workflow for digitising physical and digital archives:
+
+Bulk directory upload
+
+Drag-and-drop web upload
+
+Optional desktop import tool
+
+Lightweight metadata entry at upload time
+
+Optional OCR and EXIF extraction
+
+Immediate federation via Create(Document) activities
+
+The goal is to minimise the barrier to contribution while allowing richer metadata to be organically layered on afterward.
+
+4.2 Metadata & Curation Interface
+
+The primary interface follows a multi-column workflow, inspired by TweetDeck and Mastodon's advanced view.
+
+Default columns include:
+
+New
+
+Recent
+
+Untagged
+
+Users then create their own saved filters using boolean logic, e.g.:
+
+Oxford AND #1980s NOT #duplicate
+
+On mobile, a swipe-based workflow supports rapid tagging and categorisation. Metadata edits generate standard ActivityPub Update activities, so all subscribed clients refresh automatically.
+
+4.3 Story Engine
+
+Assembles curated collections of archive material into narrative structures. Stories are composed of existing ActivityPub objects minimising duplicating content, and should:
+
+Be embeddable
+
+Be federated
+
+Be CC-licensed by default
+
+Publish as standard Article objects wherever possible
+
+This makes storytelling another federated activity, not a separate publishing system.
+
+Front End
+
+Item mode (primary browsing view):
+
+Left/right navigation moves between new/old items; up/down scrolls within an item.
+
+Holding an item opens metadata entry - tags, text, comments - permissions-dependent on the user's edit rights.
+
+Archive visibility:
+
+Public archives are published as stories.
+
+Personal/private archives exist as a list of draft stories, not yet published.
+
+List mode (open design question - flagged for further work):
+
+Left swipe: add item to archive.
+
+Right swipe: tentatively, add metadata via the same swipe UX as item mode - needs to be specified before implementation.
+
+Back End
+
+Core responsibilities:
+
+Flows: content moves through the system based on boolean tag queries, supporting both in and out.
+
+Ownership: each object retains a clear owning actor even as it's imported, exported, or referenced across archives. (need to think about this)
+
+Editing & metadata: Update activities on flowing objects need consistent conflict handling as they propagate between nodes.
+
+Storage: a strategy is still needed for the split between live/cache databases and distributed permanent storage - open design question.
\ No newline at end of file