---
name: chronicle-models
description: Design and refine journal data models for the Chronicle Android app, including codex entry types, mention characters, fields, relationships, filters, and completion states. Use when a user wants a Chronicle model for a campaign, work log, personal journal, or another domain. Produces a blueprint for the app's Model editor, not an AI model or an import file.
metadata:
  author: Chronicle
  version: "1.0"
---

# Chronicle models

Create a model the user can configure in [Chronicle for Android](https://chronicle.dev.baschen.is/en.html).
Use the user's language and domain vocabulary for labels and options.

## Delivery boundary

Chronicle's model is journal-owned data: entry types and their field definitions.
Codex entries are instances of those types; journal notes mention those entries.
The app supplies no domain-specific rules or calculations.

The supported workflow documented here is manual configuration in the **Model** screen.
There is currently no model file import/export or public model-writing API. Deliver a
readable blueprint and setup steps. If the user requests JSON or YAML, label it as a
design document, not an importable Chronicle format. Do not invent an import button,
file extension, API, database IDs, or internal mention markers.

This capability snapshot was checked on 2026-09-06. If the user supplies documentation
or app behavior from a newer version, reconcile it before relying on these limits.
The skill is self-contained and requires no access to Chronicle's private source.

## Design the vocabulary

1. Identify what the user writes about repeatedly and what they want to find later.
   Use supplied examples; ask only for missing context that materially changes the model.
   When the request is broad, propose a small usable starting point and state assumptions.
2. Make a type for things with their own identity, notes, or relationships, such as
   Person, Place, Project, or Quest. Make a field for an attribute of such a thing.
   Use a choice for a small fixed vocabulary, tags for multiple labels, and a reference
   when the value deserves its own codex entry.
3. Reuse the built-in entry name and notes. Do not add duplicate Name or Notes fields
   unless the user needs a distinct meaning. Keep happenings in the journal log unless
   they also need an independently tracked codex entry.
4. Select a few fields that answer the user's retrieval questions. Prefer short fields
   in list summaries and leave long detail in the entry. Avoid making every field a filter.
5. For an existing journal, preserve useful types, labels, triggers, and values. Explain
   changes separately from the final blueprint. Deleting a field loses its values;
   deleting a type also deletes its entries and fields. Do not use deletion as a rename
   or describe a field-kind change as an automatic data conversion.

## Entry types

Specify each type's singular label, plural label, mention character, icon, and **Can be
finished** setting, in the desired display order.

- Labels must be nonblank. Use distinct, recognizable labels.
- Each type claims exactly one unique character within its journal from this palette:
  `@ # ~ & % + = * $ ! ? / < > |`. This allows at most 15 types through the current picker.
  Existing types already occupy their characters. If more categories are needed, discuss
  consolidating similar types with a choice field rather than inventing more triggers.
- Icon keys in picker order: `person`, `group`, `place`, `item`, `quest`, `task`,
  `creature`, `vessel`, `spark`, `spell`, `project`, `meeting`, `decision`, `org`,
  `faction`, `lore`, `chapter`, `label`. Describe the visible symbol when useful.
  An icon is decorative; it does not enable domain behavior.
- **Can be finished** adds the app's built-in to-do/done state. Use it for tasks or quests
  that end. Finished entries sort below unfinished ones in their type and can be hidden
  with the completion filter. A custom CHECKBOX does not provide that behavior.
  Add a separate status CHOICE only when the user needs more than to-do/done; it does
  not synchronize with completion automatically.

## Fields

For each field, specify its label, kind, options or reference target where relevant,
**Filterable in the codex**, and **Show under the name**, in the desired field order.
The enum names below identify the kinds unambiguously; the app displays localized labels.

| Kind | Holds | Filterable? | Design guidance |
| --- | --- | --- | --- |
| TEXT | One line of text | No | Short free-form attributes. |
| LONG_TEXT | Several lines | No | Separate narrative detail; normally hide from summaries. |
| NUMBER | A numeric value, including decimals | No | Put units in the label; no formulas or range filters. |
| CHECKBOX | Yes/no | Yes | An independent flag such as Paid; blank and explicit no differ. |
| DATE | A calendar day | No | A due date or event date; no time-of-day or reminder behavior. |
| CHOICE | One declared option | Yes | Supply a useful, ordered, nonempty list of options. |
| TAGS | Multiple labels, including newly typed ones | Yes | Optional suggested options; not a closed multi-select vocabulary. |
| REFERENCE | One other codex entry | Yes | Restrict to one type, or explicitly choose Any type. |

Enter CHOICE and TAGS options one per line, without blanks or duplicates. Option order
is preserved for declared filter values. Only those two kinds have option lists.
Only REFERENCE has a target type. Create all types before adding their reference fields;
self-references such as Place → Located in → Place are supported.

A reference points to one entry in the same journal. It is not a list of entries and
does not create an automatic inverse field. For multiple participants, choose a
clearly described compromise such as several role-specific references, mentions in a
note, or a separate relationship type if those links need attributes of their own.
Do not substitute tags while claiming they retain entry identity.

Filter rows appear only when a filterable field has at least two distinct values in
use. Declaring options alone does not make the chips appear. Multiple selected values
within a field mean OR; selections across fields mean AND. TEXT, LONG_TEXT, NUMBER,
and DATE cannot be made chip filters. A populated checkbox set to no is a value;
an unfilled field is not equivalent to no.

The editor does not expose required-field enforcement, computed fields, arbitrary
validation rules, attachments, multi-entry references, or automation. If the user
needs one, identify the limitation and offer a supported approximation explicitly.

## Output and setup

Deliver a journal name and purpose, a type table, and a field table per type. Include
all settings above so the user need not guess defaults. Keep illustrative entries
separate from field definitions. End with a short setup sequence:

1. Open the intended journal's Model screen. For a new journal, choose Blank or an
   appropriate starter model. Starter models are copied into the journal; subsequent
   edits belong to that journal.
2. Create or adapt the types first, assigning their unique mention characters, icons,
   and completion settings. Then add fields, options, reference targets, and switches.
3. Create a few representative codex entries and fill their fields. In a journal note,
   type a configured mention character and select or create the intended entry using
   the mention picker. Plain example text such as `@Mira` is a typing illustration,
   not serialized data to import.
4. Check a relationship, a summary, and the user's main retrieval question. To exercise
   filter chips, populate at least two distinct values for the chosen field. Check
   completion only on a type configured as finishable.

Do not claim to have configured or tested the app when only a blueprint was produced.

## Compact example

For a small work journal tracking who owns each task and which project it belongs to:

| Type | Plural | Mention | Icon | Can be finished |
| --- | --- | --- | --- | --- |
| Person | People | @ | person | No |
| Project | Projects | # | project | No |
| Task | Tasks | ! | task | Yes |

Person and Project need only their built-in name and notes initially. Task fields:

| Field | Kind | Options / points at | Filterable | Show under the name |
| --- | --- | --- | --- | --- |
| Project | REFERENCE | Project | Yes | Yes |
| Owner | REFERENCE | Person | Yes | Yes |
| Due date | DATE | — | No | Yes |
| Priority | CHOICE | Low, Normal, High (enter one per line) | Yes | Yes |

Example entries: people Mira and Sam; project Website; tasks Draft homepage (Mira,
Website, High) and Review copy (Sam, Website, Normal). These allow Owner and Priority
chips to appear; the Project row needs another project value in use. Marking Draft
homepage finished exercises Task's completion state. Due date remains display data,
not a reminder or an overdue filter.

## Final check

- Every trigger is allowed and unique, including existing types.
- Every field uses one of the eight supported kinds and only its applicable settings.
- Every restricted reference resolves to a declared or existing type in the journal.
- Filter switches are enabled only for eligible kinds; examples explain when chips appear.
- Completion, option lists, and summary choices match the user's actual workflow.
- The deliverable is clearly a blueprint, with no invented import or automation promises.