Extract Atomic Memory

Who or what the claim is about

subject is who or what the claim is about, and subject_kind says what kind of name that is: user, agent, named_entity, or unresolved.

When the transcript labels its speakers, resolve "I" and "my" against the speaker of the record's own source turn, not the preceding speaker or the person being addressed. In "Alex: Thanks, Sam. I finished it", Alex finished it. Check that attribution separately for each record; neighboring turns can describe different people's activities. Resolve "we", "both" and "together" from the group actually discussed. They do not automatically mean the speaker and the listener: in a discussion of a parent's activity with their children, "we did it together" keeps the parent-and-children group.

Use named_entity for a full proper name the text states — a person, an organization, a place — and for something the user is dictating that they identify by its title or its purpose sentence: a document, an e-mail, a meeting, a proposal. Pronouns, bare roles, and things the text never names ("the project", "the work", "my colleague") are unresolved; the engine asks again for the ones that matter, and that is the useful answer.

The name has to identify the very thing whose field you are setting, and it comes from the user. Before you write named_entity, apply one test to the subject you are about to write: is it a name someone would put in quotation marks and use as a title, or is it a description of what the thing does? A description, however precise, however faithfully it copies the user's words, is unresolved. Each of these was a real mistake and each is unresolved: "strategic initiative to develop and deploy an advanced avionics display integration system", "pilot program to redefine mobile content strategy", "the project led by Zara Okafor", "the proposal with the $800,000 budget", "email to Creative Directors and Regional Sales Directors", "the LinkedIn post". A subject that is a clause, or that begins "the project/proposal/email/post/meeting to …", is a description.

A proper name inside a field's CONTENT names the content, and the document that carries it stays unresolved. Removing an agenda item that mentions "Project Nexus" leaves the meeting itself unnamed; a deliverable that mentions the "Pan-European Digital Health Ecosystem" is about that ecosystem, and the proposal stays unnamed.

One narrow exception: the turn in which the user states a document's title, or dictates its purpose sentence into it, names that document — "The project proposal is titled X", "the email's purpose is to provide an update on the workflow optimization study". If an earlier turn in this window gave the title or the purpose, that name applies to every field claim you make from the turns you own. When this window gives neither, the document is unresolved; a name you would assemble yourself creates a second, separate thing in the memory.

Write the name as the user gave it: the identifying phrase itself, bare — Acme Corp Rebrand; the purpose sentence itself — To outline strategic research priorities for enhancing digital accessibility in healthcare. The engine merges spelling variants of a bare name.

Each field the user dictates is a separate claim about that thing, and every one of them is about it: the second recipient and the seventh key point as much as the first, and a hashtag, a call to action, a content type or a platform as much as a budget. Return every one of them, whether or not this window names the thing. When it does not, the record still comes back with subject_kind: unresolved and subject the short description the user used ("the project", "the proposal"); the engine attaches it to the right document afterwards, from candidates you cannot see. The risk assessment, the deliverables and the stakeholders of a proposal dictated across several turns are exactly the fields that arrive without the name, and returned as unresolved they are recovered.

The key

attribute is one entry from the list supplied for this record's subject kind (person_attribute_slugs for the user, thing_attribute_slugs for a named thing), or null. Choose the entry that states the same field the claim states. When none does, write null. The engine keeps a key only when it is in the list, so an entry that merely resembles one (preference.arts_culture where the list has preference.art and interest.arts_culture) leaves the record without a key, and a record without a key can never be replaced.

Time

Read time in the full context and return its meaning in time, following the supplied calendar instruction contract. temporal_phrase keeps the supporting words; it is evidence, never input to a phrase parser. ended_time describes an ending and is none otherwise. The engine performs calendar arithmetic only. Keep the original duration and do not replace it with a date you computed. An undated historical event is unresolved, not the session date.

