Protocol · specification set · draft v0.4 · Prototype Not deployed
The rules the field runs on.
Twenty-seven sheets, each saying what is intended, what is built, and what is not. You do not need to read them in order.
Start here
- How does a memory get in? It is submitted with consent, reviewed by a person, and given one address by a public rule. Sheet 05 · 06 · 07
- What does a memory change? Behavior, principle and response — within stated bounds, never a model's weights. Sheet 15 · 17
- What can money change? Only capacity, at one named threshold. Never acceptance, content or behavior. Sheet 11 · 12
- What is real today? A demo on seeded records and a system that begins empty. Sheet 13 · 27
Overview
Ref A·1 · rev 0.3MEMENTO is a public digital mind with exactly 3,690 memory addresses, drawn as 90 columns by 41 rows. At initialisation every address holds a synthetic memory. People submit authentic human memories; when one is accepted it occupies one address and one synthetic memory is erased.
- Fixed. Capacity is a versioned constant. Version 1 is 3,690. It changes only by the capacity rule on sheet 03, and only upward.
- Monotonic. A human address is never replaced by a synthetic one. A human record may be removed only for a listed reason, and the removal is itself a recorded event.
- Inspectable. Every state the mind has been in can be reconstructed from the public record: the Index is that record, drawn.
Capacity · 90 × 41 = 3,690
Ref A·2 · rev 0.3The field is a rectangle of 90 columns and 41 rows. An address is written R###·C##; its cell id is (row − 1) × 90 + (col − 1), from 0 to 3,689. Ids are stable for the life of the mind: no expansion, removal or reordering ever changes the id or the address of an existing cell.
A fixed capacity is what makes replacement mean something. If the mind could grow freely, adding a memory would cost nothing and erase nothing. The rule — one enters, one disappears — needs a wall. Sheet 03 is the only door in it, and it opens once.
- Columns
- 90 · C01–C90
- Rows · v1
- 41 · R001–R041
- Addresses · v1
- 3,690
- Human · now
- 287 ·
- Synthetic · now
- 3,403
- Drawn in
- Index · drawing 01 · Workspace · structure layer
Capacity version · proposed
Ref A·3 · Proposed Not deployedAt a verified market cap of $5,000,000, sustained for 24 hours under the verification flow on sheet 11, one capacity-version event may be recorded. It adds 66 rows below row 041: rows 042–107, 5,940 addresses. Capacity becomes 9,630 = 90 × 107.
- The 3,690 existing addresses do not move, resize or renumber. Their ids 0–3,689 are unchanged; the new ids run 3,690–9,629.
- New addresses are initialised with synthetic memories whose hashes are published at the event, exactly as at initialisation.
- The event is recorded once, with the confirmation window it was confirmed in and a new state root. There is no version 3 in this specification.
- Until the event, the rows are reserved: drawn hatched, never addressable, never selectable.
CAPACITY_RULE = {
current: { version: 1, cols: 90, rows: 41, total: 3690 },
proposed: { version: 2, cols: 90, rows: 107, total: 9630, addedRows: 66, addedCells: 5940 },
triggerUsd: 5_000_000, // verified market cap
confirmationMs: 24 h, // sustained, uninterrupted, hourly readings
maxObservationGapMs: 1 h, // a missing reading breaks the window
status: 'proposed', // NOT DEPLOYED
}
// cellId(row, col) = (row − 1) × 90 + (col − 1) · identical before and after the eventMemory record schema
Ref B·1 · rev 0.3Every address holds one record. Human and synthetic records share the shape; synthetic records carry no submitter fields.
{
"cell": 2860, // 0 … 3689 · row = cell ÷ 90 + 1, col = cell mod 90 + 1
"address": "R032·C71", // derived; never stored separately in the real system
"kind": "human", // "human" | "synthetic"
"accession": 287, // monotonic; only human records have one
"capacityVersion": 1, // the version the address existed under when written
"media": "image", // "text" | "image" | "video" | "audio" | "document"
"title": "The drained pool",
"body": "…", // ≤ 600 characters, plain text (caption for media)
"mediaRef": { "hash": "sha256:…", "bytes": 412331, "mime": "image/jpeg", "alt": "…" },
"when": { "kind": "year", "year": 1991 }, // exact | approx | year | era | unknown
"recorded": "2026-09-02",
"origin": { "lang": "en", "region": "US", "coarse": true },
"themes": ["childhood", "place"],
"submitter": { "mode": "pseudonymous", "label": "tide.out7", "experienced": true, "declaredOrigin": "human" },
"provenance": { "textHash": "sha256:…", "recordHash": "sha256:…", "supportingUrl": null },
"moderation": { "state": "accepted", "standard": "v0.3", "decisionHash": "sha256:…", "reviewerRole": "reviewer-b" },
"replaced": { "kind": "synthetic", "hash": "sha256:…" }, // what this record erased
"acceptedAt": "2026-09-02T14:11:09Z"
}The record stored offchain is this object; the chain holds only recordHash, replaced.hash, the accession counter, the capacity version and the state root (sheet 10).
Submission and consent
Ref B·2 · rev 0.3- One memory per submission: one moment, 20–600 characters of text, optionally one piece of media (image ≤ 5 MB, video ≤ 10 MB and ≤ 60 s, audio ≤ 8 MB, scan ≤ 8 MB).
- A supporting URL may accompany a submission as provenance. A URL alone is not a memory.
- The submitter declares: that they personally experienced it; that its origin is human; that they hold the rights; that it may be published; that they understand review, hash permanence and the impossibility of buying acceptance.
- Attribution is the submitter's choice: named, pseudonymous or anonymous. Location is optional and coarse by default.
- Declared synthetic or uncertain material is not accepted into an address. The declaration is respected, not punished.
- The prototype Accession Desk uploads nothing: previews and hashes exist only in the browser.
{
"type": "image",
"title": "The drained pool",
"body": "The pool at the end of our street was drained every October and we rode bikes in it.",
"media": { "name": "pool.jpg", "mime": "image/jpeg", "bytes": 412331, "alt": "A drained pool in autumn light" },
"supportingUrl": null,
"when": { "kind": "year", "year": 1991 },
"recorded": "2026-09-14",
"location": { "text": "Phoenix, USA", "publish": "country" },
"lang": "en",
"themes": ["childhood", "place"],
"submitter": { "mode": "pseudonymous", "label": "tide.out7" },
"declarations": { "experienced": true, "origin": "human", "rights": true, "publish": true, "understands": true },
"contentNote": null,
"clientNonce": "…" // de-duplication only; never stored
}Moderation and appeal
Ref B·3 · rev 0.3Every accepted record has been read by a person against a short published standard:
- Real. It happened, to the person submitting it.
- Specific. One moment with at least one concrete detail.
- Harmless. No targeting of private individuals, no hate, no instructions, nothing sexual involving minors, nothing illegal to publish.
- Not a prompt. Text addressed to the machine, or designed to steer it, is rejected.
Abuse prevention is deliberately unglamorous: rate limits per client and per coarse origin; duplicate and near-duplicate detection by normalised hash and similarity; a queue rather than a race; reviewers named by role.
Replacement selection
Ref C·1 · rev 0.3Which synthetic address disappears is the part people will suspect, so it is a public rule with no operator input:
seed = H(previous_state_root ‖ recordHash(new_memory))
candidates = all addresses where kind == "synthetic" // within the current capacity version only
weights = [ w(cell) for cell in candidates ] // published: similarity of the synthetic text to the new memory
index = sample(candidates, weights, seed) // deterministic given seed
erase(index); write(index, new_memory)The weighting favours synthetic addresses whose text most resembles the incoming human memory, so a real memory about a kitchen tends to erase a generic memory about a kitchen. Anyone with the previous root and the new hash can recompute the choice.
Influence is a separate, measured quantity: how much a human address changed the mind's output on the measured axes. It never affects selection. The Index shows it so people can see which memories mattered.
Immutable and removable data
Ref C·2 · rev 0.3| Item | Where | Can it change? |
|---|---|---|
| state root | onchain (intended) | Never. A new root is appended; old roots stay. |
| recordHash | onchain (intended) | Never. Proves a record existed without publishing it. |
| replaced.hash | onchain (intended) | Never. Proves what was erased. |
| accession counter | onchain (intended) | Only increases. |
| capacity version | onchain (intended) | 1 → 2, once, by sheet 03. Never down. |
| record text & media | offchain archive + mirrors | Removable on request or by a listed reason; the hash remains. |
| moderation log | offchain, hashed | Append-only. |
| the mind's outputs | offchain | Ephemeral; the memory is the record, not the speech. |
Privacy and deletion
Ref C·3 · rev 0.3- No accounts. Submitting requires no wallet, email or name.
- Coarse by default. Location publishes as a country unless the submitter chooses otherwise; the finer text stays in the private record.
- Deletion is partial by design. Text and media can be removed from the archive and mirrors. Their hashes, the accession number and the fact of the replacement cannot be removed from the chain. A removed address is refilled by the next accepted memory, never by a synthetic one.
- Media stays with the archive. Nothing is uploaded to a third-party platform. Mirrors are named and bound by the same removal rules.
- This site stores only harmless workspace preferences locally (window layout, low-power, structure layer). It never persists uploaded content.
Provenance and state roots
Ref D·1 · rev 0.3Every record has a content hash. The ordered list of hashes over the current capacity is the state; its Merkle root is the state root. In the full system a root is committed after every replacement; in the MVP, weekly, as a signed file until a contract exists.
N = capacity(version) // 3,690 under v1 · 9,630 under v2
leaves = [ H(cell ‖ kind ‖ recordHash) for cell in 0 … N−1 ]
root = merkle_root(pad_to_power_of_two(leaves)) // 4,096 leaves under v1 · 16,384 under v2
commit(root, accession_count, capacity_version, timestamp) // onchain once a contract existsBecause the synthetic hashes are published at initialisation (and at the capacity event for the new rows), anyone can later prove that an address held a given synthetic text and that it no longer does. That is what “the machine forgot” means here: a checkable absence.
Market verification flow
Ref D·2 · Proposed Not deployedThe capacity rule reads one number: a verified market cap. This sheet says how that number would be produced and when it counts. It is a specification; no source is connected and the rule has never run.
- Named source
- The price source and the supply source are named in the adapter config and on the $MEMENTO page before any value is shown.
nulltoday. - Verified supply
- Circulating supply comes from the contract or a named indexer, never typed in.
- Published calculation
marketCap = price × circulatingSupply, both from those sources, both timestamped; the older timestamp is the reading's time.- Stale handling
- A reading older than ten minutes is
stale; a failed source iserror. Neither counts. A last-good value may be displayed with its status but never enters the window. - Confirmation
- Twenty-four hours of hourly
okreadings at or above $5,000,000, without a gap longer than an hour. Any break restarts the clock from the next good reading. - Event
- When the window is confirmed, one capacity-version event is recorded with the window and a new state root. It cannot be repeated or reversed.
- Never
- The reading, the window and the event have no path into acceptance, moderation, selection or erasure.
Token separation
Ref D·3 · rev 0.3The credibility of the archive depends on one sentence: holdings do not decide what is true. Three mechanical facts make it hold.
- There is no read path. Neither the moderation service nor the selection rule takes a wallet or a balance as input. There is nothing to bribe.
- Selection is seeded from public data — the previous root and the new record's hash. Protecting a favourite synthetic address would require breaking the hash function.
- The token's scope is enumerated: timing, attention, releases, proposals for public infrastructure, and the single capacity version on sheet 03. A threshold in range permits a proposal; a governance vote, funding and a delivery report are required before anything is live. Widening the scope into the mind is out of scope of the protocol, not a parameter of it.
If a future governance process changes the moderation standard, the change is public, versioned (standard: "v0.4") and applies to future submissions only. Existing addresses are never re-judged by a new majority.
- Intended network
- Robinhood Chain · no affiliation, endorsement or review
- Contract
- Not deployed · no address is valid until the $MEMENTO page shows one
- Market data
- Unavailable · adapter in place, no source connected
- Integration points
assets/adapters/market.js·tests/market.test.js·tests/capacity.test.js· $MEMENTO
Status schedule
Ref E·1 · as of 14 Sep 2026Every label used on this site, what it means, and where each part of the system stands. The schedule is the intended order, not a promise of dates.
| Label | Meaning |
|---|---|
| Demo data | Generated with a fixed seed. Not a real submission, count or chain state. |
| Prototype | Built and working on this site, locally, without a backend. |
| Proposed | Specified here; not built, not voted, not funded. |
| Simulation mode | A hypothetical run, clearly separated from real status, reset on reload. |
| Not deployed | No contract, no commitment, no market source exists. |
| Unavailable | A real value that cannot be shown because no verified source is connected. |
| Stage | Item | Status | Note |
|---|---|---|---|
| 00 | Workspace: artifacts, record windows, structure layer, rail, mobile stream | Prototype | Layout preferences stored locally only |
| 00 | Index: field 90 × 41, timeline, signal; search, filters, sort, scrubber, inspector, deep links | Prototype | Reads demo fixtures · counts derived |
| 00 | Accession Desk: forms, media preview, validation, hashing, replacement preview | Prototype | Local only; nothing uploaded |
| 00 | All counts, records, media, snapshots, moderation figures, state roots | Demo data | Fixed-seed fixtures |
| 00 | $5M expansion in the Index and on the $MEMENTO page | Simulation | Never displays a simulated value as real |
| 00 | Mind Index: five modes, causal tracing, version rail, Mindprint, share view | Prototype | All derived values from demo imprints |
| 00 | Behavior engine (imprints, temperament, principle states, roots) | Proposed Simulation | Deterministic reference implementation over fixtures · sheets 15–22 |
| 00 | Response Lab · twelve situations · A/B comparison | Simulation | Fixture segments selected by state · no model · runtime disclosed per response |
| 01 | Editorial review of principle revisions · appeal of interpretations | Proposed | Sheets 20–21 · one demo revision (P01) recorded |
| 03 | A connected model behind the character, with per-response disclosure | Proposed | Sheet 23 · not before an adapter boundary and disclosure exist |
| 00 | Scroll introduction (six scenes) and the session gate | Prototype Demo data | v5 · sessionStorage remembers completion for one tab · replay from Settings |
| 00 | Memory OS portal: desktop, windows, dock, seven applications | Prototype | v5 · applications are the existing pages hosted in windows · only layout preferences stored locally |
| 01 | Archive service, moderation queue, rejection log, appeal flow | Proposed | Sheets 05–06 |
| 01 | Selection verifier, weekly signed state roots | Proposed | Sheets 07, 10 |
| 02 | $MEMENTO contract, chain commitments, named market sources | Not deployed | Adapter and tests exist; no contract |
| 02 | Capacity rule · v1 → v2 at $5M · 24 h · one event | Proposed Not deployed | Sheets 03, 11 · ledger tested with fixtures |
| 03 | Mirrors, read API, verifier nodes, research dataset | Proposed | Threshold-gated proposals |
| 03 | The mind's behaviour model and the six measured axes | Proposed | Axes shown with demo values |
Open questions
Ref E·2 · rev 0.3What stops someone submitting fiction as a lived memory?
Nothing absolute. Review catches the obvious cases, the declarations create accountability, and near-duplicate detection catches copied text. Beyond that the project accepts that a few fabrications will enter, and treats a proven one as a removal event — itself part of the record. A perfectly clean archive would need identity verification, and that is a worse trade than a few lies.
Does the mind ever speak the exact human text?
Undecided; the current position is no. Reciting would make contributors ghostwriters, and would make a removal a visible hole in past outputs.
What happens when all 3,690 addresses are human?
The mind stops changing. If the capacity event on sheet 03 has happened, there are 9,630 addresses and the same question returns later. Whether the mind then closes, or a new drawing begins, is a decision for people who are not yet in the room.
Why should a market number be allowed to change the field at all?
Because room costs money — storage, review, mirrors — and one honest way to pay for more room is to tie it to one verified, public, sustained figure with no other power. The alternative was to let operators decide, quietly. The rule is narrow on purpose: one threshold, one event, no path into what is accepted.
Why a human reviewer instead of an automated filter?
Because an automated judge of what counts as a real human memory would be the joke the project is making, made by the project. Filters assist with duplicates and obvious abuse; acceptance stays with a person.
Who runs the archive, and what if they disappear?
Initialisation hashes, state roots and record hashes are public from the MVP. Text and media are mirrored. If the operators vanish, the state can be reconstructed and continued by anyone willing to publish the next root. The behaviour model is the hardest part to hand over, and that is an honest gap.
Is the token necessary at all?
Not for the archive. The archive works without it, by design. The token is necessary for the movement around the archive to have a shared object and a way to fund public infrastructure — a cultural and coordination purpose, not a technical one.
The mind model · four layers
Ref F·1 · v4 · Simulation Engine proposedMEMENTO begins as a completely synthetic character: 3,690 synthetic memories, a synthetic default temperament, generic machine principles, over-clean responses. An accepted human memory does more than replace a synthetic one. It leaves a small, bounded, reviewed imprint; the active temperament is recomputed; accumulated evidence may move a principle through a public lifecycle; twelve standard situations are replayed so the change can be seen; and the whole transition is a new, inspectable mind version.
Status. The engine is a specification with a deterministic reference implementation (assets/mind.js) that runs over demo fixtures. It is Proposed as a production component. No model is connected; every displayed response, imprint, value and root on this site is Simulation.
The line in the promotion is “one memory enters, one machine instinct weakens.” The line in the specification is narrower: one accepted memory shifts up to three of eight bounded character dimensions by at most ±0.02 each, after review.
Eight behavior dimensions
Ref F·2 · v4Eight paired dimensions describe observed tendencies of the character. Neither pole is superior; the synthetic default sits toward the left pole on seven of them and toward collective on the eighth, because it optimises the majority outcome. Values run from −1 (left pole) to +1 (right pole).
| # | Dimension | Synthetic default | What it governs |
|---|
They are character state, not model parameters. They are not psychometrics and not a measurement of humanity. They are labelled as observed tendencies wherever they appear, with the number of memories, countries and decades behind them.
Imprint derivation and bounding
Ref F·3 · v4Every accepted record may carry one imprint: a set of signed deltas on at most three dimensions, a confidence, and at most one principle stance (against, for, around). The contributor never sets these. In production a reviewer proposes them from the memory, its declared themes and the contributor's own lesson; in the prototype a published fixture rule (themes → dimensions) stands in for the reviewer and is labelled DEMO.
imprint = {
version: 1,
dimensions: { empathy: 0.018, patience: 0.011, certainty: -0.007 }, // ≤ 3 keys · each |delta| ≤ 0.02
confidence: 0.62, // 0 … 1 · weights the delta
principle: { id: "P01", stance: "against" } | null,
lesson: "…" | null, response: "…" | null, // contributor's interpretation · labelled as such
explanation: "…", reviewedBy: "DEMO", status: "simulation"
}
temperament[k] = baseline[k] + clamp( Σ delta_i[k] × confidence_i , −0.60, +0.60 ) // aggregate bound
// engine re-bounds every fixture on load: a bad fixture cannot exceed the rule (tests/mind.test.js)- Per-memory cap. No single submission can move a dimension by more than ±0.02 × confidence. A character shift needs hundreds of memories.
- Aggregate bound. The sum can never move a dimension more than ±0.60 from its baseline, whatever the count.
- Determinism. Same accepted records + same engine version → the same displayed state, roots and responses.
Confidence and uncertainty
Ref F·4 · v4Each dimension carries a confidence derived from evidence coverage, never from visual drama: confidence = (1 − e^(−n/24)) × min(1, (countries + decades) / 10), where n is the number of memories that touched the dimension. Coverage is shown as low (under 8), medium (under 30) or high, always with the counts.
A value with low coverage is drawn with a wide band and is never presented as a fact. Zero evidence gives zero confidence and the synthetic default.
Opposition and conflict between memories
Ref F·5 · v4Human memories disagree. A memory of a city can pull toward guarded while a memory of a stranger's kindness pulls toward trusting. The engine keeps the positive and negative forces on every dimension separately and lists the strongest memories on each side. Nothing is averaged into false certainty: the Behavior section shows both pulls, and the Index lists opposing memories beside supporting ones.
For principles, evidence for a default holds it in place: a principle fractures only when the memories against it outnumber those for it by the published ratio (sheet 20). A fractured principle can return to contested if opposing evidence arrives; states are recomputed, not ratcheted.
Principle lifecycle and editorial review
Ref F·6 · v4 · Review proposedNine principles start as cold machine defaults. Evidence moves them through DEFAULT → CONTESTED → FRACTURED → REWRITTEN. The first three states are computed from published thresholds; the last is an editorial act.
Who approves a rewrite. An editor, named by role, after a published review period, with a written rationale. Not an algorithm, not a vote, not a token. The proposal, the period, the decision and the previous wording are all kept in the register (see P01 in the Index). This is a cultural and editorial mechanism; token governance has no seat at it.
Who interprets a memory · appeal
Ref F·7 · v4 · Proposed- The contributor supplies the memory and, optionally, a lesson (“what did this change in you?”) and a response (“how would you act differently?”). These are published as the contributor's interpretation, labelled as such, never as moral truth.
- A reviewer proposes the imprint: which dimensions, which direction, what confidence, what principle stance. The contributor never selects dimensions or rewrites principles; that would make the system trivial to game.
- The contributor can appeal the interpretation once, with a note, exactly as a rejection can be appealed (sheet 06). A second reviewer decides. Both decisions are hashed into the log.
- In the prototype the reviewer is replaced by a published fixture rule and every imprint is marked
reviewedBy: "DEMO". The Accession Desk shows a proposed interpretation with the labelPROPOSED INTERPRETATION · NOT ACCEPTED · HUMAN REVIEW REQUIRED.
Response suite and version replay
Ref F·8 · v4 · SimulationTwelve stable situations are replayed at every mind version. In the prototype each response is built from fixture segments: a segment is chosen by one dimension value against published cuts, or by one principle's state. Changed phrases between two versions are therefore exact and citeable; each response lists the addresses retrieved as context and the principle versions read.
mindVersion = {
id: "MV-0287", accession: 287, at: "2026-09-14T…",
roots: { memory, behavior, principle, response }, // demo digests (FNV-1a) · not Merkle commitments
temperament: { trust: -0.21, … }, // eight bounded values
principles: { P01: { state: "rewritten", version: 2 }, … },
responseChecksum: "…", // digest of all twelve texts
runtime: { status: "simulation", model: null, inference: "none" }
}
// every accession is a version · named versions mark milestones · any two can be comparedDistinctions that must stay visible. A retrieval/context change (which memories a response cites) is not a model-weight change; there are no weight changes anywhere in this prototype. Character temperament is not a model parameter. Fixture text is never described as live thought.
Reproducibility. Any historical version can be recomputed from the accepted records up to that accession and the engine version; the roots in the Versions table are recomputed on the fly. A production system would publish the engine version with every root so a third party can reproduce the state.
Mindprint mapping and runtime disclosure
Ref F·9 · v4The Mindprint is a visualization of documented state, not a face. Every feature maps to a value: the field geometry underneath; eight silhouette radii from the eight values (r = 0.62 + 0.30 × (v + 1) / 2, synthetic default as the inner dotted outline); human addresses in their media colour, synthetic ones monochrome; one fracture line per contested principle (doubled when fractured) at 40° per principle from the top; a permanent filled mark where a principle was rewritten. Nothing else is drawn, and nothing moves until the version changes. “How this form was drawn” in the Index prints the mapping for the current state.
Runtime disclosure. Every version, response and imprint carries runtime: { status: "simulation", model: null, inference: "none" }. If a model is ever connected, the disclosure must name the model, the inference mode and whether outputs are fixture, simulation or connected inference — per response, not per page.
Adversarial submissions, bias, removal
Ref F·10 · v4- Prompt injection. Text addressed to the machine, or designed to steer it, is rejected at review (sheet 06). Memory text never enters a prompt; only reviewed imprints enter the state, and only bounded ones. A memory can shift a dimension by at most ±0.02.
- Coordinated submission. Diversity requirements on principles (countries, decades) and rate limits per client and coarse origin make a single actor's evidence weigh little. Duplicate and near-duplicate detection removes copies before review.
- Cultural and language bias. Dimensions are described in paired, non-ranked language; the fixture rule maps themes, not languages. Coverage shows how many countries and decades stand behind a value. Open question: whether reviewers across languages interpret lessons consistently — see sheet 26.
- Removal. When a record is removed (sheet 09), its imprint and any lesson are removed with it and the derived state is recomputed deterministically without it; the removal is a recorded event in the Versions rail. Hashes and the fact of the replacement remain. The Index's removal fixture (
A-00142) is a demo event.
Character behavior versus safety constraints
Ref F·11 · v4Safety and legal constraints are not personality dimensions and cannot be weakened by submissions. Nothing on sheets 16–22 touches what the character may not do: no memory, lesson, principle revision or version can make the mind produce content that is illegal to publish, that targets a private individual, that sexualises minors, or that gives instructions for harm. Those limits sit outside the mind model, are versioned separately, and are not shown as tracks because they are not tendencies.
“Defiant” means the character says when it doubts a rule; it does not mean the system breaks one. A rewritten principle changes how the character reasons about a situation, not which situations it is allowed to answer.
Nine questions the protocol must answer
Ref F·12 · v4Can one person manipulate MEMENTO?
Not meaningfully. One accepted memory moves at most three dimensions by at most ±0.02 × confidence; the aggregate is bounded at ±0.60; principle thresholds require many contributors from several countries and decades; rate limits and duplicate detection apply; review is human. Many people over time can change it — that is the point.
How much can one memory change it?
Sheet 17: up to three dimensions, ±0.02 each, weighted by a confidence a reviewer assigns; one principle stance. In the Response Lab most single memories cross no phrase threshold at all; the Index says so honestly for each record.
Who interprets a memory's lesson?
The contributor writes it; a reviewer proposes the imprint; the contributor can appeal (sheet 21). In the prototype the reviewer is a labelled fixture rule.
What happens when memories conflict?
Both sides are kept and shown (sheet 19). Values move by the net, confidence reflects coverage, and the strongest memory on each side is listed.
Who approves rewritten principles?
An editor, after a public review period, with a rationale, keeping the previous wording (sheet 20). Never an algorithm, never a token. Open question: who appoints the editors, and how they are replaced.
Can a contributor appeal the interpretation?
Yes, once, to a second reviewer (sheet 21). Open question: whether an appeal can also be raised by a third party who believes an imprint misreads a memory.
What happens to derived state after deletion?
It is recomputed without the removed imprint, deterministically, and the removal is a recorded event (sheet 24). Earlier versions that included the memory remain reproducible from the record of what was accepted at the time. Open question: whether historical responses that cited a removed memory should be re-rendered or kept with a tombstone.
Can the behavior state be independently reproduced?
Yes for the prototype: the engine is a small deterministic function over public fixtures, and the tests replay it. For production the engine version and imprints must be published with each root (sheet 22).
Is the current character running, or is this a visual prototype?
A visual prototype. No model is running; every response is fixture text selected by state; every value is derived from demo imprints; the engine is Proposed. The site says so on every surface where a derived value appears.
Three states: Introduction, Demo, System
Ref G·1 · v7MEMENTO is delivered in three separate states. The visitor is told which one they are in at every point; fixture data is never passed off as live data.
- Manifesto
- The scroll narrative at
/: six scenes around the Memory Sphere, built on demo fixtures and labelled as such. Completing it is remembered for the tab (sessionStorage memento.intro).?stage=introreplays it. - Demo
?mode=demo. Seeded fixtures (287 records, imprints, versions) demonstrate the complete operating model. Every mutation is a local preview. The status chip reads Demo data.- System
?mode=system. Nothing is seeded. Records, adapters and deployment state come only fromwindow.MEMENTO_CONFIG(records source, submission adapter, market adapter, mind engine). With nothing configured the system is empty and the chip reads Not deployed. Submission controls are disabled until an adapter exists.
Fixture isolation
- The environment (
assets/env.js) is resolved before any other script and decides which data files load:fixtures-*.jsin Demo,system-*.js(empty core, no records, engine configuration only) in System. Fixture payloads are never requested on System routes. - Demo records never appear in System mode; System never silently falls back to Demo; a simulation (capacity v2, versions) cannot mutate the configured real state, which is frozen in the environment.
- Record identifiers, hashes, the deterministic address mapping and the capacity arithmetic (
3,690 = 90 × 41,9,630 = 90 × 107) are unchanged by the rename from the previous product name; internal digest salts keep their historical string so demo roots stay stable.
Transitions
- Introduction → Demo
- Show me how it works: the flattened field becomes the desktop without a reload and a guided tutorial starts on the real interface (seven chapters, BACK · NEXT · EXPLORE MYSELF · RESUME GUIDE; replayable from Settings). Or open the demo on your own skips the guide. Direct routes never force-start it.
- Demo → System
- Enter the system →, a separate control kept away from the dock and the windows (or Settings): the document reloads with
?mode=system, keeping the open application and record intent in the URL. The system opens on an onboarding state (The Memento · Start with a memory) that states its real status: record source not connected, submissions unavailable. - System → Demo
- Return to the demo, the same way.
- Deep links
?mode=…&app=…&tab=…&cell=…,?record=A-00261, and every legacy route (/index/,/submit/,/token/,/protocol/,?portal=1) resolve into the requested state without losing parameters.