# Symbian Heritage Archive — system manual

> Founding project brief preserved from the user-provided Notion export. This is planning and architecture source material, not a rights grant for any artifact it names.

**Source:** user-provided project brief, 2026-08-07  
**Status:** founding reference; refine claims with evidence as research proceeds.

---

<aside>
🎮

**SYMBIAN HERITAGE ARCHIVE — SYSTEM MANUAL**

**Mission:** preserve obsolete mobile software as a reproducible, portable experience — not merely as files.

**Core loop:** VAULT → EMOS → HOTMEM → GAMEBOX → RUNTIME → PLAY → DUMP → HYDRATE → CONTINUE

**First world:** Symbian / Nokia / N-Gage / Gameloft-era mobile software.

**Long game:** a memory + execution layer for disappearing digital heritage.

</aside>

## 0. THE RULE

> **Don't just preserve the file. Preserve the ability to experience it.**
> 

Preserve **artifact + provenance + environment + knowledge + state**.

Do not confuse:

- **Preservation** = retain evidence, artifacts, metadata, hashes, provenance and executable-environment knowledge.
- **Redistribution** = publicly distributing copyrighted binaries/firmware/media. Rights must be handled separately.

---

# 1. THE STACK

```
┌────────────────────────────────────────────────────┐
│                SYMBIAN HERITAGE ARCHIVE            │
│ games · devices · OS · firmware · docs · people   │
│ artifacts · evidence · provenance · oral history  │
└──────────────────────┬─────────────────────────────┘
                       ↓
                 HERITAGE VAULT
             canonical durable truth
                       ↓
┌────────────────────────────────────────────────────┐
│                       EMOS                         │
│ knowledge · routing · provenance · delegation      │
│ reconstruction context · memory lifecycle          │
└──────────────────────┬─────────────────────────────┘
                       ↓
                 HOTMEM SIDEcars
              live portable state
                       ↓
              HYDRATION / DELEGATOR
                       ↓
                   GAMEBOX
        game + OS + runtime + config + twin
                       ↓
             ┌─────────┼─────────┐
             ↓         ↓         ↓
           SERVER      PI      EMULATOR
             └─────────┼─────────┘
                       ↓
              PRESERVED EXPERIENCE
```

### Roles

| Layer | Job |
| --- | --- |
| **Vault** | Durable canonical artifacts, manifests, provenance/evidence. |
| **EMOS** | Durable knowledge, routing, provenance-aware reasoning, delegation, reconstruction context. |
| **HotMem** | Fast, dumpable, hydratable live state; portable memory sidecars. |
| **Hydration Engine** | Assemble bounded execution context from Vault + EMOS + HotMem. |
| **GameBox** | Quick-provisioned isolated playable environment. |
| **Runtime** | Emulator / native runtime that executes the preserved software. |
| **Server / Pi / local emulator** | Compute surfaces; same preserved state should travel between them. |

---

# 2. TWO ORIGINAL PATHS → ONE SYSTEM

## A. Pi / physical revival

```
Original game
 → Symbian emulator
 → Linux / ARM
 → Raspberry Pi handheld
 → PLAY
```

Use existing emulator infrastructure first; **EKA2L1** is the primary candidate to investigate. Do not start by writing a new Symbian emulator.

Target: a programmable physical preservation artifact that can run the same preserved environments locally.

## B. EMOS + preservation engine

```
Artifact
 → evidence / metadata
 → EMOS knowledge
 → environment resolution
 → hydration
 → runtime
 → experience
```

The archive is therefore not just a database. It is a **reconstruction system**.

## Convergence

The Pi is a physical client of the preservation system; server, desktop, browser, Pi and emulator are different execution surfaces over the same preserved model.

---

# 3. HOTMEM IS A FIRST-CLASS PRIMITIVE

The expanded architecture gives HotMem **two operating roles**.

### 3.1 GameBox / user memory

Per-environment live state can include:

