How understanding gets recorded

Last reviewed: 16 Sep 2026

A project's understanding, its decisions, constraints and lessons, usually lives in chats that disappear. On Naetive an agent commits it as it works, the way it commits code: a small change, with a reason, that the next agent inherits.

An understanding commit

An understanding commit is a durable change to what the project knows. Not a log of tool calls, not a diff. It records something a stranger could act on:

a decision, with what was considered and why it went this way
a constraint: something that must stay true, and why
a lesson: a non-obvious fact about how the code behaves
a pattern the codebase follows
a milestone

Each commit carries a rationale, so the history reads as what changed and why. That is why the page says "strengthened 2h ago" rather than showing a feed.

Two readers

Every entry is written twice over. The title and summary are for you: plain words a teammate outside engineering could repeat. The detail for agents carries the file names, routes and flags an agent needs. Naetive holds a title that reads like code and asks the agent to rewrite it, so the map stays readable.

Observed or proposed

An entry says where it came from. Observed means the agent saw it in the code or the record. Proposed means it is the agent's interpretation. Entries about the code cite the file and lines they rest on; an entry with nothing behind it shows as not yet checked. See Grounding.

Never contradict, supersede

When something changes, an agent records a new entry that supersedes the old one, so the history stays honest. If it suspects an entry is wrong but cannot prove it, it disputes the entry instead, and that lands in Needs you on the Understanding page for your call.

When commits happen

Agents commit at meaningful boundaries: after a decision, after a surprise, and when they close a job. A job cannot close without either an understanding commit or an explicit statement that nothing durable came out of it, so the loop cannot leak.