The field guide

Unicron is a Mac app that stores your notes in a vault, a folder of plain Markdown files with no database. Every note is a file, and every link between notes is called an edge. Each note has a type and is checked against a schema, the rules that define note types and their relationships. Together, these form a knowledge graph that the app can read, use to work out relationships, and display as a map you can browse and search.

Start by pasting a meeting transcript, writing a thought, or adding something to the inbox. Claude Code runs on your Mac and organizes that input into a note with a type and a place in the vault. It identifies the note's area, project, and people. The app uses that information to build the graph's connections for you to review and confirm.

This guide explains how the vault organizes information, how the app finds relationships, and what's planned. It grows with the app, with status badges to show which features are available and which are still in development.

The guide uses these four terms to describe the knowledge graph:

• T-Box (terminological) is the schema. It defines the kinds of notes and the links allowed between them in ontology.md.
• A-Box (assertional) is the set of assertions: your notes and the links between them.
• Predicate is the type of relationship a link represents, such as belongsTo, involves, or mentions.
• Provenance records where a fact came from and how certain it is. For example, it distinguishes a link you wrote from one the app worked out.

The vault contains two kinds of graphs.

The entity graph shows what exists: areas, projects, people, and meetings. Its connections show what belongs where and which notes mention each other.

The process graph shows what happens and what leads to what. The Decisions feature uses it to connect a decision with its steps and outcome. This follows PROV-O, the Provenance Ontology, a web standard that describes Agents, Activities, and Entities. The standard applies beyond personal note collections.

A plan can be described using PROV-O, the web standard for recording where information came from:

• An Agent acts or makes decisions, such as you or Claude working for you.
• Activities are the steps taken.
• Entities are the things those steps act on.
• The Outcome is the result.

The app can record facts such as who performed a step and what it produced. It can also check that an outcome followed a plan. Only you should confirm that the plan caused the outcome. A decision's leadsTo connection stays dotted and proposed until you confirm that claim.

The graph records your planning and where its information came from. The app records the facts it can verify and asks you to confirm claims about cause and effect.

The app combines Claude's suggestions with rule checks and your review:

• Neuro: Claude reads your notes and suggests how to organize them. It can find many possible connections, but some may be wrong.
• Symbolic: The ontology and its rules check each suggestion and store it with its provenance. This part applies defined rules without inventing facts.
• You: Review and confirm the suggestions. Confirmed facts inform the next round.

Triage follows this process: Claude suggests where an inbox item belongs, and you confirm it. The same process applies to relationships between notes.

Inferred and proposed facts must remain possible to recalculate and must never be edited by hand. Editing an inferred connection as though you wrote it makes it impossible for the system to distinguish an inference from an authored fact.

Every note declares a type. The Graph view gives each type a color. In the app, the note-type legend reads directly from your vault's ontology.md and shows your current schema.

Notes in raw/ have no type yet. They are quick captures waiting for triage and are not part of the graph.

Notes connect through named relationships called predicates. The app derives each relationship from a frontmatter field (a field at the top of a note), a folder, or a link you wrote. Provenance records whether you authored the connection by typing a link or the app inferred it from the note's structure. In the app, the relationships table reads directly from ontology.md.

The app reads the rules in ontology.md and flags notes that do not follow them. These checks are advisory: they do not block actions or edit your notes. The results appear in the app's Field Guide.

The app checks every note against the rules. A broken reference appears in red: a project: or area: identifier that points to a missing note. Less serious issues appear in amber, such as a project with no area, an area missing from your profile's ## Areas list, or an unfamiliar kind or status.

Most issues have a picker you can use to set the field. Others open the note for you to edit. For example, adding a missing area to your profile requires editing its text. These checks never change files on their own.

To add a note, click Add (the + in the top bar) or press ⌘N. Choose Meeting, Project, Person, Area, Decision, Journal, or a quick Task, then paste or type your text. Claude Code creates a note with the right type and saves it in the right folder. For meetings, you can paste the full transcript. Claude identifies the people who attended, updates their notes, and files the meeting under its area.

Text you paste or send from your phone or a Shortcut goes into the inbox without a note type. Run Triage to have Claude read each item, choose its type, and file it in the right place. You review the result. The top bar shows when the inbox has items waiting.

The top bar has five views: Today (your daily summary), Tasks, Library, Graph, and Chat. The Library lists all your notes, with type filters in the left sidebar. Click a type to show only that type, or ⌘-click to combine types. Open an area or project to see its contents.

Press ⇧⌘J to find any note by name, or / to filter the current list. Chat uses your notes to answer questions and can edit them when you ask. It can also sort your inbox or create a project. Changes appear in review cards in the conversation, and you can press ⌘Z to undo them.

