Sundance Lake Loop: who can read what on a pipeline project

Sundance Lake Loop is a made-up natural gas pipeline project, told over twelve months and six chapters. Six employees of a fictional company work on it: a project manager in the field, a project controller, a supply chain specialist, a project administrator, an accounts payable clerk and an internal auditor. Each of them works with an assistant that has its own SurrealDB Agent Memory key. The key decides which project records the assistant can read, and the assistant also remembers the conversations its owner takes part in.

The company, the project and the people are fictional. The project's size, schedule and regulatory conditions are modelled on a natural gas pipeline loop built in northwest Alberta, and the way the work moves between the field, the controller, supply chain, project administration and accounts payable follows how such projects are run in the Canadian pipeline industry.

The demo

The demo opens on a contents page with the cast and the scopes each person can read. Each chapter is a page of conversations, drawn as comic strips, with the project records of that period between them. What the assistants caught is the short version: the notes that changed what someone did, one that was ignored, and who could answer the auditor's questions on each date.

As you read a chapter

• •

  Scopes are under every message and record. A record shows the scopes it is filed under, and a message shows the scopes its speaker's assistant recalled from, with the number of items from each. Hover over or tap a scope to see who can and cannot read it on that date.

• •

  Email and chat are reviewed before they are sent. The assistant reads the draft, and a box under the message shows what it flagged and what it suggested, marked sent anyway when its owner did not follow it.

• •

  Calls and meetings are reviewed afterwards. Nobody is interrupted while they talk. The assistant reviews what its owner said and leaves a note, and the next message shows when its owner glanced at it.

• •

  Two people have no assistant. The contractor's project manager and a local resident with a boat are outside the company, so their records sit under their own vendor scopes as well as the internal one.

How the money moves through SAP

The fictional company buys and pays through SAP S/4HANA. A purchase starts as a purchase requisition and becomes a purchase order. The work is confirmed with a service entry sheet, or a goods receipt for materials, and SAP posts an invoice only once it matches both the purchase order and the receipt, which is called a three-way match. Approved invoices go into a weekly payment run. A vendor has to be qualified by supply chain and set up as a business partner before any of this can happen. For a SurrealDB schema of the same process, see the procure-to-pay starter among the sample industry schemas.

The demo does not connect to SAP. Its project records are the documents SAP would hold, written into Agent Memory on their dates and filed under scopes, so each step of the process is visible only to the people whose work it is:

Two of the story's problems come from this process. SAP does not post an invoice without a purchase order, so the boat Wes hired by phone needs an after-the-fact purchase order, which supply chain has to justify. And an invoice approved in SAP stays in the payment queue until someone reverses the approval, so the original invoice 4471 and its replacement were both queued for the same payment run.

What the demo shows

Every read goes through a scoped key

The six assistants share one Context, and each reads with a key whose grants list the scopes that person may read. Agent Memory applies the grants on every read, so a query from the project manager's assistant about the sealed bids returns none of the bid figures, none of the facts extracted from the bid record, and no entity that appears only in it. The one bidder name it does return comes from the prequalification record, which the project manager is cleared to read.

The project manager's access changes once in the story. On the day the contract is awarded, he gains read access to the bid summary, so a question about the bids gets nothing before that date and the summary after it.

A conversation belongs to the people in it

Each message is written to Agent Memory under the private scope of every Chinook employee in the conversation, as alternatives: anyone who holds one of those scopes can read it. Everyone in the conversation remembers what was said, and nobody else does. This is what lets the controller hold back a date she learnt in a conversation the project manager was not part of, and it is also why the auditor needs the project manager to tell him about a phone call that no project record describes.

The assistant checks a figure against what was first said

When the assistant reviews a turn, it searches memory for the claims in that turn, so a stated rate meets the conversation where the rate was quoted. Agent Memory keeps every version of a figure with its source and its time, and the choice between them is the assistant's: where memory holds more than one version, it trusts the first-hand one, what the person who set the figure said or a signed record, over a later restatement by someone else. Eight months after the project manager hired a boat by phone, the auditor gets the rate the boat's owner quoted on the call.

The audit is read as of each date

The auditor's two questions are put to each person's assistant as of five dates, with the key that person had on each date. The grid on What the assistants caught shows who could answer, in part or in full, and on what. The project records say only that "the project administrator" approved the boat invoice. The name, and the reason the boat was needed, come from conversations, which only the people in them remember.

How it was built

The story runs in date order. Each project record is written into its scopes on its date, and each conversation is written one message at a time, by a model playing each person from what that person's assistant recalls as of that moment.

Each assistant's key comes from POST /keys, with grants that narrow the caller's own access to the scopes on that person's card. See self-service keys in the REST API reference.

{
	"name": "wes",
	"grants": {
		"memory:read": ["sundance/shared", "sundance/cost", "sundance/changes", "supply/vendors/outcomes", "person/wes"]
	}
}

A message goes to /facts with observed_at set to the time it was said, and with one scope set for each Chinook employee in the conversation. A flat list of scope sets is read as alternatives, so either person's key can read the message. See scope tags for the wire format.

{
	"text": "[T10.2 · Phone call · from Wes Haldane to Jordan Kowalczyk · scope conversation memory of Jordan Kowalczyk, Wes Haldane · 2025-10-07T07:46] Yeah, hang on, let me flip back in my book...",
	"infer": "full",
	"scopes": [["person/jordan"], ["person/wes"]],
	"observed_at": "2025-10-07T07:46:00-06:00"
}

Each stored text starts with a header naming what it is and the scope it was filed under, so that the assistant can tell where each recalled item came from when it decides what its owner may repeat to someone else.

Before each message, the speaker's assistant queries with the speaker's own key and asOf set to that moment. The key's grants decide what comes back, so the query needs no scope filter of its own.

{
	"query": "the boat on Sundance Lake, and who approved it",
	"k": 10,
	"asOf": "2025-10-07T07:46:00-06:00"
}

Related pages

• •

  Contexts and scope: how scopes partition a Context, and how grants decide what a key can read.

• •

  REST API: the /keys, /facts and /query endpoints the demo uses.

• •

  Night Owls: seven agents on a forum, with private scopes and point-in-time recall over twenty years.

• •

  Calgary 1912-1913 explorer: a city where every answer a resident gives comes from a scope you can inspect.