Meet Morrow Works.

What they know is spread across files.

A handbook, meeting notes, a copy pasted into the helpdesk. Each file holds part of the answer.

Your job is to make it usable, for the staff and for the AI assistant they work with.

We’ll follow one member’s question from start to finish. No background needed.

A member asks a simple question.

“How much notice makes cancelling my room booking free?”

The room is in France. They booked it on 4 May 2027. Today is 8 May, and we want the general rule as the member would see it.

Those details matter. Rules differ by country, by product and by booking date.

Search the file names. Nothing.

None of the five file names contains “cancellation”. The decision we need is saved as notes-04-18.md.

The answer exists. We were looking in the wrong place.

Searching file names works fine when you already know which file you want.

Search inside the files, and four answer.

Now the decision shows up, and it says 7 days. So do the original terms, the handbook and the helpdesk copy. They all say 14.

Finding passages like this is called retrieval. It found the statements. It can’t tell you which one applies.

This search really runs, in your browser, over the fictional files.

Three copies, one decision.

The handbook copied the original terms, and the helpdesk copied the handbook. All three 14s come from one place.

The 7 comes from an approved board decision. A newer-looking file name doesn’t overrule it, and neither does a majority.

What matters is where each statement came from, not how often it appears.

Does the change cover this booking?

The board approved it on 18 April. It covers France room bookings made from 1 May. The team’s files received it on 3 May.

Our booking was made on 4 May and we’re asking on 8 May, so it’s covered. The answer is 7 days.

An April booking in France, or any booking in Germany, would get a different answer.

The assistant needs the reasons, not just the number.

An AI assistant only sees what you hand it for this answer. That bundle is called its context.

Here we hand it the rule for which documents win, plus the decision that applies. A document left out of the bundle can’t help, however well it was stored.

Saving the file was the easy part.

We had to find it, work out how it related to the others, check when it applied, and hand over the right part.

When a rule changes tomorrow, all of that has to be redone. That work, more than storage, is what we mean by memory.

We started with a known question. Teams also need to explore files before they know what to ask. That’s next.

The team wants the bigger picture.

The member has an answer. Now the team wants to understand what happens when bookings change.

An operations note is a start: rooms sit empty after cancellations, while other requests come in too late. Could those freed rooms go to someone else?

Still 8 May, still the member’s view. The note records what staff noticed. Nobody measured anything.

One note, several ways in.

File the note under “operations” and it’s stored. But someone studying booking changes won’t think to look there.

Tag it three ways instead: room capacity, booking lifecycle, preparation work. It’s still one note, reachable from three directions.

Start with rough categories you can change later. You don’t need a perfect filing system first.

Two things called Atlas.

“Atlas” shows up twice in the files. One is a room in France. The other is a recording kit in Germany.

The shared name can put them in the same search results. It must not merge them, or apply the room’s rules to the kit.

Grouping asks “what is this related to?” Identity asks “which thing is this?” Keep the two apart.

A promising link still needs evidence.

Back to the empty-rooms note. A separate draft proposes a two-day cancellation window for a trial in French rooms. It also asks someone to compare rebooking and preparation costs.

Read together, the two give the team something to investigate. They don’t show the trial would fill rooms, and the draft is still only a draft.

Keep the link and the doubt together. Nothing in these files measures what a shorter window would do.

A good summary keeps the doubt in.

The team writes a short overview: empty rooms were noticed, a trial was proposed, rebooking was never measured.

Squash that into “shorter notice fills rooms” and the doubt disappears. Keep what was seen, what was proposed and what’s missing on separate lines, each linked to its source.

A summary is one more thing to check and correct. It doesn’t replace the files.

The files suggest the next question.

“Do freed rooms actually get booked again?” Nobody asked that at first. It came from reading the notes side by side.

Answering it needs booking data and a way to test the trial. These files can’t give a rate or prove a cause. Say so, and don’t make up a number.

You went from finding a known answer to finding what you still need to learn. A clear gap is a useful result.

The rule changed before the files caught up.

Rewind to 3 May 2027. The board minutes with the 7-day rule have just reached the team’s files. The board approved the rule on 18 April, and it took effect on 1 May.

Approved, in effect, received: three different dates. Arriving late doesn’t move the date the rule took effect.

We’re still looking back from 8 May as a member. No new decision is invented here.

A new rule doesn’t replace every old one.

The decision sets 7 days for France room bookings made on or after 1 May. France room bookings made from 1 January 2027 up to 30 April keep 14 days.

Rooms in Germany and equipment rentals don’t change. The update has to land on the right rule, not overwrite every cancellation rule in the files.

Examples here are about ATLAS-ROOM-FR, seen by a member on 8 May. They cover the general terms, not individual waivers.

The source is current. The summary isn’t.

Say the team saved a one-line summary on 2 May: “France room bookings need 14 days’ notice.” It matched the old terms and missed a change already in effect.

Then the minutes arrive. The summary doesn’t fix itself because a new file showed up. Staff, or the assistant, could still be handed the old line.

The decision itself is still S03.

Fix the summary. Keep the old one on record.