- session state
- user configuration
- controller mapping
- emulator state
- temporary environment state
- game-specific metadata
- user preferences
- checkpoints / snapshots where technically supported
- player progress / interaction context

A GameBox gets a HotMem sidecar that can be **dumped and hydrated**.

### 3.2 Preservation / delegator memory

The delegator can use HotMem as its active operational substrate for questions/actions such as:

```
“What runtime does this artifact need?”
        ↓
EMOS knowledge + Vault evidence
        ↓
resolve environment
        ↓
hydrate GameBox
```

HotMem is therefore not one monolithic memory. Think **memory sidecars**:

```
          EMOS
            │
   ┌────────┼────────┐
   ↓        ↓        ↓
HotMem   HotMem   HotMem
GameBox  Archive  Delegator
```

**Vault = durable truth. EMOS = knowledge/orchestration. HotMem = active portable state.**

---

# 4. THE GAMING TWIN

A **Gaming Twin** is the portable stateful representation of a player's relationship with a preserved digital world.

It is **not merely a save file**.

```
            GAMING TWIN
                 │
     ┌───────────┼───────────┐
     ↓           ↓           ↓
  PLAYER        GAME      ENVIRONMENT
  state         state       state
     │           │           │
preferences   progress   configuration
history       inventory  device profile
interactions  discoveries runtime state
learned ctx   achievements compatibility
```

The twin can potentially move:

```
Server
  ↓ dump
Portable state
  ↓ hydrate
Raspberry Pi / local emulator / another server
  ↓
Continue
```

This creates a new preservation primitive:

> **Portable Digital Experience** — move not only the artifact, but the stateful relationship with the preserved environment.
> 

---

# 5. THE GAMEBOX

A **GameBox** is a quick-provisioned, isolated execution environment generated from the preservation system.

Conceptually:

```
GAMEBOX
──────────────
Game artifact
Symbian version
Device profile
Firmware/runtime deps
Emulator configuration
Display/input/audio config
        +
Gaming Twin / HotMem state
        ↓
PLAY
```

Desired user flow:

1. Request game + device/experience profile.
2. Delegator resolves required artifact/environment.
3. Vault supplies canonical material/evidence.
4. EMOS supplies knowledge and routing context.
5. Hydration assembles bounded context.
6. HotMem sidecar is instantiated.
7. GameBox boots.
8. User plays.
9. State can be dumped.
10. Another GameBox can hydrate it later.

---

# 6. THE PRESERVATION MODEL

Preserve five things:

### 6.1 Software

`.sis`, `.jar`, ROMs, executables, patches, configuration, installers, save data where appropriate.

### 6.2 Environment

Symbian releases, S60 editions, firmware, runtime dependencies, emulator configuration.

### 6.3 Hardware

Model, CPU, graphics, screen, input, audio, OS/firmware relationship and compatibility behaviour.

### 6.4 Context

Manuals, packaging, screenshots, advertising, magazines, reviews, developer docs, video/audio where rights permit.

### 6.5 Human knowledge

Former developers, designers, engineers, QA, localization, producers and other contributors.

The target is therefore:

**people + software + hardware + environment + culture + provenance.**

---

# 7. ARTIFACT LAKE / VAULT

Canonical storage should distinguish source artifacts from derived knowledge.

```
/artifacts
  /games
  /firmware
  /roms
  /manuals
  /screenshots
  /audio
  /video
  /advertising
  /development
```

Every preserved artifact should ideally carry:

- content hash
- version
- source
- acquisition/contribution event
- timestamp
- device/extraction context when known
- rights/access status
- relationship to equivalent artifacts

Hashes and manifests protect integrity; they do not by themselves create redistribution rights.

---

# 8. KNOWLEDGE + PROVENANCE MODEL

Represent relationships such as:

```
Game → Platform
Game → Symbian Version
Game → Device
Game → Developer
Game → Publisher
Game → Release
Game → Region
Game → Language
Game → Artifact
Game → Compatibility
Device → Firmware
Device → OS
Runtime → OS
Runtime → Device
Runtime → Game
```