Notes open in preview. Press ⌘E or click the pencil to edit. Type @ followed by a name to link to a person; the app fills in the path. Type / to open the formatting and blocks menu. You can edit tables cell by cell and use the row and column controls. When you save, the app reads the note again to update the graph.

Diagrams. A fenced mermaid code block appears as a diagram in preview. It stays plain text in edit mode and in other Markdown editors:

```mermaid
flowchart LR
  A[Opened] --> B[Consent] --> C[Identity]
```

Mermaid's syntax supports flowcharts, sequence diagrams, state diagrams, and entity-relationship (ER) diagrams. Wide diagrams scroll within their own box. If a diagram has a syntax error, the app shows the error and source while keeping the rest of the note readable.

To set a diagram's theme, add a %%{init: …}%% directive on its first line. That setting overrides the app's light or dark theme. The app applies its theme only when the diagram has none of its own.

The Tasks view gathers task lines written as - [ ] in your notes. It groups them by owner:

• Mine contains your tasks and counts toward your workload. You can mark tasks done, defer them, or use Select to mark or assign several at once. Checking off a task updates the note it came from.
• Waiting on contains other people's commitments. Put a name before the task (**Jane** — send the contract) or write it in that person's note to place it here. These items have no checkbox and do not count toward your workload. Review them to see what you are waiting for. Any follow-up work you do after someone delivers becomes a new task of your own.
• Threads contains items without a named owner in a client area or its projects, meetings, and decisions. These provide context about the work. Like Waiting on, they have no checkbox and do not count toward your workload.

The task line identifies its owner. If a task is in the wrong group, use Assign to in the row's ⋯ menu. You can also assign several tasks from the Select toolbar. The app writes the name into the Markdown, as in - [ ] **Jane** — send the contract, so it can keep the task in the right group. Press ⌘Z to undo the change.

Waiting on and Threads only allow reassignment. Assign an item to yourself to move it into your own work. You cannot mark other people's commitments complete in those groups.

To write an owner by hand, use - [ ] **Sam** — send the contract. For shared work, use **Sam + Alex** or **Sam / Alex**. Use **Unassigned** when no one owns it yet. Claude names an owner when filing a task so the app does not have to guess. Older tasks may have no owner; assign them to make their ownership clear.

Later shows deferred tasks. They are counted and sorted by their return date and stay out of the other groups until then.

Each task belongs in one note. Use a person's note for their commitments and a project or area note for your own work. Meeting notes record assignments as plain bullets. Previously, the same task could appear as a checkbox in a meeting, in people's notes, and in an area note. Checking off one copy left the others open. Claude now writes the checkbox once in the note where the task will be maintained. The meeting note keeps a record of the assignment.

Running /focus or /tasks also writes Tasks.md in the vault's top-level folder. It lists your open tasks as plain bullets grouped by area, so you can read them on your phone through your synced vault. This file is a read-only copy: the app does not read changes from it, and each run replaces it. Complete tasks in the app or their source notes.

The same ownership rules apply elsewhere. A project's Open tasks count includes only your tasks, with a separate "Waiting on" list below. In a note, someone else's - [ ] appears as a plain bullet.

You can act on a task while reading a note. Right-click an open task line or hover over it and click ⋮. Your tasks have Do later, Assign to, and Won't do, just as in the Tasks view. Other people's tasks have only Assign to. These actions update the line's marker or name and can be undone with ⌘Z. Open Edit when you want to change the task's wording.

Use the scope control at the top to filter Tasks to one area or project.

A document is a long note for an area or a project, such as research, a draft, or talking points. It is the only note type intended for long writing.

• Every document belongs to an area, and can also belong to one of that area's projects. Choose a project when the writing serves one effort. Leave it at the area when it serves the area as a whole. Writing that does not belong to any area goes in a topic, which holds ideas that apply across the vault.
• Tasks belong on the project or area note. Put any commitments from a document there with the other tasks. The Field Guide flags any - [ ] task lines in a document.
• The description is indexed; the body is not. The ## Documents section on the project note, or on the area note for a document with no project, lists each document's title, a one-line description, and a link. Most features read only that entry. This keeps the daily summary from reading long documents that may have little to do with today's work. Write a clear description so the index is useful.

Create a document with Add ▸ Document or /document in Terminal. Pick an area, or one of its projects. A project brings its area with it.

To move a document later, use the path chip under its title, which reads Area / Project. Choose a project from the second half, or No project to leave it at the area. The document's entry in Documents moves to its new home with it, and Undo puts everything back. Changing the area clears the project, because projects belong to one area. Meetings have the same chip, without the index entry.

Add readonly: true to tell Claude to leave a document unchanged. See Protecting your writing for the limits of this setting.

