HOWTO CHRONICLE

What Chronicle Is

Chronicle is for real-life memories. Every memory is tied to a date, a place, and your own account of what happened.

Chronicle is made for non-fiction personal history. It is not a social feed and it is not designed for viral content.

A few clear, factual memories are usually better than many vague ones.

If you are new, think of Chronicle as a private record of your life that can later connect into a timeline and story graph.

Core Building Blocks

These concepts appear throughout the product and understanding them early makes everything easier.

Memory -> Storyline -> Chronology (Visual Model)

This map shows how Chronicle organizes narrative data. Memory is the source of truth, storylines group memories, and chronology adds historical context.

Read the flow top-to-bottom. Individual memories sit at the top, grouped into storyline ribbons in the middle, then linked to chronology events at the bottom.

A key safety rule: this visual does not override permissions. Visibility is always enforced at memory level, even inside a storyline or chronology view.

Storyline primary event anchoring is contextual metadata only. It helps orient the narrative, but does not auto-grant access and does not silently force chronology links.

Visibility and Sharing Basics

Visibility decides who can read a memory after you publish it.

Restricted memories are permission-based. People cannot see them unless you add and save sharing permissions.

Drafts stay private until you publish.

Simple rule: choose the most private option that still fits who you want to share with.

Encryption and Passphrase

Chronicle separates account authentication from memory decryption so protected memories stay secure even if login factors change.

Protected memory text is never decrypted by the server for private/restricted browsing flows. Decryption happens on the client after your key is unlocked.

If you change passphrase settings, first open a few older protected memories to confirm unlock still works.

Keep your recovery phrase offline in a safe place. If both passphrase and recovery phrase are lost, protected-memory unlock may be impossible.

• Private and restricted memory text is encrypted.
• Public story text can still be encrypted while stored on the server.
• Titles, dates, locations, and tags stay searchable so navigation still works.
• Your encryption passphrase is separate from login by default.
• Your passphrase and recovery flow are required to unlock protected memories.

Email vs OAuth: Same Encryption Workflow

Both sign-in types use the same Chronicle encryption system. The difference is only how your account session is authenticated.

For Email users: login password authenticates your account. Encryption passphrase decrypts your private/restricted memory content.

For OAuth users: provider sign-in authenticates your account. Chronicle passphrase still controls protected-memory decryption.

For both: Recovery phrase is the backup route to restore passphrase access without re-encrypting all memory content from scratch.

Product rule: convenience is optional, security boundaries are explicit. Authentication and decryption are treated as separate controls.

Edit Window, Immutability, and Anchoring

After you publish, you get a short editing period (24 hours). After that, Chronicle locks the memory content to preserve historical accuracy.

The content lock is intentional. It prevents old memories from being silently rewritten later.

Simple rule: if you still expect major rewrites, keep the memory as a draft. Publish only when the core facts are ready to stay fixed after 24 hours.

Author Actions (After Edit Window)

After the edit window closes, Chronicle keeps a safer maintenance mode called Author Actions. This lets you improve organization quality without rewriting locked history.

When you click Save Author Actions, the backend runs a short sequence: validate request, save metadata updates, and recompute graph link candidates.

This is intentional: Chronicle lets you maintain discoverability and context quality over time, while still preserving the integrity of published memory content.

If you need major text rewrites, keep the memory as draft longer before publishing. Author Actions is for metadata maintenance, not narrative rewrites.

How Story Graph Matching Works

Connections are not random. Chronicle checks concrete signals (date, place, tags, and title similarity) and then suggests likely links.

Chronicle prioritizes tags first. Accurate tags usually lead to better connection suggestions.

Title similarity is a backup signal, not the main one.

In practice, better tags and consistent location names improve graph quality a lot.

• Event link: same date and same location.
• Location link: same location context.
• Subject link: overlapping topics, mostly based on shared tags/categories.
• Cycle prevention and access checks apply before manual links are saved.

How to Write for Better Connections

If your goal is to connect memories by subject or theme, writing quality and metadata quality matter equally.