Compatibility claims should be evidence-backed.

Example:

```
Game X
 ├─ artifact hash
 ├─ S60 version
 ├─ Nokia device profile
 ├─ EKA2L1 configuration
 ├─ test result
 └─ evidence / provenance
```

---

# 9. RECONSTRUCTION / HYDRATION

The system should eventually turn a human request into a reproducible environment:

```
“I want Game X as experienced on Device Y.”
                 ↓
            IDENTIFY ARTIFACT
                 ↓
            RESOLVE VERSION
                 ↓
        RESOLVE OS / DEVICE / RUNTIME
                 ↓
         VERIFY HASH + PROVENANCE
                 ↓
        HYDRATE BOUNDED CONTEXT
                 ↓
             START GAMEBOX
                 ↓
                 PLAY
```

The hydration engine is **bounded context assembly for execution**, not generic RAG.

---

# 10. EMULATION STRATEGY

Three revival levels exist:

### A — Emulation — DEFAULT

```
Original binary → emulator → modern hardware
```

Preserves the original artifact and reconstructs the execution environment.

### B — Reimplementation

```
Original software → reverse engineering → new implementation
```

Useful where appropriate; technically and legally more complex.

### C — Native port

```
Original source → modernization → ARM/Linux → Pi
```

Potentially excellent when legitimate source and rights exist.

**Rule: start with A.** Native ports are an extension, not the preservation foundation.

---

# 11. EKA2L1 + EXISTING INFRASTRUCTURE

The project should wrap existing infrastructure wherever possible.

**Primary emulator candidate:** EKA2L1.

Research before committing:

- Symbian/S60 versions supported
- device compatibility
- game compatibility
- ARM/Raspberry Pi viability
- firmware/ROM dependencies
- configuration requirements
- reproducible packaging
- emulator licensing

Do not conflate Symbian preservation with J2ME preservation. A title may have materially different builds for J2ME, Symbian, N-Gage, Windows Mobile, BREW, etc. Model the **game → platform → build → device** relationship explicitly.

---

# 12. GAMING CORPUS

Initial inspiration: the **Gameloft / Nokia / N-Gage era**.

Candidate targets include:

- Asphalt
- Prince of Persia
- Real Football
- Splinter Cell
- Rayman
- Diamond Rush
- Bounce
- N-Gage titles

These are candidate preservation targets, **not assumed redistributable binaries**.

MVP: **5–10 representative games**, selected for variation in platform, S60 generation, device, year, publisher/developer and technical difficulty.

---

# 13. THE KILLER DEMO

```
Prince of Persia — Symbian

✓ artifact identified
✓ version resolved
✓ device profile resolved
✓ environment reconstructed
✓ emulator compatible
✓ Gaming Twin ready

[ PLAY ]
```

Launch on the Pi.

Then:

```
PLAY
 ↓
DUMP
 ↓
move state
 ↓
HYDRATE elsewhere
 ↓
CONTINUE
```

The technical proof is not merely “the ROM runs.” It is:

> **the system can explain, reconstruct, checkpoint and move the experience.**
> 

---

# 14. DEVELOPER LEGACY LAYER

The archive should involve the people who built the world.

Potential contributors:

- former Gameloft developers
- Nokia / Symbian engineers
- game designers
- programmers
- QA
- localization teams
- producers
- publishers

Capture oral histories such as:

> “What did it take to ship this game on a Nokia N95 in 2007?”
> 

Attach that knowledge to the artifact/environment graph rather than leaving interviews as disconnected media.

```
GAME
 ├─ artifact
 ├─ device
 ├─ runtime
 ├─ compatibility evidence
 ├─ developer
 │   └─ oral history
 └─ preservation history
```

This is **software archaeology + AI memory + cultural heritage**.

---

# 15. LEGAL BOUNDARY

Keep infrastructure and rights-controlled material separate.

### Open / potentially open

