Start with the correction
An agent writes that a new workflow is seamless. You know the user still has to connect two services, copy a key, and repeat a manual step. You edit the sentence: “Do not call this seamless. Show the setup and the unresolved hand-off.” The correction is useful, but what exactly has it proven?
It has proven that this result missed your standard in this task. It may suggest that you prefer concrete product language. It may reveal a rule for public launch writing: name the manual step before making an ease-of-use claim. It does not prove that you never use the word seamless, that all writing should focus on friction, or that every agent in every project should inherit the edit.
Separate the event from the interpretation
Most systems collapse those two things. A chat system keeps the correction inside one conversation, where it works briefly and then disappears. A broad memory system may store a sentence about your preference and retrieve it later. Both approaches avoid the harder decision: how does an observed correction become justified future guidance?
Meraki treats the correction as immutable evidence. The record keeps the original task, the agent result, the words you changed, the source material, and the later outcome. A separate process can then propose a candidate rule. That proposal is an interpretation. It must state what it thinks should change, where the change belongs, how long it should last, and which evidence supports it.
The distinction sounds procedural, but it protects the person behind the profile. If a correction and a rule are the same object, any temporary reaction can become durable identity. Frustration becomes preference. A project constraint becomes a universal habit. A model inference becomes a claim about who you are. Keeping evidence separate makes those mistakes visible before they spread.
Propose the smallest honest rule
A good candidate explains the miss without pretending to explain the whole person. In the example, “never use optimistic language” is too broad. “For public product claims in this launch, name required manual setup before describing ease of use” is narrow enough to inspect. It has a project, a task family, and a reason.
Small rules are not only safer. They are easier to test. The next matching task can receive the guidance while an unrelated task stays unchanged. If a future launch note becomes clearer, that is supporting evidence. If an exploratory memo becomes stiff because the rule leaked into it, the scope was wrong. The system can narrow or revoke the rule without deleting the original correction.
Approval matters here. A candidate changes nothing by default. A person or an explicit policy can accept it, weaken its confidence, shorten its expected lifetime, rescope it, or reject it. This keeps an agent from promoting its own interpretation into durable profile state merely because the interpretation sounds reasonable.
What the current evidence shows
Meraki Core already models evidence, candidate guidance, approval, scoped retrieval, profile versions, and rollback in a deterministic local loop. It can keep the source of a correction and construct a focused context pack for a later task. Those mechanics demonstrate that the separation is implementable.
They do not yet prove that generated candidates are consistently good, that people will understand scope decisions, or that the approach improves enough real work to justify its cost. Hosted invited-user proof and independent human evaluation remain unfinished. That boundary matters because a clean data model can still produce bad advice.
The unresolved question is therefore practical: what is the smallest amount of evidence that should justify a proposed change, and how should that threshold vary between a temporary workflow hint and a durable claim about judgment? Meraki is being built to make that question inspectable instead of answering it invisibly.