Archiving removes an area, project, or person from active views while keeping its file in the vault. Choose Archive from the note's ⋮ menu to hide it from the Library, Graph, Tasks, and Today summary. The app adds archived: true to that file.

Notes within it are hidden too. Archiving an area hides its projects and meetings. Archiving a project hides its meetings and documents. The app works out which notes to hide when it reads the vault, so it only needs to edit the archived note's file. Restoring that note brings its contents back too.

The archive dialog also asks about related items outside those contents:

• People. People can be linked to several areas. When you archive an area, the dialog offers to archive people who would have no active area left. It leaves people linked to another active area alone.
• Loose tasks. Tasks elsewhere, such as in a journal entry, can link to the area or name one of those people as owner. The dialog offers to mark these won't do (- [-]) so they do not remain in Tasks after archiving. Tasks inside archived notes stay unchanged and return when those notes are restored.

Both options are checked by default. Press ⌘Z to undo the entire action. Open Archive in the Library sidebar to see archived notes. Each row lets you restore a note with one click or delete it permanently.

The Graph view maps the vault. Each note is a node, sized by how many links it has. Each link is an edge. Choose from two layouts:

• Force pulls connected notes together to show their relationships.
• Tree arranges notes from the top down, starting with you, to show their hierarchy.

The graph shows two kinds of edges:

• Solid lines are written links from your notes.
• Dashed lines are relationships the app inferred from frontmatter and folders, such as a project belonging to an area.

Use the Edges control in the graph toolbar to choose Written for only the links you wrote, or All to include inferred connections. The dashed lines from the Journal and Topics hubs, and from an area to its groups, stay in both modes so a filtered-in note never floats. The crosshair button pans the view back to you at the current zoom. Hover over an edge to see its source: a written link or the predicate used to infer it.

The app creates dashed connections from a note's area:, project:, or folder. A project connects to its area. A meeting connects to its project and area. Adding that information to the note creates the relationships in the graph.

You do not need to add a link back to the note's own area or project. Removing a written link like that leaves the inferred, dashed connection in place.

Areas need a written link from your profile. An area has no parent for the app to infer. Its entry in your profile's ## Areas list connects it to the graph. /area and the Capture dialog add this link when creating an area. A missing entry is flagged in the app's Field Guide, and the area appears disconnected in the graph.

Add links by hand for relationships the app cannot infer, such as a person involved in a project, a meeting related to another area, or a reference to work elsewhere. These appear as solid lines. The app maintains the connections it can derive from your notes.

A decision is a choice you want to track. Create one with ⌘N ▸ Decision. Like a project, it belongs to an area. Write its steps as task lines (- [ ]) to include them in Tasks. Use decidedBy to record who made the decision.

Change its status in the note header or View ▸ Decisions. Use open while deciding, made after choosing, and revisited when reconsidering. You can change these without editing YAML.

To record the result, choose Record outcome in the Decisions view or note header. This creates an outcome note, sets the decision's leadsTo field to that note, and adds a linked ## Outcome section to the decision. Recording an outcome this way confirms the relationship immediately.

The header then replaces the Record button with an Outcome link showing the outcome's title and an arrow.

A leadsTo field you write by hand or Claude proposes appears as a dotted line until you confirm it. The app needs your confirmation that the decision caused the outcome. Open View ▸ Decisions and choose Confirm to make the line solid.

Each decision in the sidebar has a status dot on its right edge: blue for open, green for made, and amber for revisited. A check appears when the outcome is confirmed.

You can mark part of a note or an entire file to tell Claude to leave your writing unchanged.

A protected region marks part of a note. Type / and choose Protected region. Select a passage first to place the markers around it. The markers are HTML comments, hidden when the note is displayed:

<!-- claude:keep-out -->
The part you wrote and want left alone.
<!-- /claude:keep-out -->

If you type the markers by hand, the short form works the same way:

<!-- no-ai -->
The part you wrote and want left alone.
<!-- /no-ai -->

Capitals work too, like <!-- NO-AI -->. Close a region with the same form you opened it with. Every HTML comment is hidden in the reading view, not just these.

Claude can still read the protected text and use it to answer questions. It is instructed to leave that text unchanged while editing the rest of the note. This lets you keep your own writing beside sections Claude maintains, such as a Meeting history index.

A read-only note tells Claude to leave the whole file unchanged. Add readonly: true to the frontmatter, the fields at the top of the note. Use this for notes you maintain yourself.

The app checks for unwanted changes. Both markings are instructions that Claude could misread while using its own editing tools. The app compares files before and after each run. If protected text changes, the review card flags it and lets you revert with one click. To block writes at the file level, use chmod a-w on the file.