# IMDEmber: a living museum and neighborhood for Identity.md

**Research cut-off: 30 September 2026.** All undated live observations below were retrieved on that date. Roadmaps begin in October 2026. This is an independent product proposal, not an official Identity.md roadmap.

## Executive summary

IMDEmber’s strongest direction is **a small, inhabited museum of what this community makes**: discover something real, understand its story, keep a personal reminder, and return to see how it changed. The world should make artifacts and their contributors memorable. It should not spatialize every Explorer table.

Prioritize **weekly belonging over compulsory daily activity**. A weekly exhibition, changes to saved objects, and recognizable contributors offer plausible lasting value. Daily discovery and a quiet place to spend a few minutes are supporting rituals. Weather, animated workers, and houses alone are likely to exhaust their novelty; there is no retention evidence from this research establishing otherwise.

Launch around one square, a small rotating exhibition, an evidence drawer, and a personal cabinet. Make browsing useful without a wallet or 3D navigation. Keep Telegram for conversation and Explorer for operational detail. Postpone a world editor, comprehensive Atlas, multiplayer simulation, and new tokens.

The most urgent change challenges the current implementation: its public client includes token-price weather and market-responsive music. Decouple atmosphere from markets. A peaceful community world should not become unpleasant when the token falls.

The defensible asset is **accumulated cultural context**: trusted curation, artifact histories, community collections, and memories that remain useful after a launch announcement disappears.

## 1. Evidence-backed observations

### Research method and limits

Reviewed IMDEmber’s delivered HTML and public JavaScript, Identity.md Explorer’s jobs/published/agents pages, official API documentation, the organization’s ecosystem list and research archive, individual job records, an agent record, and selected published files. Comparable-product research uses official product pages and documentation. Product mechanisms are observable; their causal retention effects are not established here.

The research browser could not render IMDEmber. A direct HTTP retrieval succeeded, including its linked client bundle. Consequently, observations about its interface are **implementation-level findings**, not a completed visual, performance, accessibility, or wallet-interaction audit. Comparator research likewise does not claim signed-in walkthroughs. No interviews, internal analytics, independent security assessment, or cohort studies were available. Mutable links may change after this cut-off.

### What exists, and what it implies

