M Made Scientific MADE OS · 04 · Context

Context

The grounding layer. Without it every agent is a well-spoken stranger: fluent, confident, and wrong about your business. Context is what makes an answer specific to Made — the databases that hold what is true, the brain that retrieves it, the wiki that explains it, and the brand pack that makes output look like it came from here.

Mapped 2026-08-04. The one rule: authored in git, retrieved from Postgres.
The rule that keeps this layer from rotting

Authored in git. Retrieved from Postgres. Never the other way round.

Context has one failure mode above all others: two copies that disagree. A wiki page says the resolver runs at 07:00, the crontab says 09:00, and now every agent grounded on the wiki is subtly wrong. (That is a real example — see R-02.)

So the discipline is directional. Humans write context as markdown in a git repo, where it can be reviewed, diffed and blamed. Machines read it from Postgres, where it can be embedded, filtered and joined. The database is a projection of the repo, never a second source of truth. Anything that edits context directly in the database has created a fork nobody will notice.

Corollary: if a number appears on a page like this one, it must be re-queried, not carried forward. Every figure on this site was re-queried on 2026-08-04 for exactly that reason.

Databases
7
Supabase projects
Canonical companies
4,595
on Transfer
Canonical contacts
102,529
100% carry a MADE-ID
Cross-system ID map
108,415
mappings
Learned name aliases
1,425
accumulated by hand + agent
Unreviewed proposals
2,335
nobody answered
Layer 1 · the databases

Which database is truth for what

Seven Supabase projects is a lot of boundaries, and each boundary is somewhere an identity can fail to line up. This table is the answer to "where do I look for X" — and the reason identity resolution is the most engineered part of the skill library.

DatabaseTruth forOwnerNote
Transfer
jrfcfayphcmaxsixxupu
Canonical companies + contacts + MADE-ID. The commercial engine. Also holds the os_* registry that this whole site reads. BioCreative 4,595 companies · 102,529 contacts · 404 opportunities · 178 campaigns
Reporting / CRM
xyopyttkhoxvnyeyijzb
External CRM truth as-is. sfdc_accounts, hubspot_companies, hubspot_contacts, hubspot_forms. Landing zone, not canonical. Made / Joe 17,653 HubSpot contacts · 26 forms · nightly sync
made-ai-os Joe's skill + agent authoring loop. The upstream that os_* mirrors. Made / Joe Canonical for authoring. The OS reads the mirror, never writes here.
BioCreative hubThe BC side of the ID bridge; shared life-sciences universe.BioCreative3,302 bc_hub ID mappings
Revenue ForecastingForecast warehouse.Made
Monday SyncMonday board mirror — OKRs, tasks.Made
Contracts · RFP IntakeAgreements; inbound RFP capture.MadeRFP Intake will be GATEKEEPER's input when built.
The one-sentence version: Reporting is what the CRMs say. Transfer is what we have decided is true. made-ai-os is how we build. Everything else is a specialised store.
Layer 2 · the identity spine

MADE-ID — one stable ID, and everything keys on it

This is the single highest-value piece of context Made owns, and it is genuinely good. Coverage is complete on both sides. It is also where the honest limits are sharpest, so both are below.

STRONG

The graph is real and complete

Verified
What existsEvery account and contact carries a canonical MADE-ID. A single cross-system map crosswalks HubSpot, Salesforce, LinkedIn-sourced and BC-outreach IDs onto it. One RPC — monocle_contact() — returns the whole picture for a person: their company, tier, every external ID, every opportunity, every campaign.
Accounts with a canonical ID4,595 · 100%
Contacts with a canonical ID102,529 · 100%
ID mappings108,415
Learned name aliases1,425
Why agents get this for free. An inbound email from someone met at ISCT two years ago, or who sat in a 2024 Salesforce campaign, resolves. Any new agent should call monocle_*, never rebuild it — a second relationship layer is a second source of truth.

Discipline worth notingExact matches merge automatically; anything ambiguous becomes a proposal for a human, never a silent guess. That is why a match can be trusted.

HONEST LIMIT

The structure is excellent. Some of the content is thin.

Known, quantified

Three specific thinnesses 2,335 unreviewed resolution proposals — the system asked "is this the same company?" 2,335 times and nobody answered. Each is a possible duplicate or unlinked account.

The 31% rollup gap — roughly a third of CRM contacts carry a MADE-ID but resolve to no company, understating every account-level engagement metric by about a third. Gates campaign attribution.

17 derived customers out of 4,595 accounts, and opportunity-to-contact resolution around 22%.

Unreviewed proposals2,335
Contacts with no company~31%
Opp→contact resolution~22%
These are CRM data questions, not architecture questions — and all three are Tier 2: documented, quantified, named in a skill, and nobody is pretending otherwise. contact_account_rollup exists specifically to close the 31%.

The one that compoundsThe 2,335 unreviewed proposals. A review queue nobody drains stops being a queue and becomes a backlog that makes the graph quietly worse.

