GitHub / code
Production behavior, architecture, dependencies
SCHEDULE = "daily 02:00" SOURCE = "sftp" # not API
The story
The record is the foundation.
Context is the multiplier.
From scattered company knowledge to a governed institutional record that generates the context people need to act. Fifteen screens: what goes wrong, what changed, where we come in, and what it makes possible.
- The painKnowledge lives in many places, behind different doors, and people became the layer on top.
- What changedAI can read what the business already knows. People still decide what is true.
- Where we come inMany systems become one record, with a structure that shows the gaps.
- What it makes possibleFrom search to context generation, and the flywheel that keeps it growing.
The pain · 01
Where do I even start?
You ask for the documentation and get sent to seven places.
Questions immediately appear
Select a question to see it on the map.
You
Shared drive folder
Slack thread
Code repository
BI dashboard
Contract folder
Someone’s inbox
Old wiki page
The workaround · 02
So we ask a person
Eventually, we do the rational thing: we book a meeting.
Then over the next few weeks it becomes Slack, coffee, and messages like these.
People are not just providing information. They are providing context.
Illustration · the real documentation system
Jordan · Monday
I’ll Slack you the link.
Where it actually lives
Priya · Wednesday
That’s technically right, but…
The exception nobody wrote down
Marcus · the next week
Don’t use that file.
Which source to trust
Elena · over coffee
Sarah knows why we did that.
Why a decision was made
Dev · week three
Ask Cam.
Who really owns it
The archive · 03
The knowledge survived. But can anyone use it?
The company’s knowledge survives in an archive written in many different languages.
- Code
if order.amount:Engineering only - SQL
SELECT account_idData team only - Contracts
§ 9.1 TerminationLegal only - Dashboards
- Spreadsheets
=SUMIFS(C:C,…)Finance only - Policies
Policy 4.2 · v7 - Meeting notes
Action items (3) - Emails
Re: Fwd: Re:Inbox owner only - Project tools
Status: Blocked
It also sits behind different access rights.
Example · a finance leader’s view
A finance leader can see revenue on a dashboard, but not necessarily the SQL, lineage, exclusions, or transformation logic underneath it.
RevenueDashboard
Underneath, out of view
- SQL
- Lineage
- Exclusions
- Transformation logic
So they go to BI.
What changed · 04
AI changed what was possible
AI can now read the languages companies already speak and translate them into structured knowledge that humans and machines can consume.
The advantage is not only speed. AI can work from what is actually present in the source:
- The code is what production does.
- The contract is what was signed.
- The SQL is how the metric is calculated.
Illustration · reading the languages a company speaks
What the code says
from payments import Processor from cache import cached @cached(hours=1) def account_profile(id): return Processor.get(id)
What it becomes
- Architecture
- Account profiles come from the payment processor, through a cache.
- Dependencies
- The payment processor’s SDK and a caching layer.
- System documentation
- A profile can be up to an hour old. The screen never says so.
Creation · 05
We stopped trying to write documentation. We started creating it.
It is easier to criticize than create.
The old ask
Untitled · 0 words
“Please document how this system works.”
The new ask
Generated draft · for review
Refund requests arrive through the portal. Requests over $500 go to a second approver. Approved refunds reach finance overnight.
refund-service codeRefund policy, revised.docxRefunds dashboard SQL
Two sources disagree. The policy allows refunds for 30 days. The code allows 45. Which one is right?
Maintenance · 06
Creating it once does not solve the problem
Old documentation often fails on Day 217, not Day 1.
Day 1Written. Accurate.
Day 64The code changes.
Day 131A contract is amended.
Day 217Someone relies on it.
- 1
Source changes
Code, contract, metric, or workflow changes.
- 2
Affected knowledge identified
The engine finds pages that may now be stale.
- 3
Draft update created
AI proposes the change and shows what will be overwritten.
- 4
Human review
A person approves, corrects, or pulls the handbrake.
- 5
Record updated
Approved institutional memory stays current.
Run it to watch one change move through the engine. It stops at step 4 and waits for a person.
Where we come in · 07
From many systems to one record
These systems were never built to explain the business to the same audience. Memory at Scale brings their knowledge together without pretending the original systems disappear.
Contracts / business documents
Rules, dates, obligations, exceptions
§4.2 Invoiced per active user Sch. B Data by file transfer
BI / SQL / data
Definitions, lineage, calculations
SELECT user_id FROM logins WHERE at >= today - 30
Illustration · the institutional record
Client XClient profile
Approved- Purpose
- Owner
- Sources
- Rules
- History
- Status
What sits on top
Readable pages
The approved record, by area
Search and Q&A
Answers that name their sources
Generated context
Assembled for the task in front of you
Structure · 08
We define what “good” looks like
We do not simply tell AI: “Go document the company.”
Different kinds of knowledge need different structures. Each model lists the sections a page must have.
If the engine cannot populate a required section, that may represent a real gap in the organization, not just an incomplete document.
Knowledge model · system page
Payment syncA system page requires
PurposeRequired
OwnerRequired
ArchitectureRequired
AuthenticationRequired
DependenciesRequired
MonitoringRequired
RecoveryRequired
Known risksRequired
The obvious question · 09
Why not just point Claude at everything?
Because this is still work. It is just better work.
AI is excellent at
- Reading
- Comparing
- Translating
- Drafting
- Finding patterns
- Spotting inconsistencies
But people still decide
- Which source is authoritative?
- What is missing?
- Which conflict reflects reality?
- What business context is absent from the source?
- Should this become the company’s record?
The x-ray · 10
We weren’t just documenting. We were seeing.
Documenting things properly surfaces what nobody was looking for.
Or drag across either card.
Definition conflict
IllustrationGross marginDashboard
Everyone believed it meant one thing:Revenue, less everything it cost to deliver.
Production logic
(revenue - product_cost) / revenue WHERE status <> 'refunded'
Production subtracts product cost only, not shipping or support, and leaves out refunded orders. The margin everyone was quoting is higher than the real one.
Operational risk
IllustrationPayment syncRunning
- Last change
- 3 weeks ago
- Alerts
- None
- Used by
- Finance, reporting
On the surface, nothing looks wrong.
Found while documenting it
- Security. A secret key where secrets shouldn’t be.
- Maintenance. Code going out of support.
- Ownership. No named owner.
- Control. No review before changes go live.
Beyond search · 11
Great. Now we can search everything. But is that how we solve problems anymore?
Once the record exists, people can
- Search it
- Browse pages
- Trace sources
- Find definitions
That is already valuable. But search is mainly useful when you know what you are looking for — an address, a policy, a recipe, a specific definition.
When people need to
- Understand something complicated
- Make a decision
- Plan work
- Learn an unfamiliar domain
- Create something new
They increasingly ask an AI system to help assemble what they need.
Illustration · one record, two ways in
refund policy
- Refund policy, revised
- Refund rate
- refund-service
You knew what to look for. You get documents.
In practice · 12
Context generation in action
One trusted memory
- Subcontractor portal
- Payment sync
- Known issues
- Use a queue
- Retry limit
- Exclusions
- Retention
- Active user
- Order
- Profile
- Contract
- Integration
- Systems
- Decisions
- Metrics
- Client X
Start from the same trusted institutional memory and generate different contexts for different needs.
Generated context · new engineer
Get me up to speed on the subcontractor portal: architecture, dependencies, history, decisions, and risks.
- Architecture
- Event-driven. Reads the payment sync, writes to the warehouse nightly.
- Dependencies
- Payment processor SDK, warehouse loader, a one-hour cache.
- History
- Started 2024. Rebuilt in 2025 when the sync moved to file transfer.
- Decisions
- Use a queue, not cron. Retry limit of five. Both accepted.
- Risks
- A dependency nearing end of support. No recovery runbook yet.
Assembled from 5 approved pages, each one cited.
Possibilities · 13
Once you see it, the possibilities multiply
A trusted institutional memory can generate context for:
The recordapproved, sourced, current
Example request1 of 8
Role-specific onboarding
“A finance analyst starts Monday. Build their first two weeks.”
Draws on processes, metric definitions, systems, and who to ask.
Adoption · 14
The memory flywheel
The system improves through use.
The signal it was working
Another team came asking to be included, because they had FOMO.
Trusted memory
The belief · 15
For decades, the answer to knowledge loss was: People need to document more.
But:
Writing was hard.
Maintaining was hard.
Finding was hard.
So forgetting was easier.
Now we can change the equation.
Let the work create the memory.
Let people decide what is true.
Let that memory generate the context we need next.
Make remembering easier than forgetting.
Memory At Scale · mematscale.com
Appendix
Questions people ask next
Open any of them.
Appendix · A1A1 of 9
How an engagement works
A practical path from first conversation to useful institutional memory.
- 1
Discover
We map where your knowledge lives, who owns which part of it, and the words your business uses for things.
- 2
Foundation
We stand the engine up in your cloud, behind your sign-in, with your people in the approver roles.
- 3
First loop
One real document goes all the way through, from submission to a published page, with your reviewers.
- 4
Connect
We switch on your systems one at a time, and watch each one run before starting the next.
- 5
Load
We bring in the documents you already have, with your people approving what goes in.
- 6
Operate
We run and curate it with you, or hand it over to your team. Either way it stays yours.
We won’t quote a number before we have seen where your knowledge lives. The build follows a fixed order with a check at every stage, and you get a timeline at the end of discovery. The eight decisions we make with you first →
A1How an engagement works
A practical path from first conversation to useful institutional memory.
- 1
Discover
We map where your knowledge lives, who owns which part of it, and the words your business uses for things.
- 2
Foundation
We stand the engine up in your cloud, behind your sign-in, with your people in the approver roles.
- 3
First loop
One real document goes all the way through, from submission to a published page, with your reviewers.
- 4
Connect
We switch on your systems one at a time, and watch each one run before starting the next.
- 5
Load
We bring in the documents you already have, with your people approving what goes in.
- 6
Operate
We run and curate it with you, or hand it over to your team. Either way it stays yours.
We won’t quote a number before we have seen where your knowledge lives. The build follows a fixed order with a check at every stage, and you get a timeline at the end of discovery. The eight decisions we make with you first →
A2What should we start with?
Start with a trusted island of knowledge where value can appear quickly.
Your code
Documents and code are always connected. A repository gets one page, rewritten in the week its code changes.
The first twenty documents
Of everything you have, the twenty documents everyone actually needs are the first week’s reviews.
The wiki you already have
If one already exists, we port it.
Then one system at a time
Everything else is a module we port when you have that system: the project tool, the warehouse, meeting notes, a cloud inventory. Each one is watched through a run before the next.
Known issues go on the table from day one: duplicates, stale documents nobody retired, spreadsheets whose later tabs hold the real data, sources carrying figures that may never be published.
A3What do we hand over?
The objective is a durable institutional record, not a black box.
- The knowledge
- Text files in your git repository, with their full history. There is no proprietary format to get out of.
- The running system
- Your cloud project, behind your sign-in, open only to the group you choose.
- Keys and credentials
- Your secret manager.
- AI usage
- Your own account, billed to you. We don’t resell it.
- Approvals and settings
- A database in your cloud project.
If we stopped working together tomorrow, you would keep everything, and it would keep running.
A4Who maintains it longer term?
Automation handles drift. People retain accountability.
- Wiki admin
- Reviews plans as they arrive, triages reported issues, approves new tags and entities, owns the forbidden list.
- Approver per domain
- Admits documents and approves plans in their area. Can be the admin, at first.
- Declarers
- Name new platforms, integrations and spine units, since the engine may not invent them.
- Everyone
- Submits documents, asks questions, and reports a page they know is wrong.
- Us
- The connections, the deploys, the contract changes you ask for, a new module when you add a system. Or we hand it over to your team. Either way it stays yours.
A5How do we know the engine is healthy?
Health is not only uptime. It is the quality of the institutional memory.
Freshness
Pages carry their sources and the date they last changed.
Plan reviews
As they arrive, in the app and in your channel. A review is a few minutes.
The release check
Every release is checked first. One broken link holds the whole release back.
Reported problems
Readers can report a problem on any page. The fix goes through the same review.
The weekly lint report
Keeps the graph clean.
Questions it could not answer
Reviewed weekly: the list of what to write next.
From the engine’s own build. The first release check found 888 problems across 779 pages, 629 of them broken links. Nothing had been checking. Now nothing is released until the check passes.
A6Common challenges after launch
Many apparent “system issues” are actually organizational issues made visible.
Memory at Scale does not create the problem. It may reveal the problem.
A7Real example patterns
Sanitized real examples in one format: situation, what the engine found, why it mattered, outcome.
Situation
A metric everyone believed they understood.
What the engine found
Production logic excluded records that the shared definition never mentioned.
Why it mattered
People were making decisions on a number that meant something narrower than they thought.
Outcome
The mismatch was resolved. The record now states the exclusion, with the SQL as its source.
A8What do we need to build one?
Eight things, one per step of the start. None of them is a document; most are names.
- The shape
- How you already talk about the business, the list of things you run, and who would approve a page in each area.
- The data
- A list of systems with an owner beside each, a rough count of documents, and your honest list of what is messy.
- Where it lives
- Your cloud, identity and GitHub administrators, each for about an hour across the build.
- Risk and compliance
- Your compliance owner, the regimes you report under, and anything legal would want on the forbidden list.
- Governance
- One approver per domain, a wiki admin, and a decision on whether admission and approval must be different people.
- The AI
- The owner of the AI account and the cloud bill, and a budget for the bootstrap month.
- Build and launch
- The people above, available when their milestone arrives, and a real document and a real question for the first loop.
- Starting the flywheel
- Who the wiki admin is, and what colours and logo the site should wear.
Already connects to
Today it is built for Google Cloud and Google Workspace, and that is where it goes in fastest. On a different stack, such as Microsoft 365, the engine is the same but the connectors to your documents and tools have to be rebuilt. We scope that in discovery, before you commit to anything.
A9Source authority and governance
The hardest question is often not “Can AI read it?” It is “What do we agree is true?”
- The rulebook
- One written rulebook sets the structure, the vocabulary and what may be written. The AI that plans each document is given all of it, every time, and you can read it too.
- Ranked sources
- Where two systems disagree, one wins, and we write that down before the first sync. A person outranks every system.
- A person’s edit
- A value a person set by hand is left alone unless you have decided a system owns that field.
- Plan review
- A person approves the plan, sends it back with notes, or rejects it. Nobody admits their own submission.
- Sensitive data
- Blocked, not flagged. A submitted document is checked for card, bank account, passport and national ID numbers before any AI model reads it.
- Decision records
- What was decided, why, and what was superseded, dated and linked to the record it replaced.
Example authority map
| Type of fact | What wins |
|---|---|
| Live operational values | The data warehouse |
| What was agreed | The signed contract |
| How a system behaves | Production code |
| A person’s correction | Kept, and the next sync leaves it alone, unless you have decided a system owns that field |
Memory At Scale