Working with us
You have seen what it is.
Here is how we would start.
Eight decisions, made in order, before anything is provisioned. Every answer lands in one configuration file and one rulebook you can read. When they are made, the build is mostly mechanical, and the surprises left are the ones we have already written down.
- The shape of your businessThe nouns your business runs on: domains, programs, the spine.
- The dataWhere knowledge lives today, who holds the keys, what is wrong with it.
- Where it livesYour cloud, your repository, your sign-in.
- Risk and complianceWhat may never appear, and which sections are closed.
- GovernanceWho approves what, and what the engine may do alone.
- The AI, and what it costsWhose account, what drives the bill, and the levers.
- Build and launchNine milestones, the core live after six.
- Starting the flywheelUse writes the next page. A small rhythm on your side, and everything stays yours.
Step 1 of 8
The shape of your business.
The first conversation carves the knowledge up, because everything after it routes on that carving: who approves a page, who may read it, and where a submitted document lands.
- Domains. The three to nine bodies of knowledge the business runs on. Each gets a name, an audience and an approver. Folders say what the content is about, never who owns it.
- Programs and projects. The umbrellas and the initiatives under them: a controlled list a plan may propose additions to, never an emergent one.
- The spine. The per-unit thing you think in, if there is one: customers, sites, products. One folder per unit, and a stable code every connected system carries. It decides what the integrations can do.
- What it is not for. Personal notes, external documentation, meeting notes that carry no decision, drafts. Agreeing this early keeps the first month honest.
We will ask
- What are the three to nine bodies of knowledge the business runs on, and who says yes or no to a page in each?
- Which categories exist within each: projects, processes, runbooks, decisions, metrics?
- Is there a per-unit thing you think in? Its stable code, its master list, and which systems carry it?
- Who reads it, by role?
Step 2 of 8
The data.
The engine is only as good as what flows into it, so we map every place knowledge lives today, who holds the keys to each, and what is wrong with it.
- Two sources are always connected: documents and code. Everything else is a module we port when you have that system: the project tool, the warehouse, meeting notes, a cloud inventory.
- Ten file formats are read. Google Docs, Sheets and Slides, PDF, Word, Excel, PowerPoint, CSV, text and Markdown. A protected or oversized file is rejected with a reason, never passed along as garbage.
- Ranked sources. Where two systems disagree, one wins, and we write that down before the first sync. A field a machine owns is marked, so a person's edit is never silently overwritten.
- Known issues, 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.
- The first twenty. Of everything you have, the twenty documents everyone actually needs are the first week's reviews. If a wiki already exists, we port it.
We will ask
- Where do documents live? Is it Google Workspace, and can IT authorize read-only delegation?
- Where does code live, and which repositories should have pages?
- Which systems of record go stale fastest, who owns each credential, and what is the join key?
- How many documents exist, in what formats, and is there a wiki to port?
Step 3 of 8
Where it lives.
In a cloud project you own, under your billing, with the content in a private repository you own. We are granted access to build and operate it.
- Your cloud. Today the platform is built for Google Cloud: one project per client, created by us, owned by you. We check your organization's guardrails first; three of them changed how our own demo was built.
- Two ways to sign in. Google's own identity gate in front of the site, or your existing SSO proxy forwarding the identity. Chosen at discovery, never assumed. Roles inside the wiki are the wiki's own either way.
- Who may read. A whole email domain, a group, a named list, or whoever your proxy admits.
- Who holds the keys. Secrets live in your project's vault and are pasted in by a person, never through an agent session. We hold a break-glass identity, time-bound where your policy allows.
We will ask
- Does a Google Cloud organization and billing account exist, and which policies does it enforce?
- Who may read: a domain, a group, a list, or your existing SSO?
- What hostname, and who controls its DNS?
- Is there a GitHub organization we may create one private repository in?
Step 4 of 8
Risk and compliance.
What may never appear on the wiki is decided before the first document is submitted, because the engine enforces it on the way in, not after.
- Which regimes apply. Card payments, personal data by jurisdiction, health records. Each sets the detectors the sensitive-data scan runs with and the tags a page can declare.
- The scan. Every submitted document is scanned before anyone reads it, text and embedded images both. A hit blocks it. An image that cannot be scanned blocks it too.
- The forbidden list. Secrets; personal information beyond work emails; vendor spend, rates and hours; the gap between a stated date and a tracker's. Pipelines strip these before writing.
- Sections closed by role. A closed page is not served, not indexed and not quoted in an answer. By role, not by individual.
- Retention. Versioned content with a thirty-day window on superseded versions; intake files deleted after thirty days. Zero-data-retention terms are available from the AI provider if you require them.
We will ask
- Which regimes do you answer to?
- What may never be published, beyond the standard list?
- Which sections must be closed, and to which role are they open?
- Any retention requirement beyond the defaults?
Step 5 of 8
Governance.
The engine works under a written contract you can read, and the contract names a person for every decision that changes the shape of the knowledge.
- The rulebook. One document, rendered from your answers, that every agent loads before every operation. Versioned with the content: change a rule and the next run follows it.
- Two gates on every document. Admission: should we learn from this at all? Plan review: what will be created and what will change. Only then are the pages written, together, as one traceable change.
- What goes through unattended. Small plans from non-canonical sources that propose nothing new and raise no flag. A canonical document, or anything a person submitted, always waits for a person.
- Scheduled syncs commit with no person in the loop, kept safe by ranked sources, marked machine-owned fields, and sections only a machine may write.
- Decision records. What was decided, why, and what was superseded. The engine's own build is kept in sixty-one of them.
We will ask
- One approver per domain, or must admission and approval be different people?
- May low-risk updates go through unattended?
- Who may declare a new platform, integration, unit or tag?
Step 6 of 8
The AI, and what it costs.
The model is a choice we made, not a dependency you inherit, and the AI is billed to an account in your name.
- The model. It runs on Claude because that is what we chose. Three sizes do three kinds of work, and the assignment is a configuration line. It does not have to be Claude.
- Whose account. An AI account in your name: a clean data boundary, and we never hold your spend. A new account starts on low rate limits, so the bulk load goes through the batch interface.
- What drives the cost. Fixed cloud services first, the search index above all; then document volume, where the first month dwarfs steady state; then questions and syncs. The AI bill is not the dominant cost.
- The levers. Batch processing for bulk at half price, caching of the context every plan re-reads, the smallest model for answering, scale-to-zero where the wait is acceptable.
- Your staff's assistant. If your organization has Claude seats, the wiki can be registered as a connector, under the same section rules. Optional: search and Ask work without it.
We will ask
- Who owns the AI account and the cloud bill?
- Is zero-data-retention required? What is the budget for the bootstrap month?
- Do your staff use Claude or another assistant, and should it read the wiki?
- Where should notifications go: Slack, Discord or email?
Step 7 of 8
Build and launch.
A runbook with a gate at the end of every phase. A phase is done when the live system is read back and matches the plan, not when a command exits cleanly. For you, nine milestones, and at each one, one thing only you can do.
The decisions are made
Your answers render the configuration and the rulebook, and the content rules pass before anything deploys.
You the eight conversations, a private repository, an hour of your cloud administrator.
Your cloud is ready
Project, identities, buckets, search index and secret vaults, read back from the live system and matching the plan.
You accept the console terms, decide the sharing-policy exception, grant us access.
The site is up, behind your sign-in
First deploy, then the perimeter. A member is in silently; a non-member is refused; the raw address refuses.
You seed the access group, or point DNS and your proxy at it.
Search and Ask work
The first admin signs in, roles are seeded, content is indexed. Search returns pages; Ask answers with sources.
You name one approver per domain, and the wiki admin.
The first document goes through
Scan, admission, plan, review, write, commit, publish: one traceable change, the page rendered, the log written.
You paste the AI key and the git token, submit a real document, approve its plan.
Live
The operating process is agreed and approver roles granted. From here the wiki grows with use.
You the wiki admin takes the plan reviews and the feedback queue.
Keep-current connections, one at a time
Code, document changes, people, then each module: one watched run each, and a hand edit must survive the next.
You one read-only credential per system.
Your backlog is loaded
The corpus goes through the batch interface. Twenty are reviewed by hand; the rest update pages rather than duplicate them.
You the document list, and the review hours for the first twenty.
Your assistant reads it
The wiki is registered as a connector. It answers a question and cites the pages it used.
You a Claude admin registers the connector. Optional.
The schedule is set by the hand-offs, not by the build. Our own demo went from decisions to a signed-in first user in an evening, then waited two weeks on one console step only a person could do. That is why every one of those steps is written down with its exact clicks, and why we do not quote a date before discovery.
Step 8 of 8
Starting the flywheel.
Living with it is where the flywheel starts. What people ask shows what to write next, the next page earns more use, and the memory moves from a person to the wiki. A small rhythm on your side keeps it turning, we tend the engine, and everything it holds stays yours.
Your roles
- 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.
The rhythm
- As they arrive
- Plan reviews, in the app and in your channel. A review is a few minutes.
- Weekly
- The lint report and the questions the wiki could not answer well: the first keeps the graph clean, the second is the list of what to write next.
- Quarterly
- The ranked sources and the forbidden list, re-read against what has changed in the business.
- Ours, throughout
- The connections, the deploys, the contract changes you ask for, a new module when you add a system. Named sessions, reviewed and merged, a log entry each time.
The content is a repository you own, and the platform source is in it. The cloud project, the secrets, the index and the AI account are in your name. If we stopped working together, you would keep everything.
Before the first conversation
Bring this.
Eight things, one per step. 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.
Memory At Scale