Avoid using the same broad tag for every story (for example, tagging everything as just “life”). This creates noisy, low-quality matches.

If two memories should be linked by theme, make sure they share at least one specific tag.

• Use specific dates (or verify auto-filled date is accurate).
• Use consistent location naming (same city format across related stories).
• Use precise tags instead of broad placeholders.
• Keep title descriptive and factual.
• Prefer one memory per meaningful event moment.

Location and Map View Rules

Map view is designed for historical context and browsing, not precise private-address disclosure.

Map view is for context and discovery, not exact address tracking.

If a story is missing from the map, first check location validity and visibility permissions.

• If you type a landmark, Chronicle may convert it to a city-level location for consistency.
• Stories appear where location resolution is valid.
• Consistent location naming improves cluster quality in map and graph.

Shared Memories and Infinite Scroll Behavior

Shared Memories list/grid uses incremental loading to keep the interface responsive for large datasets.

If loading feels slow, reduce filters and try list view.

Infinite scroll is used only in list and grid modes.

• New cards load as you approach bottom of current results.
• Filters and sorting determine what loads next.
• When there are no more stories, loading stops and the list stays as-is.

Building a Storyline Across Multiple Memoirs

A strong storyline is a curated sequence, not a pile of loosely related memories.

A good storyline usually has three parts: setup, turning point, and consequence.

Even if some entries are private and others are shared, you can still keep a coherent storyline.

• Start with the anchor memory that defines the central event.
• Add before/after memories around the same people/themes.
• Reuse consistent tags across the sequence.
• Keep chronological order accurate.
• Review and confirm suggested links.

Chronology: Purpose, User Value, and Internal Logic

Chronology connects personal memories to broader events to preserve context across time.

Chronology helps explain why a personal moment mattered, not only when it happened.

Internal high-level logic: chronology matching uses date overlap, region/location relevance, topic hints, and moderation state.

Chronology adds context around your memory. It does not rewrite your text or change your meaning.

Suggesting New Chronology Events

If the relevant historical event does not exist, users can submit a proposal for moderation.

Strong submissions are specific and clearly scoped. Vague submissions are slower to review and more likely to be rejected.

Once approved, events can be used for chronology links.

• Provide clear event title and date window.
• Provide region/context description.
• Explain why the event is historically significant.
• Submit and track moderation outcome.

Admin Review and Approval Flows

Admin moderation keeps chronology quality high while preserving privacy boundaries.

Moderation here means quality control. The goal is consistency, relevance, and user trust in chronology outcomes.

Private memory handling follows stricter visibility constraints than restricted or public memories.

• Review pending chronology connections and submissions.
• Approve/reject with notes where appropriate.
• Enable or disable rollout controls through feature flags.
• Respect privacy policy boundaries during moderation workflows.

Tiered Features

Some capabilities are enabled only for specific tiers and are controlled by admin feature flags.

Tier-based rollout lets Chronicle release advanced features gradually and safely.

If a feature is not available for your tier, the interface may hide that control. This is expected.

• Tier controls are explicit and auditable.
• Feature flags can target specific tiers.
• Feature rollout can be expanded step-by-step after validation.

Best Practices for High-Quality Memoirs

Quality memoirs are clear, specific, and anchored. They read better and connect better.

• Write concrete moments, not abstract summaries.
• Name real context (date, place, people, outcome).
• Use tags that clearly describe the subject.
• Use one memory per meaningful unit of experience.
• Publish when you are comfortable that the core facts should stay fixed after 24 hours.
• Use drafts for refinement. Quick Capture draft cap is currently 10 per user.

Common Mistakes and How to Avoid Them

Most connection issues come from metadata quality, not system failure.

Quick FAQ

Short answers for frequent questions from first-time users.

• Can I keep memories private forever? Yes, with private visibility.
• Can I share with only specific people? Yes, use restricted visibility and grants.
• Why did two stories not connect? Usually tag/date/location mismatch.
• Can chronology be user-extended? Yes, via event submission and moderation.
• Is everything public if I publish one story? No. Visibility is per story.