Memory At Scale
Anyone can build a knowledge base.
Scaling is hard.
We implement an institutional knowledge engine inside your business: a knowledge base that documents itself, under rules you can read, in a cloud you own.
- Documents
- Code repositories
- Project boards
- Data warehouse
- Meeting notes
mematscale
plan · review · write
- A wiki, by area
- Instant search
- Answers, with sources
- Your AI assistant
The problem
A repository on its own doesn’t unlock anything.
Every company has tried a wiki, and plenty of developers have built their own knowledge repository. The knowledge is still locked up, for the same three reasons every time.
- It lives everywhere else. Contracts sit in shared drives, decisions in meeting notes, and the real behaviour of a system in its code. Nobody has time to copy it all into one place, so nobody does.
- It goes stale. A page is right on the day it is written. The source keeps changing and the page doesn't. After the first wrong answer, people stop trusting any of it.
- It doesn't survive growth. One person's notes work for one person. Add teams, clients and years, and you get duplicate pages, competing versions of the truth, and no record of who decided what.
What it takes · 1 of 3
Auto-documentation
It writes itself, and keeps itself current.
- The systems you connect are re-read on a schedule: project boards and the data warehouse every day, code repositories every week.
- It only does work when something has changed. A repository is re-documented when it has new commits. A document already in the knowledge base is picked up again when its text changes, not its formatting.
- Meeting notes are filed as pages the same day.
- It reads what people really submit: documents, spreadsheets with every tab, slides and PDFs, along with the diagrams and images inside them.
- Where a source is already structured, plain code does the work and no AI is involved. That keeps it exact, and cheap.
- Pages carry their sources and the date they last changed. A page that came from a document also names who wrote it, who submitted it and who approved it.
Refunds
Active as of 12 March
Payment terms synced from the warehouse
Escalation contact set by a person · kept
- Source
- Refund policy, revised.docx
- Written by
- Document owner
- Submitted by
- Operations
- Approved by
- Finance approver
Linked from 6 pages
What it takes · 2 of 3
Governance
Every write has a rule behind it, and a person where it matters.
- 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.
- A submitted document becomes a plan before it becomes pages. The plan says what will be created and what will change, and flags anything new or unclear.
- A person approves the plan, sends it back with notes, or rejects it. Nobody admits their own submission, and a document that touches several departments needs each of them.
- Connected systems sync on their own, on purpose. What keeps that safe: each synced field records where it came from, the sources are ranked, and a value a person set by hand is left alone unless you have decided a system owns that field.
- A system or a repository is only read once a person has switched it on.
- Sensitive data is blocked, not flagged. A submitted document is checked for card, bank account, passport and national ID numbers before any AI model reads it, and an image that cannot be scanned keeps the document out.
- Every release is checked first. One broken link holds the whole release back.
- Readers can report a problem on any page. The fix goes through the same review.
Source
Refund policy, revised.docx
- 1
- page to create
- 3
- pages to update
- 1
- new name proposed
Needs a decision
Proposes a new name, “Refund desk”. Closest existing: “Customer refunds”.
Waiting on Finance approver
What it takes · 3 of 3
Sovereignty
It is yours. All of it.
- The knowledge is plain text files in your own repository, with their full history. There is no proprietary format to get out of.
- It runs in your cloud project, behind your sign-in, open only to the group you choose.
- Keys and credentials stay in your own secret manager.
- AI usage is billed to your own account. We don't resell it.
- A document is read as the person who submitted it, so the engine sees only what they are allowed to see.
- A section can be closed to its own readers, by role — one group may read it, another approves it. The limit is enforced before the page is served, and binds the search box and the AI too.
- Your AI assistant gets read-only access. Your data warehouse is reached through a read-only role, limited to the views you approve.
- If we stopped working together tomorrow, you would keep everything, and it would keep running.
- The knowledge
- Text files in your git repository
- The running system
- Your cloud project
- Who can get in
- Your sign-in, your access group
- Keys and credentials
- Your secret manager
- AI usage
- Your own account, billed to you
- Approvals and settings
- A database in your cloud project
Worth singling out
The decision record.
Most documentation says what is true today. A decision record says why, and what else was on the table.
- One page for each decision that matters: the situation that forced it, the options that were on the table, what was chosen, and what that made easier and harder.
- It is dated and it carries a status: proposed, accepted, deprecated or superseded.
- When a decision changes, a new record supersedes the old one and the two are linked, so the reasoning of the time is still there to read.
- Each record is tied to the system it is about, and links to the projects and the sources behind it.
- The engine drafts them from the documents and meetings where decisions actually get made. A person approves the plan, as with any other page.
- Ask why something is the way it is, and the answer names the record.
- The engine's own history is kept this way: 61 decision records, from the review gate to the choice of search.
Refunds over $500 need a second approver
acceptedDecided 12 March · Finance
- Context
- Disputed refunds doubled after the policy changed.
- Options considered
- Keep a single approver · A second approver over $500 · A manager for every refund
- Consequences
- Large refunds take a day longer. Fewer are reversed.
Supersedes Refund approvals (2023)
How it works
From a document to an answer.
Then the source changes, and it starts again by itself.
Submit or sync
Someone submits a document, or a scheduled sync finds a change in a connected system.
Admit
A second person confirms a submitted document belongs in the knowledge base.
Scan
It is checked for card, bank and identity numbers before any AI model reads it.
Plan
The engine reads it against the rulebook and the list of pages that already exist, and proposes what to create and what to update.
Review
The right approver sees the plan and approves it, rejects it, or sends it back with notes.
Write
The pages are written and committed together, as one change you can trace and undo.
Check
The whole knowledge base is checked for broken links and loose ends before release.
Ask
People browse it, search it and ask it questions. The answers name the pages they came from.
Why scale matters
A repository holds knowledge. An engine keeps it true.
The difference doesn’t show with one author and fifty pages. It shows with ten teams and two thousand.
Who writes it
RepositoryWhoever remembers to
EnginePipelines, on a schedule, from the sources
What stops a wrong page
RepositoryNothing
EngineA plan a person approves, then an automatic check
Where a page came from
RepositoryNobody knows
EngineRecorded: the source, the submitter, the approver
When the source changes
RepositoryThe page stays as it was
EngineThe change is detected and the page is updated
When two sources disagree
RepositoryWhoever edited last wins
EngineA fixed ranking decides, and a person outranks every system
Why it was done this way
RepositoryWhoever decided has left
EngineA dated record, with the options that were turned down
Names and structure
RepositoryEach author's own
EngineOne controlled vocabulary
Who can approve
RepositoryEveryone, or no one
EngineNamed roles for each team, enforced on the server
Who owns it
RepositoryWhoever hosts the tool
EngineYou
| Question | A developer’s repository | A knowledge engine |
|---|---|---|
| Who writes it | Whoever remembers to | Pipelines, on a schedule, from the sources |
| What stops a wrong page | Nothing | A plan a person approves, then an automatic check |
| Where a page came from | Nobody knows | Recorded: the source, the submitter, the approver |
| When the source changes | The page stays as it was | The change is detected and the page is updated |
| When two sources disagree | Whoever edited last wins | A fixed ranking decides, and a person outranks every system |
| Why it was done this way | Whoever decided has left | A dated record, with the options that were turned down |
| Names and structure | Each author's own | One controlled vocabulary |
| Who can approve | Everyone, or no one | Named roles for each team, enforced on the server |
| Who owns it | Whoever hosts the tool | You |
Where it comes from
Built from one that already runs.
The engine we implement was not designed on a whiteboard. It comes from a knowledge base that runs inside a working company today.
- pages
- 1,600+
- jobs running on a schedule
- 24
- file formats read
- 10
- problems caught by the first release check
- 888
What scaling it taught us
The first release check found 888 problems.
They were spread across 779 pages, and 629 of them were broken links. Nothing had been checking. Now nothing is released until the check passes.
Three of ten file formats were being read properly.
PDFs and Word files were reaching the AI as garbage, and spreadsheets lost every tab but the first. Each format now has its own reader, and a bad extraction is rejected instead of passed along.
The AI invented pages that already existed.
It did not know which pages were there, so it made new ones instead of updating the real ones. It is now given the full list, and every write checks its own result.
A question that should have listed everything listed some.
Asking which clients share a property returned part of the answer, because the facts sat where search could not see them. List and count questions now have their own path, and it returns the complete set.
What it already connects to
- Documents
- Google Drive: Docs, Sheets, Slides, PDFs and Office files, with a weekly check for changes.
- Project boards
- Monday.com: client records, programmes, tickets, the roadmap and sprints, every day.
- Data warehouse
- Snowflake: figures on pages every day, a data dictionary, and a guarded query tool for AI assistants.
- Code
- GitHub: one page per repository, rewritten in the week its code changes.
- Meeting notes
- Google Meet notes: stand-ups and planning sessions, filed the same day.
- Cloud estate
- Azure: a weekly inventory of what is running, and data pipelines documented from their own definitions.
- AI assistants
- Claude, through a read-only connector, and Snowflake's own agents the other way round.
Other tools fill the same slots. Each one is a connector we scope with you in discovery.
The first one was built the hard way, one lesson at a time. Yours starts from all of them.
What your people get
One knowledge base, four ways in.
The questions it cannot answer are kept, and become the list of what to document next.
A wiki, by area
Each part of the business has its own section and its own front page.
Instant search
Results as you type, matched on titles, tags and the opening of every page.
Answers, with sources
Ask in plain language, by typing or by voice, and get an answer that names the pages it came from.
Your AI assistant
A standard connector (MCP) lets the assistant your staff already use search and read the knowledge base. It cannot write to it.
Working with us
We build it with you, in your environment.
Discover
We map where your knowledge lives, who owns which part of it, and the words your business uses for things.
Foundation
We stand the engine up in your cloud, behind your sign-in, with your people in the approver roles.
First loop
One real document goes all the way through, from submission to a published page, with your reviewers.
Connect
We switch on your systems one at a time, and watch each one run before starting the next.
Load
We bring in the documents you already have, with your people approving what goes in.
Operate
We run and curate it with you, or hand it over to your team. Either way it stays yours.
Straight answers
What people ask us first.
- What does it run on?
- 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.
- Does a person check everything it writes?
- No, and we would rather say so. For a document, a person approves the plan: what will be created and what will change. The words are written after that. Data synced from your own systems is not approved item by item; it is kept in its lane by the ranking of sources and by sections only a machine may write.
- Who can see what?
- Access is set by section, through roles. Each section has its own approvers, and a section can have its own viewers, so one like HR can be limited to the people who should see it. You decide who holds which role.
- Which AI does it use?
- Claude, from Anthropic, through an account in your name. That is the model we chose, not one the engine depends on: it does not have to be Claude. Different jobs use different sizes of model, and a good share of the work uses none at all.
- What does it cost to run?
- The running costs are your own cloud and AI usage, billed to you directly. They depend on how much you load and how many systems you connect, so we estimate them with you during discovery, before anything is built.
- How long does it take?
- 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.
- What happens when the AI gets something wrong?
- It will. That is what the plan review, the release check and the report button on every page are for. A correction a person makes is recorded as theirs, so the next sync leaves it alone.
What does it run on?
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.
Does a person check everything it writes?
No, and we would rather say so. For a document, a person approves the plan: what will be created and what will change. The words are written after that. Data synced from your own systems is not approved item by item; it is kept in its lane by the ranking of sources and by sections only a machine may write.
Who can see what?
Access is set by section, through roles. Each section has its own approvers, and a section can have its own viewers, so one like HR can be limited to the people who should see it. You decide who holds which role.
Which AI does it use?
Claude, from Anthropic, through an account in your name. That is the model we chose, not one the engine depends on: it does not have to be Claude. Different jobs use different sizes of model, and a good share of the work uses none at all.
What does it cost to run?
The running costs are your own cloud and AI usage, billed to you directly. They depend on how much you load and how many systems you connect, so we estimate them with you during discovery, before anything is built.
How long does it take?
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.
What happens when the AI gets something wrong?
It will. That is what the plan review, the release check and the report button on every page are for. A correction a person makes is recorded as theirs, so the next sync leaves it alone.
Start here
Tell us where your knowledge is stuck.
A few lines is enough: what you do, where the knowledge lives now, and what goes wrong because of it. We’ll reply by email.
Memory At Scale
Where would you like to go?
- Talk to usTell us where your knowledge is stuck. A few lines is enough.
- The storyWhy institutional memory: from finding anything at all to the memory flywheel.
- How we would startEight decisions we make with you, in order, before anything is built.
- The openingBack to the very start, where the dots fall in.