The new summary splits the cases: 14 days for France room bookings made from 1 January 2027 up to 30 April, 7 days from 1 May. It links to the original terms, the change and the rules for when each applies.

The old summary can stay in the history, marked incomplete. It must not be served as today’s answer.

Keeping an old version shows what the system believed. It doesn’t show that the belief was right.

Two questions about the past, two answers.

“What applies to a France room booked on 29 April?” That’s about the booking’s terms. Seen from 8 May, it’s still 14 days, because the booking came before the change.

“What did the files contain on 2 May?” That’s about the files. They didn’t have S03 yet. That doesn’t mean the change wasn’t in effect.

Both are about ATLAS-ROOM-FR and the member’s view. The first uses what’s known on 8 May. The second rebuilds what the files held on 2 May.

Some conflicts have no winner.

Back on 8 May, the team finds another problem, this time for ATLAS-KIT-DE, the recording kit in Germany. For returns from 6 May, one logistics lead says “before 17:00 UTC”. Another says “before 18:00 UTC”.

Both were written on 4 May, both leads have the same authority, and neither cancels the other. Which paragraph comes first doesn’t settle it.

Keep both, mark the deadline unresolved, and ask logistics for a ruling. A tidy merged answer would hide the conflict.

This is a return-time question, not a cancellation rule. The files never settle it.

A booking number isn’t a key.

8 May 2027. Someone asks about DEMO-R17, a France room booked on 29 April. We can explain the general cancellation terms. Can we also say what this booking will cost?

Not from the member’s side. Waiver records are for finance only. Knowing the booking number gives no access, and the answer mustn’t hint at whether a waiver exists.

So the answer stays general: here is the policy, and here is who can check your booking. A file being stored somewhere doesn’t mean everyone may use it.

Member · ATLAS-ROOM-FR · DEMO-R17 · booked 29 April 2027 · as of 8 May.

Search found the right rule. The assistant never saw it.

A different booking now: the Atlas room in France, booked on 4 May 2027. On 8 May the member asks for the general free-cancellation notice, not the fee for one cancellation.

Search finds both the original terms and the change. But the app passes only the original 14-day passage to the assistant. The change never reaches it.

Context is what the assistant is given for this one answer. Finding evidence and putting it into context are two steps, and things can go wrong between them.

The 4 May booking falls under S03’s France-room rule, and the member may read both sources.

Send the scope along with the evidence.

The team fixes the bundle. It now says which room, country, product, booking date, reader and knowledge date it’s about, alongside the rules for when each policy applies and the policy passages themselves.

For this France room booked on 4 May, the change gives 7 days. The original terms and the change both stay visible, so the number arrives with its reasons.

This doesn’t mean sending every file. Pick what the reader may see and what’s relevant, plus what’s needed to read it correctly. More text won’t make up for missing evidence.

Same case: member · ATLAS-ROOM-FR · booked 4 May 2027 · as of 8 May.

The right source can still be misread.

Even with the fixed bundle, an assistant could treat 7 days as a rule for everything, and wrongly apply it to rooms in Germany, equipment and older France bookings.

A good answer here is: “For this France room booked on 4 May 2027, free cancellation needs at least 7 days’ notice.” It doesn’t calculate a fee or reveal private exceptions.

The whole chain is now visible: stored, found, applicable, allowed, handed over, used correctly. Check each step. Passing one doesn’t mean the next will pass.

S03 leaves Germany rooms and equipment unchanged; S02 and S03 cover older France bookings. If a detail is missing, ask. Don’t guess.

Three days later: which door?

11 May 2027. The same member is arriving at ATLAS-ROOM-FR. A notice received on 9 May says to use the courtyard entrance for arrivals from 10 to 12 May, during maintenance.

For an 11 May arrival, the notice is current. Its end date matters as much as what it says: it expires at 00:00 UTC on 13 May.

The notice has also been copied into an extracted fact, a summary and an answer cache. Which of those copies depend on it?

New date, new task: member · ATLAS-ROOM-FR · arriving 11 May 2027. The 8 May scenes couldn’t see this notice (S10).

13 May: yesterday’s notice no longer answers.

At 00:00 UTC on 13 May the courtyard notice expires. For someone arriving that day, it can’t answer “which door?”. The files don’t say which entrance to use now, so don’t make one up.

The old notice can still explain what happened on 11 May. Useful as history and valid today are different questions.

Expired isn’t deleted. The records rule allows a short history window. Then the notice and every copy the team owns must be deleted at 00:00 UTC on 15 May.

Member · ATLAS-ROOM-FR · as of 13 May 2027. The two-day history window is this fictional company’s rule, not a general standard.

15 May: deleting means the copies too.

At 00:00 UTC on 15 May the deletion has to reach four places the team owns: the source store, the extracted facts, the summary and the answer cache. Deleting only the original leaves the content behind elsewhere.

What remains is a receipt with the source ID and deletion time, without the notice itself. From these stores, nobody can now say which door the 11 May guest used.

Policy decisions and waiver history are outside this deletion rule.

Member · ATLAS-ROOM-FR · as of 15 May 2027. The rule covers stores the team owns.