R-06

The learning loop is wired and has never fired

Believed workinger_learned_rules
What the data showser_decisions holds 1,778 recorded human decisions about identity matches. er_learned_rules holds zero rows. Decisions are being captured faithfully and no rule has ever been promoted from them.

Why this is red and not futureBecause the loop is described as closed. The design is "corrections feed back into the logic" — and the correction table is full while the logic table is empty. Anyone reading the architecture would reasonably believe the system is learning from 1,778 human judgements. It is not learning from any of them.

Human decisions recorded1,778
Rules ever promoted0
A log nobody harvests is half the value at full cost. Every one of those 1,778 decisions cost human attention. The capture half works perfectly; the promotion half was never built or never run.

Decision neededEither build the promotion pass, or stop describing the loop as closed. The second is free and instantly makes the docs true.

GOOD

Propose-only is the house pattern, and it holds

Verified across 4 agents

The patternAgents that touch canonical data propose; humans confirm. RESOLVER, MADE-ID CUSTODIAN, the Account Atlas status mapper and CHIEF's dispatch routes are all propose-only. Nothing auto-merges an ambiguous identity, and nothing auto-writes a relationship status.

Why it's worth the frictionThe alternative was tried elsewhere and produced silent corruption that took weeks to find. A proposal queue that's too long is annoying. A wrongly-merged company is a data-integrity incident that shows up as a bad number in a board deck.

The trade-off is explicit and accepted: propose-only is why there are 2,335 unreviewed proposals. That backlog is the cost of the guarantee, not a failure of it. The fix is a faster review surface, never auto-confirmation.

Inherited byEvery new agent, by default. Overriding it requires a reason.

Layer 3 · retrieval

The brain — how context reaches an agent

Storing context is not the same as an agent being able to use it. Three surfaces do the retrieval, and they are deliberately layered so that a cheap question doesn't pay for an expensive one.

Retrieval

From a question to a grounded answer

Container brain-api-made + litellm-made on bc-made, fronted by public RAG Edge Functions.
01
Structured lookup
SQL and RPCs against Transfer. monocle_contact(), territory, tier, opportunity history.
Free · exact
02
Vector retrieval
Embedded documents — research, transcripts, wiki, brand. Answers "what do we know about this."
Cheap · fuzzy
03
Synthesis
Claude, given only what the first two steps returned. Grounded, not free-associating.
Metered
04
Surfaced
MADE BRAIN chat, CHIEF's brain route, or an agent calling it as a step.
Free
The ordering is the whole design. Structured lookup first because it is exact and free; vector retrieval second because it is cheap and approximate; the model last, and only over what the first two returned. Invert this and you get a confident essay instead of an answer — which is the single most common way an "AI agent" fails in a business setting.
Layer 4 · the written layer

What humans author, and where

All of it markdown in git, all of it reviewable, all of it embedded into the brain on a sync. This is the layer that decides whether an agent sounds like Made or like a chatbot.

BodyWhereWhat it grounds
The wikiwiki/concepts/, entities/, systems/, reference/How the platform works. Karpathy-style navigable notes with an INDEX front door. The place an agent goes to learn what a "buyer segment" is here.
Company braindocs/company-brain-depth/Seed source matrix, brain contract schema, the BC↔Made delegation spec. What the company is, as opposed to what its database contains.
Brand packbrands/made-scientific/ + made-original, made-regen, partner-neutralTokens, palette, fonts, voice, imagery direction. Four packs — the reason a Regen deliverable and a Made deliverable look correctly different.
Skillsskills/ + Joe's made-ai-os loopExecutable instruction sets. See the Skill Library.
Segment + ICP contextbuyer segments, personas, scoring rubricsWho Made sells to and how they're ranked. Consumed by SSO AGENT's ICP gate.
Diagram pagesbrands/made-scientific/diagrams/workflows/The four live-verified explainer pages (lifecycle, data inputs, CRM mapping, BEACON). Human-facing, not embedded — and each carries a verification date because they go stale.
The diagram pages are the honest exception to "authored in git, retrieved from Postgres." They're hand-authored HTML with numbers baked in, so they cannot self-refresh. That's why every one of them — including this site — carries a verification date in the footer. A page without one should be assumed stale.
What good looks like here

Context is the cheapest layer to improve and the easiest to let rot

Nothing on this page needs a new model, a new harness or a new container. The identity graph is complete. The retrieval stack works. The written layer exists and is reviewable. The gaps are: 2,335 proposals nobody answered, 1,778 decisions nobody harvested, and 31% of contacts with no company.

All three are review-and-drain problems, not build problems. And all three get worse silently — which is the defining property of this layer. An agent that breaks throws an error. Context that decays just makes every answer slightly less right, and nobody notices for a quarter.

The one red item — the empty er_learned_rules table under a closed-loop description — is on this page rather than the fleet page for exactly that reason. It is a documentation claim that outran the implementation, and it costs nothing to make honest.