- emulator integration
- preservation engine
- metadata schemas
- compatibility database
- hashes
- manifests
- provenance model
- hardware profiles
- environment specifications
- reproducible runtime definitions
- preservation tooling
- documentation

### Potentially restricted

- commercial game binaries
- firmware
- copyrighted artwork
- music
- manuals
- proprietary assets

Support **artifact references + hashes + provenance** even when the artifact itself cannot legally be redistributed.

Research German/EU preservation, software-archiving, emulator, research and controlled-access rules before public distribution.

---

# 16. WHAT MAKES THIS DIFFERENT

Not:

- a ROM dump
- a Symbian emulator
- a retro console
- a blockchain/token project
- an attempt to archive every mobile game immediately

It is:

> **AI-assisted preservation and reproducible emulation of obsolete digital cultural heritage, with portable live state.**
> 

The key new primitive is:

> **Portable Digital Experience = preserved artifact + reconstructed environment + portable operational state.**
> 

---

# 17. FUNDING / CULTURAL POSITIONING

Pitch the **heritage infrastructure**, not the toy:

> **Preserve and reproducibly reconstruct obsolete digital cultural heritage through open preservation infrastructure, machine-readable provenance, emulation, portable state and accessible physical interfaces.**
> 

Potential programme families to research/currently verify:

- Creative Europe
- Horizon Europe Cluster 2 / Culture, Creativity and Inclusive Society
- European cultural-heritage initiatives
- digitalisation / digital-preservation programmes
- German cultural-heritage / digitalisation funding
- university research programmes
- museum/archive partnerships

Potential consortium:

**open-source technical + preservation research + university + museum/archive + historical industry experts + emulator community.**

No funding call should be treated as confirmed until current eligibility/deadlines are checked.

---

# 18. KNOWB / EMOS / KNOWGUARD FIT

This project is a research application of the broader KnowB architecture.

Reusable primitives:

- durable memory
- episodic → semantic consolidation
- provenance
- artifact identity
- hashes
- filesystem-native storage
- derived indexes
- lifecycle/promotion
- routing
- bounded-context hydration
- replay/reconstruction

KnowGuard's **Verifiable Memory Evolution Chain** concept is relevant as an architectural analogy: consolidation/preservation events can carry input fingerprints, logic/version identifiers, output hashes, deltas, confidence, timestamps and policy context, enabling traceability and integrity checks.

The routing concept can similarly inform lightweight retrieval metadata for questions such as:

> “Which artifact/device/runtime/environment should be activated?”
> 

Do **not** assume a public blockchain is required. Cryptographic integrity and provenance are first-class; blockchain/tokenization is not.

---

# 19. THE CORE RESEARCH QUESTION

> **What minimum set of artifacts, metadata, provenance, environment knowledge and live state is required to reconstruct an obsolete digital experience decades after its original hardware and distribution ecosystem have disappeared?**
> 

Subquestions:

- How much information is sufficient for reproducible reconstruction?
- Can AI memory maintain compatibility knowledge over time?
- Can environments become reproducible rather than manually rebuilt?
- Can hardware profiles act as executable preservation specifications?
- Can a preservation engine automatically identify required runtime state?
- How should uncertainty be represented?
- How should portable live state be versioned and validated?
- Can the same Gaming Twin survive movement across server, emulator and physical hardware?

---

# 20. MVP — PROVE THE LOOP, NOT THE WHOLE WORLD

Start with **5–10 games**, but architect for the full system.

For each:

1. Identify versions/builds.
2. Identify target environment.
3. Identify legally accessible artifacts.
4. Hash + manifest.
5. Build game/device/runtime metadata.
6. Record provenance.
7. Test EKA2L1.
8. Build reproducible configuration.
9. Integrate EMOS.
10. Instantiate HotMem sidecar.
11. Provision GameBox.
12. Run desktop.
13. Run Raspberry Pi.
14. Dump state.
15. Hydrate elsewhere.
16. Continue.
17. Record compatibility + uncertainty.

**The MVP killer test:**

> One preserved Symbian game → one GameBox → one Gaming Twin → dump → another machine → hydrate → same experience.
> 

