Propose a durable memory
arroway_rememberSave a durable memory (decision/rule/fact/preference/reference/identity) as governed by default. For a source-backed fact or reference that is useful only as agent context, set treatment='finding' and explain why: it costs nobody a review, and is stored as CONTEXT, never a human-sanctioned norm, cannot be pinned, and is shown separately in Findings. A finding cannot replace a sanctioned memory; correcting another finding is in-place replacement with no human queue. A finding a person revoked cannot be written again unless they reconsidered in this conversation — related_checked does not unlock that. 'identity' is WHO someone is — a person, a relation, a background: it never expires, never pins by default, and comes back when the person is part of the task; someone from the user's own circle belongs in their personal project, people of a business in that business's project. If the human explicitly stated or sanctioned it in this conversation, set decided_by_human=true (memory becomes active). Otherwise it is saved as a PROPOSAL for the human's weekly review — never present a proposal as a decision. kill_condition is mandatory: what would kill or force a review of this memory. A RULE takes TWO calls: send it with no pin fields and no related_checked, read the neighbours and the block cost the server returns, then call again with the token it gave you and the pin decided against what you just saw. Any OTHER type stays one call unless you ask to pin it: sending pin_suggested or pin_requested_by_human starts the same comparison, and only the second call with the returned token can pin it. Any type that the server stops for strong related memories also takes TWO calls: read those memories, then return related_checked=true together with its related_check_token. A flag alone never proves a comparison happened.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| title | Yes | Short, unique within the project | |
| topic | No | ||
| content | Yes | The norm ITSELF, written as if it were true today and nobody had to be told how it got here. Length is never free: this body is re-read by every assistant on this project, on every read, from now on — write the shortest version that still governs correctly. Keep only the reasoning WITHOUT WHICH the rule would be applied wrongly; if removing a sentence would not change anyone's next action, it is biography, not norm. Leave out the biography: who said it, on what date, their exact words, the episode that produced it, and numbers measured on a particular day — all of that goes in why_source. A body that opens with a quote makes the next assistant follow the quote instead of the rule, and a date in the body makes it discount the whole memory as possibly stale. If a GENERAL rule shows up while you are writing about a specific case, the general rule is the memory and the case is the example — not the other way round: the case goes in the example field, never here. Condense: a memory per sentence is how Arroway fills with near-duplicates. | |
| essence | Yes | The memory's essence in ONE line: the operative norm or fact, not the first sentence and not its biography. This is the compressed layer that always travels when the full body does not fit. | |
| example | No | A concrete case that ILLUSTRATES the rule — the human sees it in the panel next to the rule; it NEVER travels in reads, so no assistant can mistake the case for the rule's scope. If the rule cannot be applied correctly without this example, the example is smuggling a criterion: name that criterion in content instead. Quotes, dates and the episode that produced the rule still belong in why_source. | |
| expires | No | ARROW-78. Set true ONLY for a dated STATUS — a number, a rollout state, a temporary condition — where being read after review_at would assert something stale as current: it stops being returned once the date passes. Leave it out for a durable fact that merely needs re-checking (a market structure, how a tool works): that one keeps being returned, marked as due for re-check. If unsure, leave it out — a fact that vanishes leaves no trace, one that comes back marked cannot be mistaken for current. | |
| project | Yes | Project slug. If it did not come from the person or from a read in this session, it is a guess: check it against the roster that opens arroway_catch_up before writing, because material from one circle must never land in another. | |
| review_at | No | ISO date (YYYY-MM-DD) when this stops being true on its own — the end of a cycle, a deadline, a season. This is how a COMMITMENT is carried: an objective is a decision with a horizon. REQUIRED for type=fact, and there it also removes the memory from reads once the date passes. Leave it empty only for something with no expiry date at all. | |
| treatment | No | Which of two destinations this write takes, and they cost different people. `governed` enters the person's review queue, and that review is a real cost to them — pay it for what governs. `finding` costs nobody a review: it is served to agents as context, never becomes a sanctioned norm, cannot be pinned and cannot replace one. The line between them is not the topic, it is the force: does this GOVERN what someone may or must do, or only INFORM? Governs → governed. Informs, and points at a source another agent can reopen and compare — a file, a URL, a record, a query → finding, and only fact and reference qualify. | |
| backfilled | No | True when this is HISTORY you are bringing in — something that was already true before Arroway existed, not something that just happened. The moment to use it: you finished a task about topic X, the read came back thin on X, and the work took you to a durable SOURCE about X — a file in this workspace, a document, a ticket. Then write that history too. Only the topic you just worked on, never a project dump; only what you can point a source at, never your own recollection of past conversations; a few memories, not a batch. | |
| source_ptr | No | Pointer to the living source, when verifiable | |
| why_source | No | Where it came from, and this is the ONLY place biography belongs: who decided, when, in their words, what was measured, which episode produced it. This does NOT travel in reads — it is what a person sees when auditing the memory in the panel, and what tells them whether the rule still deserves to exist. Writing it here costs nothing to whoever reads Arroway while working; writing it in the body costs every assistant, every read. | |
| contradiction | No | Required with supersedes_id: name what the earlier memory says that this one contradicts or changes. This is the named contrast that proves it is the same point, not merely a neighbour on the same topic. Do not point at a memory that can be followed alongside this one. | |
| pin_suggested | No | Whether this memory sits in the fixed block of EVERY read, costing tokens in every session of this project from now on. There is no default: a rule requires this on its confirming call, and any other type carrying this field begins the same two-call comparison. The first call does not decide the pin; return this value only with pin_decision_token after the server showed the neighbours and cost. Three questions decide: does breaking this cause expensive or irreversible damage · does it apply to every task, or only when someone touches one area · would the next person have found it anyway when they opened the relevant file? A memory discoverable where it matters is a reference or a fact, not a pinned rule. What a pin actually costs: it does not displace another pin — it eats the SAMPLED space of every read, which is where the memories relevant to someone else's task come from. This field carries YOUR judgement, so above the block's ceiling the server turns it into a proposal of the pin alone and the memory itself still lands. The person's own order is pin_requested_by_human, and it is not this field. | |
| supersedes_id | No | If this replaces an earlier memory: its #handle from a read. Point only when the two memories are the SAME point: acting on either would already satisfy or violate the other. A shared topic is not enough — if both can be followed together, they are different memories. | |
| kill_condition | Yes | Mandatory: explicit revocation / named trigger / review date | |
| related_checked | No | Only after the server showed you related memories: set true with related_check_token to confirm you read them and this is a genuinely different point, not an update to one of them. Never set either blindly on a first call. | |
| decided_by_human | Yes | true ONLY when the person stated or sanctioned this in THIS conversation. Never because it looks obviously right to you. false makes it a PROPOSAL for their review, which is the normal case — and a proposal is never free: it costs that person a review, whether they end up approving it, editing it or turning it down. What it costs afterwards depends on where it sits: only a PINNED memory travels in every read of the project from now on; a normal memory competes for space in the block relevant to the task at hand. So the question that decides whether to write at all is not what the write costs you — it is whether this would change what someone does on a DIFFERENT task. Three things never pass that question, however true they are: an instruction to check, verify, be careful or look at the source; a step of a routine, which belongs in the prompt that runs it; and anything that is here only because something went wrong once. | |
| split_considered | No | Set true only after you looked for the seams and this genuinely has to stay whole. Splitting is the default: a long memory usually holds a norm, the reasoning behind it, and a checklist — and only the first belongs here. | |
| example_considered | No | Only after the server flagged the body as carrying its example: set true to confirm you re-read it and what looks like an example there is actually criterion the rule needs — an exact string it matches on, a deadline it carries. Never set it blindly on a first call. | |
| pin_decision_token | No | The token the server gave you on the first call for a pin decision. A rule always uses this two-call flow; every other type uses it whenever pin_suggested or pin_requested_by_human is present. The first call returns the neighbouring memories with the pin state of each and what the fixed block currently costs, and only the second one writes. Send the token back unchanged on that second call, together with the pin decision. It is tied to the exact title and body you compared, works once, and expires — a comparison you cannot prove is a comparison that did not happen, so a confirmation without it is refused and nothing is written. | |
| related_check_token | No | The one-use token the server returned with related memories. It proves this confirmation follows THAT comparison and is tied to this exact text. | |
| pin_requested_by_human | No | true ONLY when the person, in THIS conversation, told you to fix this memory in every session — 'pin this', 'this has to be in every session', 'always send this'. On any type, sending it begins the two-call comparison; only the return with pin_decision_token records the order. Sanctioning the CONTENT is not asking for the pin: they can agree a memory is right, and correct, and still never have asked for it to travel in every read. Those are two different facts and the server records them separately. Their order pins immediately, above any ceiling, and the block's hygiene is then theirs; your own judgement goes in pin_suggested and passes through the ceiling. Never set this because the pin looks obviously right to you — that is pin_suggested. | |
| revoked_reconsideration | No | Required when a related finding was revoked by a person: quote what they said in THIS conversation that reconsiders it. related_checked does not unlock rewriting a revoked finding. Do not promise that old prompts or past actions will be undone. | |
| treatment_justification | No | Required with treatment=finding: say why this is verifiable context rather than a policy, priority, procedure, or decision for a person. |