Scalarmind

Working knowledge / 05 of 06

What is worth remembering?

After a difficult piece of work, there is usually more to save than the next person needs. A field note on finding the lesson inside the transcript.

Field note4 min readScalarmind journal

Take a finished conversation with an agent. Somewhere inside it are the requirements, a few wrong turns, a correction from the user, and the thing that finally worked. Saving all of it is easy. Deciding what another session should inherit takes more thought.

I would try this with one piece of work before turning it into a company-wide habit. Keep the original conversation available. Then write the smallest note that would have helped someone facing the same difficulty.

The first attempt is often a sentence such as “check the data carefully” or “make sure permissions are correct.” It sounds like a lesson because the work was painful. Read it without remembering the incident and it becomes difficult to act on. A competent colleague probably intended to do both already.

The useful detail is usually further down.

Put the note beside a real decision

Here is a hypothetical incident to work with. An agent changes a record and accidentally makes it visible to a wider group. The application has an audience field, but the correction path did not preserve the source record's audience.

“Be careful with access” would preserve the mood of the incident. A more usable note would tell the next person to check whether a correction inherits the record's existing audience when no new audience is supplied.

Now the note points to a decision in the work: what should happen when the caller leaves a field unspecified? It also suggests an observable check. A test can create a narrowly shared record, correct it without changing its audience, and inspect who can read the result.

The example is illustrative. The principle behind it comes from the learning discipline kept in Mana: preserve a lesson when it changes a future decision, and make its strategy concrete enough for a reader to apply without reconstructing the original incident.

That gives the editor a useful question. If someone reads this note tomorrow, what will they do differently?

From experience to guidance

  1. A concrete incidentKeep evidence of what happened.
  2. A checkable lessonName a changed decision and its boundary.
  3. A future taskTest whether someone else can use it.
An incident can remain in the history even when it yields no reusable instruction.

Keep the boundary with the lesson

There is a danger in making the sentence shorter. “Corrections must preserve access” sounds tidy, but what if the caller explicitly intends to narrow the audience? The original incident concerned an omitted field. Remove that detail and the lesson starts to govern situations it did not explain.

The note needs its scope. It also needs to distinguish what was observed from what merely seems likely. A failure in one correction path does not prove that every import, export, or summary has the same defect.

This is the same problem explored in the answer that used to be right, viewed from the moment the knowledge is first captured. A sentence travels more safely when a later reader can see the conditions that made it useful.

There is no prize for expressing every lesson as a universal rule. A narrow instruction that prevents a recurring mistake can be worth keeping. A broad principle whose meaning has to be supplied by the reader may add little.

Hand it to someone who missed the incident

Before adding the note to the shared guidance, imagine giving it to a colleague who saw none of the conversation. Better still, try that with a person or a fresh agent on a small artificial example.

Ask them what the note tells them to check and when it applies. Do not first explain the intended answer. If their interpretation is different, the wording has not yet carried the lesson across the gap.

This is a practical way to expose missing context. It should also leave room for rejection. Some incidents lead to a task to fix a specific defect, with no reusable instruction to add. Some proposed lessons duplicate guidance the team already has. Keeping both versions can create extra reading without adding a new decision.

The record of what happened can remain in the project history. The shorter set of instructions given to future work deserves a more selective admission process.

Retrieval is part of the experiment

Once the note is stored, try to find it using the words someone would use when they encounter the problem. Search for the task, the uncertainty, or the effect, rather than only its exact title.

If it cannot be found, it is not yet helping that future reader. If it appears in unrelated tasks, its wording or scope may be too broad. If an older version appears after a correction, the retrieval needs attention before the team can rely on the newer advice.

Mana provides a shared place for these records and the means to retrieve them. The value still depends on the quality of the captured lesson and whether it reaches the work where it matters. A small comparison across repeated tasks can reveal more than the number of memories in the store.

I would finish the exercise with one note, not a transcript rewritten as a handbook. Read it again after some distance from the incident. Can you still identify the decision, the check, and the boundary?

If you can, there is a reasonable candidate for shared memory. If you cannot, the experience may still matter, but its lesson has not yet become portable.

Six connected pieces · explore the reading path
  1. The colleague who remembers why
  2. When everyone can work at once
  3. The answer that used to be right
  4. Who gets to know?
  5. What is worth remembering?
  6. The work before the work

Follow the question