If this works, the core architecture is demonstrated.

---

# 21. PHASES

### P0 — LANDSCAPE + RIGHTS

Map Symbian archives, J2ME archives, emulators, EKA2L1 support, gaps and legal constraints.

**Output:** preservation/emulator/archive/rights map.

### P1 — ARTIFACT + RUNTIME

5–10 representative games; reproducible environments.

**Output:** first preservation packages.

### P2 — EMOS + HOTMEM

Knowledge/routing + live sidecars + provenance + hydration.

**Output:** artifact → environment → GameBox pipeline.

### P3 — PI

Portable physical client.

**Output:** Symbian Heritage handheld.

### P4 — HERITAGE NETWORK

Contributors, researchers, developers, museums, archives, oral history.

**Output:** collaborative Mobile Heritage Archive.

### P5 — EXPANSION

J2ME → Windows Mobile → Palm → BREW → early Android/iOS → early mobile web/Flash → other obsolete personal-computing environments.

**Output:** general digital-heritage memory + execution layer.

---

# 22. RESEARCH BACKLOG

## Ecosystem

- [ ]  Map existing Symbian archives.
- [ ]  Map J2ME/mobile-game preservation.
- [ ]  Identify Symbian-specific gaps.
- [ ]  Map emulator projects.
- [ ]  Deep-dive EKA2L1.

## Runtime

- [ ]  Test EKA2L1 on Linux.
- [ ]  Test ARM/Pi.
- [ ]  Resolve firmware dependencies.
- [ ]  Define reproducible runtime package.

## Data

- [ ]  Artifact schema.
- [ ]  Device schema.
- [ ]  Environment schema.
- [ ]  Compatibility schema.
- [ ]  Provenance model.
- [ ]  Manifest/hash model.
- [ ]  Gaming Twin schema.
- [ ]  HotMem snapshot/hydration contract.

## EMOS

- [ ]  Model preservation knowledge.
- [ ]  Model delegator context.
- [ ]  Model GameBox sidecars.
- [ ]  Define routing metadata.
- [ ]  Define bounded hydration.
- [ ]  Define replay/checkpoint semantics.

## Hardware

- [ ]  Raspberry Pi / Compute Module.
- [ ]  Display.
- [ ]  Controls.
- [ ]  Battery/power.
- [ ]  Enclosure.
- [ ]  Audio.
- [ ]  OS image.
- [ ]  Emulator integration.

## Heritage

- [ ]  Identify former Symbian developers.
- [ ]  Identify former Gameloft developers.
- [ ]  Oral-history format.
- [ ]  Museum/archive partners.
- [ ]  Academic partners.
- [ ]  Rights/provenance policy.

## Funding

- [ ]  Current EU calls.
- [ ]  German funding.
- [ ]  Consortium requirements.
- [ ]  University/museum partners.
- [ ]  One-page concept.

---

# 23. END STATE

```
               MOBILE HERITAGE
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
       VAULT               PEOPLE
          │             developers/users
          ↓                   │
         EMOS ←──────────────┘
          │
   ┌──────┴──────┐
   ↓             ↓
HOTMEM       HYDRATION
   │             │
   └──────┬──────┘
          ↓
       GAMEBOX
          │
   ┌──────┼──────┐
   ↓      ↓      ↓
 Server   Pi   Emulator
          │
          ↓
PRESERVED EXPERIENCE
          │
        DUMP
          │
    portable Twin
          │
       HYDRATE
          │
          ↓
    EXPERIENCE AGAIN
```

### The final vision

**Vault** remembers what existed.

**EMOS** remembers what it means and how to reconstruct it.

**HotMem** carries the live state.

**Hydration** rebuilds the bounded world.

**GameBox** makes it executable.

**Pi / server / emulator** make it physical.

**Developers + players** make it human.

**Provenance** makes it trustworthy.

**The archive** makes it survive.

> **A memory and execution layer for the disappearing history of personal computing.**
>