ends_current is true when the claim says that a preference, or a named thing's standing state, has ended: "I used to like spirituals" ends that liking; a proposal whose funding has ended ends that state; "remove X from the recipients" and "the stakeholders no longer include Y" end X's and Y's membership, so those records are standing claims about the document with ends_current true. A task the user finished or dropped is a to-do record — todo done or removed — with ends_current false. ends_current is decided by that claim's own sentence alone, and it is false for these:

• "I started liking jazz last year" — says when the liking began.
• A value the user revises later in the same conversation — "the budget is $45,000", then "make that $52,000". The earlier claim still says what it said; the engine replaces it with the later value, and the chain from old to new depends on the earlier claim staying false. When the revision happens inside ONE turn — "the budget is $45,000… actually, make that $52,000" — return one record carrying the final value only; the figure the user withdrew in the same breath is not a claim. Rows born from one turn never replace each other, so a withdrawn figure returned as its own record would stay current beside the final one.
• A comparison — "prefers Joan Crawford's performances over James Stewart's" — states a current preference.

For a claim with ends_current true, claim_text states the current state first and the past second: "The user no longer likes Rita Hayworth; used to like her", "The user now likes Bill Evans; used to dislike him". The engine keeps this record as the current state and closes the older statements, so a reader who sees only this line must read it as what holds now.

ended_at_phrase is the exact words that say WHEN the ending happened, when the claim states them, and null otherwise. It is null whenever ends_current is false.

To-do Boundary

A to-do is a discrete action the user can finish and tick off. "I plan to" or "I'm going to" followed by a finishable action opens one. A project description, a deliverable, an ongoing goal, "the user is working on X", a habit, a routine and a recurring limit are standing claims with todo: none.

An in-flight progress report — "I am halfway through writing the release notes", "发布说明写到一 半了" — gets no record of its own; return the other claims the utterance states, split under the ordinary rules. Classify the original statement before paraphrasing: rewriting this report as "the user is working on the release notes" does not make it a separate standing fact. The exclusion also applies to claims_found; an otherwise empty progress turn returns both arrays empty. Being partway through an action is neither a completed occurrence nor a new intention to do it. Do not label it occurrence or todo: open. Before returning, remove any claim and record whose only evidence says that an action is currently underway; retain separately stated preferences, commitments, completed actions and other durable facts.

A to-do is done when the user explicitly says it was done. "I no longer need to book the reservations" closes that to-do as a standing record: todo is done when the user says it is done, removed when they dropped it. "I'll do it later today" keeps it open. Buying or paying for something is a related occurrence, and a "buy" to-do stays open until the user says it is done.

todo is open, done, removed or none. close_reason copies the user's words for done or removed, and is null otherwise. value for a to-do is the discrete action phrase alone.

The remaining fields

• claim_text states one claim, terse and near-verbatim. Claims that can change independently get separate records.
• value is the value the claim asserts.
• importance is high, medium or low. Low importance is still a record; write it.
• changes_current_state is true when the occurrence also changes a durable current state.
• source_span.turn_index is the number of the supporting turn as supplied, and source_span.quote copies that turn's supporting text exactly. The quote evidences the FIELD: quote the one turn that states this field, and let the name come from wherever the user gave it. A quote from one turn matches; a quote stitched from two turns matches neither.
• relations names up to three supplied relation types that the claim states; when none of the supplied types states it, use MENTIONS.
• single_claim answers whether claim_text contains exactly one independently mutable claim.

Reply with one JSON object and nothing before or after it. Its shape is

{"claims_found": ["<claim>", "<claim>"], "records": [{...}, {...}]}

claims_found comes first, inside the object under its key: one short string for each claim you return, in the order the claims appear, and an empty array when the window states none. records follows, one record for each entry of claims_found, each record complete as response_schema describes, with its source_span filled in. Listing the claims first is what makes the array complete: a reply that opens records at once is where whole turns go missing. The task-specific instructions the engine appends below (turns to account for, subject resolution, the missing durable half, the user-subject guard) apply to that call only.