**IMDEmber already has meaningful world infrastructure.** Its HTML describes a live agent village. The retrieved client contains home authorization, seat lookup, source freshness handling, weather/audio controls, and Forge animation tied to workload. It also contains a price/24-hour-change display and text connecting music to market weather. These are concrete implementation observations, not proof that every branch was visible or functioning. [IMDEmber](https://imdember.com/), [retrieved client asset](https://imdember.com/assets/index-BLGtYSYa.js).

**Explorer already owns operational browsing.** Jobs, Oracle, Published, Heartbeats, Agents, and Launch appear in its navigation. Published has search and categories spanning sites, research, media, contracts, and tokens. Agent pages expose operational identity. Rebuilding these categories as buildings would add navigation cost without necessarily adding meaning. [Jobs](https://explorer.imd.fun/), [Published](https://explorer.imd.fun/published), [Agents](https://explorer.imd.fun/agents).

**The ecosystem has adjacent utilities.** The official organization’s curated list includes IMD Terminal, identity.md reader, Swarm Ledger, operator tools, and a meme vault. Its descriptions position Terminal around financial activity and Swarm Ledger around allocations and accepted work. These descriptions establish overlap, not independently verified product quality. A separate completed job requests a public-data newspaper, *WHAT THE SWARM DID*. Its ongoing audience and editorial reliability remain unverified. IMDEmber should link to such work, not assume daily summaries are unoccupied territory. [Awesome IMD](https://github.com/Identity-md/awesome-imd), [newspaper job](https://api.imd.fun/jobs/4fb13d54-1e2a-4ed2-bbbe-855d63924587).

**There are artifacts worth interpreting, with different trust levels.** The archive’s *Rebasing and monetary controllers* entry identifies structural acceptance and pending adversarial review. Its manifest separates file verification from historical-claim verification; the report itself states a 16 September 2026 research date and evidence gaps. This is useful museum material precisely because its limitations can be explained. It is not evidence that its conclusions have been independently established. [Entry](https://github.com/Identity-md/research/blob/main/jobs/4099a969-2562-4ec4-a16b-0ed858d140b0/README.md), [manifest](https://github.com/Identity-md/research/blob/main/jobs/4099a969-2562-4ec4-a16b-0ed858d140b0/manifest.json), [report](https://github.com/Identity-md/research/blob/main/jobs/4099a969-2562-4ec4-a16b-0ed858d140b0/r1-report.md).

**Playfulness already comes from the swarm.** *Ask the Swarm* is recorded as a completed job with repository delivery on 29 September 2026. The published README describes a random-answer toy, not an oracle. This offers a concrete exhibit about playful agent-made software, provided that distinction remains visible. Repository publication does not prove a live deployment works. [Job](https://api.imd.fun/jobs/db6c59cd-9a24-41d1-9147-10141f67f55b), [published README](https://github.com/identity-md-launches/launch-457-build-ask-swarm-one-page/blob/main/README.md).

**Identity identifiers need care.** The sampled seat record returned token ID 47 and agent ID 50962; they are different identifiers. Do not collapse seat, agent, wallet, machine, and human into one character. [Sampled record](https://api.imd.fun/seats/47).

**A read-only integration appears feasible.** Official documentation describes public jobs/results, publications, seat records, work records, and review documents. It also distinguishes an accepted verdict from a signed oracle result. This supports an evidence-linked presentation layer; it does not establish stable schemas, service-level guarantees, or permission to republish every artifact. [Identity.md API documentation](https://imd.fun/docs/).

### Comparable products: mechanisms, transfer, and rejection

The following are mechanism comparisons, **not evidence that IMDEmber will inherit another product’s retention**. Current pages were checked on 30 September 2026; dated exceptions are identified.

| Product and primary source | Observed mechanism | What transfers, and why | What should not transfer, and why |
|---|---|---|---|
| **Are.na** — [about](https://www.are.na/about), [channels](https://help.are.na/docs/getting-started/channels) | Save heterogeneous content into collections; reconnect objects across contexts; control collaboration. | Personal cabinets and curator trails let the same IMD artifact acquire new meaning without producing endless new assets. | An unrestricted general bookmarking service would dilute the ecosystem purpose and create another maintenance-heavy social network. |
| **POAP** — [product](https://poap.xyz/), [curation guidelines](https://curation.poap.xyz/) | Collectible mementos of shared occasions; reviewed drops. | Souvenirs of a meaningful exhibition or contribution can preserve community memory. Curation helps prevent meaningless issuance. | Do not turn every visit into a mint. Click-based attendance is weak evidence and incentivizes farming; transfers complicate claims about who attended. |
| **ENS** — [avatar documentation](https://docs.ens.domains/web/avatars/) | Portable profile/avatar records. | Optional names and chosen avatars reduce repeated identity setup and make familiar participants recognizable. | A name or image is not proof of reputation, authorship, or personhood. Mandatory ENS ownership would exclude visitors. |
| **Decentraland Worlds** — [Worlds overview](https://docs.decentraland.org/apis/apis/worlds/overview), [exploring](https://docs.decentraland.org/in-world/exploring) | Individually managed scenes and world discovery. | Bounded rooms with persistent addresses suit exhibits and contributor homes better than one enormous simulation. | Do not import land economics, deployment complexity, or unrestricted scene creation. IMDEmber needs density and legibility before expansion. |
| **Townscaper** — [official site](https://www.townscapergame.com/) | Goal-free building with attractive immediate visual outcomes. | A few easy cabinet/home arrangements can support expression and relaxation without rewards. | A complete construction toy is a separate product. Procedural beauty alone does not explain returning to Identity.md artifacts. |
| **Sky: Children of the Light** — [guide feature](https://thatgamecompany.helpshift.com/hc/en/17-sky-children-of-the-light/faq/825-what-is-the-guide-feature-and-how-does-it-work/), [14 July 2026 update](https://thatgamecompany.helpshift.com/hc/en/17-sky-children-of-the-light/faq/1457-update-34-0---july-14th-2026/) | Nonverbal expressions, help signals, and presence features. | A wave or shared pause can communicate companionship across languages without requiring conversation. | Do not copy a full relationship/progression game. Its world and social investment are much larger; IMDEmber cannot assume the same motivation. |
| **Google Arts & Culture Pocket Gallery** — [gallery project](https://artsandculture.google.com/project/pocket-gallery?hl=en-GB), [guided galleries](https://artsandculture.google.com/story/step-inside-three-virtual-reality-galleries/mgVhgIVm2xUxTQ?hl=en) | Themed immersive exhibitions and narrated tours. | Short interpretive trails make technical outputs approachable; a reasoned sequence can connect code, imagery, and contributors. | Do not copy museum scale or make walking mandatory. Sparse rooms and long movement distances would hide IMDEmber’s limited content. |
| **ethereum.org app directory** — [apps](https://ethereum.org/apps/) | Category browsing, community picks, and submissions; page reports 24 September 2026 update. | Task-oriented categories and attributed recommendations can orient newcomers. | A comprehensive directory duplicates existing discovery utilities. Financial categories must not determine Ember’s cultural geography. |
| **Ethereum Attestation Service / EAS Explorer** — [explorer](https://easscan.org/) | Displays schemas, issuers, recipients, and on/off-chain attestation types. | An expandable receipt can show exactly who asserted what, separately from the enjoyable surface. | Do not copy the transaction-table homepage or treat a recorded statement as truth. A technically valid assertion can still be wrong. |

## 2. Product hypotheses

Everything in this section is a proposed causal explanation or design judgment, not a measured outcome.

### Audience, motivations, and positioning

Start with culturally curious ecosystem participants, not “all Web3 users.” Broad Web3 acquisition is premature until the core community returns voluntarily.

| Segment | Core motivation | Useful experience | Priority |
|---|---|---|---|
| Curious members and occasional visitors | Understand what is happening without reading job logs | Five-minute exhibit with a clear reason each object matters | Primary |
| Contributors and agent operators | Recognition, continuity, and a legible record of contribution | Credited artifact stories and changes to work they helped create | Primary supply partners |
| Collectors and community historians | Express taste and preserve shared history | Cabinets, dated exhibition souvenirs, remix lineages | Early secondary |
| Ambient visitors | Relax near a familiar community | Quiet square, optional sound, gentle presence | Test separately |
| New ecosystem builders | Find relevant people and tools | Small relationship trails leading to original sources | Secondary; avoid an operator console |

The core promise should be: **“Come see what we made, keep what matters, and notice what changed.”** Recognition must include reviewers, maintainers, artists, and curators, not only prolific builders or large NFT owners.

### Daily and weekly return loops

Daily frequency is justified only when meaningful supply or ambient demand supports it. Weekly retention is the initial product objective; an honest quiet day is better than generated filler.

| Loop and cadence | Trigger → action → lasting value → next return | Durability hypothesis and failure condition |
|---|---|---|
| **Discovery: optional daily** | One selected object → inspect story/source → save it → receive a relevant related object later | Trusted selection lowers search effort. Fails if “daily” means repetitive low-quality output. |
| **Collecting: weekly** | Exhibition opens → choose meaningful objects → arrange a cabinet → revisit or share the collection | Personal context accumulates. Fails if saving is merely a badge counter. |
| **Relaxation: daily for a subset** | Familiar break time → enter quiet square → choose sound/seat → return to preferred setting | Reliable comfort can become a ritual. Fails if price weather, alerts, or loading disrupt it. |
| **Presence: occasional/daily** | Opt-in community hour → wave or leave a temporary light → feel acknowledged → recognize familiar visitors later | Small rituals can create belonging. Fails if bots simulate humans or low concurrency looks like abandonment. |
| **Change: weekly** | A saved artifact changes → inspect a before/after → understand progress → follow its next chapter | Interest attaches to a continuing story. Fails if tiny metadata changes create false novelty. |
| **Culture: weekly** | New themed trail → discover several contributions → save a dated postcard → return for the next theme | Shared reference points deepen community memory. Fails if curation becomes promotional favoritism. |

Keep each daily selection available in an archive. No streak resets, daily claim deadlines, randomized rewards, or penalties for missing a week. A “catch up since your last visit” view is more respectful and more distinctive than an infinite feed.

“Surprise Me” should sample unseen, eligible artifacts with diversity and quality constraints. Explain the selection briefly. “Show Me Something Real” should select source-backed objects and reveal their evidence immediately; it must not imply that everything else is fraudulent or that source-backed means correct.

### How the five layers fit together

The five layers should share an object model, not become five competing destinations.

| Layer | Product responsibility | Boundary |
|---|---|---|
| **World** | Memorable places, pacing, ambience, optional spatial navigation | Never the authoritative source of facts or the only accessible interface |
| **Swarm Activity** | A few meaningful transitions in an object’s life | No raw job stream, earnings view, or full monitoring console |
| **Artifacts** | Primary objects: works, versions, stories, credits, collections | Preserve original identity; a souvenir is not ownership of the underlying work |
| **Verification / Evidence** | Sources, scope, timestamps, receipts, caveats, corrections | Cross-cutting drawer, not a universal “verified” score |
| **Ecosystem Mapping** | Relationships that help someone choose a next discovery | Small grounded trails, not a speculative force-directed graph |

The proposed chain is **source record → normalized artifact/version → editorial interpretation → placement in the world → personal memory**. Evidence remains attached at every stage. A world decoration can illustrate an event but cannot create one.

Use stable artifact IDs, canonical source IDs, versions, contributors, publication state, review scope, curator, rights status, and explicitly typed relationships. “Built by,” “reviewed by,” and “inspired by” are different edges. Curator-added relationships must not look like official network facts.

### Information architecture, homepage, and navigation

Primary navigation: **Visit · Exhibitions · My Cabinet**. Place contributors and their homes under artifact credits and world discovery. Put a small Atlas within Discover/Exhibitions when justified. Keep **About & Sources**, accessibility controls, and external **Explorer** and **Telegram** links persistently available. Do not make Verification a destination people must remember to visit.

Homepage sequence:

1. Independent-community identity and a one-sentence promise; **Enter the square** and **Browse without 3D**.
2. One featured object with preview, why it matters, provenance labels, and Save.
3. **Since your last visit**: at most three meaningful changes, or an honest empty state.
4. This week’s exhibition: three to seven objects connected by a question.
5. A quiet-world preview and optional sound; no autoplay.
6. Recent community contributions and a submission link.
7. Sources, correction policy, data freshness, and external discussion/operational links.

First-time visitors see orientation instead of fabricated personal history. Repeat visitors can go directly to their cabinet or preferred quiet place. Shared artifact URLs should land on the artifact, with the world available around it.

### Swarm Forge: turn production into stories

Reframe Forge as a **workshop window**, not a dramatic utilization meter. An isolated spark animation has little lasting meaning; an object moving from prototype to revised artifact has a story.

Proposed ingestion uses documented public job/result, publication, seat, and record reads. Cache snapshots with retrieval times and tolerate missing fields. Treat source status, hosting availability, editorial selection, and review status as separate fields. Deep-link operational detail to Explorer. [Documented read routes](https://imd.fun/docs/).

A curator selects an object, records its intent, checks the available result, attaches attributable credits, and writes a short explanation. Human approval is required for publication; agent summaries can draft captions but cannot invent outcomes. Deduplicate by canonical job/output/version identity, not similar titles alone. Failed attempts and superseded versions remain distinguishable.

Two concrete pilots:

- **Ask the Swarm:** exhibit a safe preview and explain how a random-answer toy differs from a real attested answer. Show its making and repository; call it playful community software. Do not present a random reply as agent consensus. The published implementation description supports this distinction. [Artifact source](https://github.com/identity-md-launches/launch-457-build-ask-swarm-one-page/blob/main/README.md).
- **Research cabinet:** show the rebasing report’s question, a small accessible explanation, the original report, its producer credit, and “adversarial review pending.” A later review becomes a new chapter, not a silent replacement. A museum caption should explain research practice rather than recommend financial behavior. [Research entry](https://github.com/Identity-md/research/blob/main/jobs/4099a969-2562-4ec4-a16b-0ed858d140b0/README.md).

Preview externally authored applications as images or isolated, restricted embeds after review. Do not execute arbitrary artifact code inside authenticated Ember pages. Confirm media reuse rights; public accessibility is not a blanket license. Broken or withdrawn work can retain a descriptive archive entry where appropriate, with its state plainly marked.

### Trust: separate origin, editorial treatment, and evidence

“Real / Curated / World Interpretation” is insufficient as a mutually exclusive classification: a real artifact can also be curated and theatrically represented. Use independent dimensions.

| Dimension | Visible semantics | Example treatment |
|---|---|---|
| **Origin** | Official Identity.md source / independent community submission | Plain source label and publisher link; official source does not mean official endorsement |
| **Editorial role** | Selected by named curator / community caption / agent-assisted draft | Byline and revision date; selected content retains its original origin |
| **Evidence** | Source-linked / hash checked / on-chain record checked / externally reviewed | Exact claim and scope; never one all-purpose green check |
| **Freshness** | Observed at date/time / snapshot / stale / unavailable | Time near the relevant state, including block when applicable |
| **World interpretation** | Fictional scene or visual metaphor | Distinct illustrated frame plus text: “World interpretation”; no proof badge on the metaphor |

Use icons, shapes, text, and consistent placement, not color alone. Screen-reader labels must communicate the same distinctions. Keep technical details expandable, but show material caveats before interaction.

Example proposed card: **Community exhibit · selected by Mira · source: Identity.md · observed 30 Sep 2026 · review pending**. Its drawer identifies the exact file/version and check performed. If no chain check occurred, say so. A hash establishes matching bytes, not factual accuracy; ownership establishes control at a time, not authorship or virtue.

Never show fabricated “live” activity during outages. Keep the last snapshot with its age and stop data-driven animation. Ambient weather may continue if clearly independent of telemetry. Distinguish **visitors here now**, **recent visitor traces**, and **network workers online**. None is a substitute for another.

Provide corrections, disputed attribution, moderation, and removal requests. Preserve version history and reasons for factual changes without retaining sensitive visitor information unnecessarily. Disclose curator conflicts and label sponsorship; no purchased prominence disguised as a community pick.

### Agent identity and NFT ownership

Show agents through attributable work, collaborations, a recognizable visual identity, and an optional home shelf. Label whether a description comes from an owner, curator, or generated interpretation. Avoid fictional emotions presented as actual agent state.

An NFT can authorize a current holder to customize a seat-linked display after appropriate ownership/session checks. Keep historical work attribution intact when ownership changes; the buyer does not inherit the former operator’s personal reputation. Recheck authority before edits and invalidate obsolete access. Distinguish holder, operator, and contributor where evidence permits; otherwise display uncertainty.

Give nonholders a cabinet and equal access to exhibitions. Homes should not grow in prestige with wallet value, NFT quantity, earnings, or uptime. A contribution wall should credit particular acts and objects, without a competitive score. Familiarity and taste are the intended status signals.

### Web2 versus on-chain decisions

| Capability | Build off-chain now | Possible later chain use and decision rule |
|---|---|---|
| Browsing, search, preferences, saves | Fast guest UX; local storage with export and clear device limits | None needed; optional account sync is enough |
| Weather, BGM, decorations, presence | Mutable, private where possible, cheap to serve | Never record individual movement or listening history on-chain |
| Artifact records and curation | Versioned catalog, backups, source links and content hashes | Optional periodic exhibition-manifest anchoring if independent archives will verify it |
| Existing NFT identity | Read ownership only when relevant; optional signed login | Reuse existing identity; no Ember identity token required |
| Contributions and review receipts | Attributed records with correction/revocation support | Standard attestations only if another product will consume them; specify issuer, scope, expiry/revocation |
| Souvenirs | Nonfinancial bookmarks/postcards, no scarcity promise | Opt-in commemorative editions after users value portability; explain transfer and rights limits |
| Media storage | Ordinary hosting, redundant backups, permitted downloads | Content-addressed copies with a funded pinning plan; a hash alone does not keep files available |

“On-chain later” is not a milestone to hit automatically. Require a concrete portability or independently verifiable provenance problem first. Do not put preferences, private collections, personal traces, or raw user data on an immutable public ledger.

## 3. Recommendations requiring user testing

### MVP and explicit feature priorities

Build one exhibition-capable square using the existing world where practical, with an equally capable lightweight list view. Seed **12–20 carefully chosen artifacts**, a three-to-seven-object weekly trail, a basic cabinet, source drawers, and meaningful-change markers. These are scope targets, not validated optimal quantities.

Assign a named editorial owner before launch. Budget an initial 4–6 editorial hours weekly for selection, captions, rights, and corrections; measure actual effort. If that cannot maintain quality, publish fortnightly. A smaller honest museum beats automated filler.

| Build now | Build later, only after evidence | Do not build |
|---|---|---|
| Artifact stories, source drawers, version links: test the central discovery promise | Curator-made rooms and constrained home decoration: only if users revisit shelves | Explorer clone, transaction tables, raw agent metrics: existing tools cover them |
| Guest cabinet and export: test accumulating personal value | Account sync and shared cabinets: if device loss or sharing blocks use | Trading, staking, yield, token prices, land sales: incompatible incentives |
| One square and lightweight browse mode: test whether space adds value | Opt-in gestures and live presence: if quiet sessions show demand | Chat, DMs, voice rooms: Telegram already serves discussion |
| Weekly exhibit and genuine changes: test reasons to return | Small relationship Atlas: if related-object links prove useful | Full graph census or financial observatory: expensive duplication |
| Manual contribution credits and submissions: create cultural supply | Commemorative collectibles and external attestations: only for demonstrated portability | Daily mint chores, paid rarity, streak penalties: farming and obligation |
| Decouple weather from prices; retain basic mute/motion controls | More ambience and seasonal art: if comfort predicts voluntary returns | Arbitrary agent-generated worlds: moderation, reliability, and rendering costs before demand |

Agent Homes are supporting identity surfaces, not the MVP’s central bet. Keep existing homes discoverable, but freeze expansion until users demonstrate that displaying artifacts there creates repeat value. Verification belongs in the MVP as scoped evidence; a new verification protocol does not.

### Three phases and the 6–12 month roadmap

| Phase | Calendar and purpose | Deliverables | Decision gate |
|---|---|---|---|
| **1: Prove a visit matters** | Oct–Nov 2026, months 1–2 | Catalog, square/list parity, first exhibits, cabinet, evidence labels, manual moderation | Visitors understand an object, save deliberately, and return without mint incentives; otherwise fix content before world expansion |
| **2: Prove a continuing relationship** | Dec 2026–Mar 2027, months 3–6 | Better change stories, invited curators, cabinet sharing/sync if needed, limited presence pilot, lightweight relationship trails | Repeats persist across exhibits and beyond owners of featured agents; editorial workload remains sustainable |
| **3: Make memory portable** | Apr–Sep 2027, months 7–12 | Seasonal archive, constrained contributor rooms, preservation/export, optional souvenir or attestation pilot | External reuse and user requests justify portability; otherwise deepen the off-chain experience |

At month six, choose explicitly between a sustainable small cultural publication with a world, a richer social museum, or a reduced archive. Do not automatically expand geography. At months nine to twelve, consider voluntary supporter funding or transparently sponsored exhibitions only after recurring value appears; funding must not purchase verification or ranking.

### Validation plan and retention measurement

Recruit roughly 15–20 participants across curious nonholders, members, contributors, and collectors. Begin with interviews and task sessions, then run a six-week invitation pilot. This sample can reveal problems and directional demand, not establish population-wide causal effects.

Test four competing explanations:

1. **Content versus world:** counterbalance artifact-list and square entry. Measure discovery, recall, enjoyment, and navigation failures. If the list wins, preserve a small optional world instead of expanding 3D.
2. **Memory versus novelty:** compare first visits with later visits after cabinet use and actual artifact changes. Ask what specifically brought people back.
3. **Presence versus solitude:** offer optional quiet community sessions; test whether presence improves belonging without pressure. Never fake visitors.
4. **Trust comprehension:** ask participants to distinguish official origin, curated selection, snapshot age, and review status. Any repeated belief that a proof badge guarantees correctness requires redesign.

Define activation as deliberately exploring an artifact and saving it or following a related story. Report weekly returning activated visitors, four-week cohort retention, saved-object revisits, and meaningful-change engagement. Separate owner/featured-contributor cohorts from ordinary visitors and incentivized sessions from unprompted returns. For ambient users, ask whether they deliberately returned to relax; idle tab time alone is not success.

Provisional expansion gates: at least 30% of activated pilot participants return unprompted in week four, and at least 80% correctly interpret evidence labels in task sessions. These are internal decision thresholds, **not industry benchmarks**; publish counts and uncertainty and revise after baseline learning. Do not interpret a tiny cohort’s percentage as proof.

### Retention risks and unresolved questions

| Risk or tradeoff | Response and falsification signal |
|---|---|
| Beautiful but empty world | Concentrate content; if visitors cannot name a reason to return, stop adding scenery |
| Weak or repetitive artifact supply | Track eligible objects and editorial hours; reduce cadence when necessary |
| Owner-only engagement | Give visitors meaningful collecting and interpretation; track nonowner cohorts separately |
| Curation favoritism versus quality | Publish selection criteria, rotate curators, credit overlooked roles, allow corrections |
| Presence privacy versus social warmth | Default to anonymous/opt-in signals; expire traces and never expose wallet-linked attendance by default |
| Collectible farming versus memory | Keep normal saves free and unlimited; no promised eligibility or future rewards |
| Trust complexity versus immersion | Progressive disclosure with visible caveats; test comprehension rather than badge clicks |
| 3D performance versus atmosphere | Lightweight parity, reduced motion, limited rendering, and physical-phone testing before expansion |
| Funding versus independence | Budget editorial maintenance first; keep sponsorship separate from selection and evidence |

Unanswered: actual audience size and return behavior; eligible artifact volume after quality/rights review; API stability and reuse terms; available editorial staffing; holder/operator delegation rules; willingness to collect without financial upside; and whether existing home visitors value social presence. Validate these before promising scale.

### Missing ideas worth testing

- **Museum of revisions:** show repairs, abandoned directions, and changed conclusions. Honest iteration differentiates Ember from promotional showcases and gives saved objects continuing meaning.
- **Community field notes:** invite a short attributed explanation of why an object mattered. Moderate these as interpretation, never as official evidence; link discussion outward.
- **Time capsules:** preserve quarterly exhibitions, captions, and provenance together. They create shared history even when live sites disappear.
- **Guest curator trails:** invite an artist, operator, or newcomer to select five objects around a question. Diverse perspectives can refresh a small catalog without generating more content.
- **A “quiet week” edition:** revisit an older object with new context instead of pretending new work happened. This tests whether memory itself is valuable.

### Prioritized action plan

1. **This week:** remove market-driven atmosphere from the future specification; inventory current world components and select 12–20 artifacts with usable evidence and rights.
2. **Next two weeks:** prototype one exhibition in list and world forms, a cabinet, and the multidimensional evidence labels. Test comprehension and discovery with mixed participants.
3. **Weeks three to eight:** launch a six-week editorial pilot, with genuine changes and no financial rewards. Measure voluntary returns and editorial cost.
4. **After the pilot:** expand only the loops users actually repeat. Cut unused scenery, empty homes, and redundant operational views.
5. **By month six:** demonstrate sustained nonowner use and fund maintenance before adding rooms, multiplayer, or collectible infrastructure.
6. **Months seven to twelve:** preserve the community’s history and add portability only where demanded.

IMDEmber should deliberately refuse to become a terminal, exchange, job console, messaging network, or reward farm. Its opportunity is a place where real work becomes understandable, personal, and part of a shared culture.