System map · the complete set
Eight maps of the same machine, stacked end to end. What we hold on a client and where the gaps are, how a review or a phone call finds its way in, how a post gets made and sent back out, and what it all looks like running at once.
A single page per client showing every source the agency has connected, every source it has not, and exactly how much has actually come through. Three clients here, at three different stages of onboarding.
standalone version →an illustrative view — the clients below are invented
Five layers, split by what the data is rather than by which vendor it came from. Every row in every layer carries the client it belongs to, and the database itself refuses a read or a write that crosses that line.
Name, address, phone, service area, timezone, brand palette, and where its site and files live. Small, hand-curated, and the row everything else hangs off.
One credential per thing the client already owns — their listing, their page, their ad account, their CRM. Encrypted at rest and decrypted only at the moment of the call. Never stored in a repo.
One table for every synced fact — reviews, ad numbers, conversations, form fills, visits.
A kind column tells them apart. Plus the identity graph, because
the same person is a CRM contact and a Facebook commenter and a Google reviewer, with
three different IDs.
Before-and-afters, phone video, raw uploads, logo files. The bytes never go in the database and never go in git — the row holds a bucket and a key and nothing else.
Text chunks with their embeddings sitting in the same database as the rows they describe, so one query can filter by client, filter by rating, and search by meaning at the same time. Plus the compiled brief a person can review before it ships.
Append-only. Every sync, every generated draft, every write. This is what lets you change your mind about the structure later without losing the history.
When a platform adds a field, or you decide six months in that you want sentiment on every conversation, you add a column and backfill from what you already stored. No re-fetch, no rate limits, no data you threw away because it did not fit the schema you had on the day you wrote it.
bright · tenant
tenants
tenants.brand
No palette captured. Pull it from the site stylesheet or the brand kit.
connections
Nothing linked.
facts kind=gbp_snapshot
No connection for this yet.
facts kind=review
No connection for this yet.
facts kind=post
No connection for this yet.
facts kind=ad_metric
No connection for this yet.
facts kind=message
No connection for this yet.
facts kind=form_submission
No connection for this yet.
facts kind=site_visit
No connection for this yet.
facts kind=keyword
No connection for this yet.
assets
No connection for this yet.
chunks
Connected, but this has never been pulled.
handy · tenant
tenants
tenants.brand
connections
agency/handyactivehttps://handyhome.exampleactivefacts kind=gbp_snapshot
Connected, but this has never been pulled.
facts kind=review
Connected, but this has never been pulled.
facts kind=post
Connected, but this has never been pulled.
facts kind=ad_metric
Connected, but this has never been pulled.
facts kind=message
facts kind=form_submission
facts kind=site_visit
facts kind=keyword
Connected, but this has never been pulled.
assets
No connection for this yet.
chunks
Connected, but this has never been pulled.
summit · tenant
tenants
tenants.brand
connections
agency/summitactivehttps://summitkarting.exampleactivefacts kind=gbp_snapshot
facts kind=review
facts kind=post
facts kind=ad_metric
facts kind=message
facts kind=form_submission
facts kind=site_visit
facts kind=keyword
assets
chunks
Everything a business touches flows into one brain — reviews, phone calls, text threads, job photos, what people did on the website. Agents read from it and publish back out to the same platforms the facts came from. And here is the part that makes it an ecosystem rather than a funnel: every post that goes out lands back in as a row, so next week the system already knows what it said.
standalone version →↔ swipe the diagram
Google is where the reviews come from and where the posts go. Same for Facebook and the website. The marks on those boxes are not decoration — the arrow genuinely goes both ways, which is the difference between a feed and an ecosystem.
The job publisher does not tell the weekly agent what it posted. It does not have to. Both write to the same table and both read the same table, so the handoff is the database rather than a message between two systems that have to stay in sync.
A post that goes out and is forgotten is how you end up saying the same thing in week three and week eleven. Because published posts come back in as rows, "have we said this already" is a query, and next week's agent starts smarter than this week's did.
Six streams in, four readers, four places to publish, and one return path. None
of the streams know about each other. A review, a phone call, a text thread, a photo from a
driveway, a form submission, and a post that went out last Tuesday all land in
facts as rows that differ only by their kind. That is the
entire trick. Because they share one table, an agent writing Tuesday's post can read
Monday's phone call, the service area, the brand voice, and every post already published — in
one query, with none of it typed in twice.
Sources push and we pull — conversations, reviews, paid spend, organic performance. Replies and posts flow back out. One Postgres hub, sealed per tenant, feeding every human and AI reader from the same rows.
standalone version →Somebody finishes a job happy and leaves five stars. That review lives on Google, not in our database — so once a day we go out and bring it home. Here is the whole trip.
standalone version →The pull runs once a day on a schedule, not the instant the review appears —
so a morning review shows up the next time the job runs. It is safe to run over and over:
each review is matched on its own id, so re-running updates what changed and adds what is
new, and never creates a duplicate. Same trip for the profile itself — hours, categories,
service area — which is why the database can answer what are your hours
without anyone ever retyping them.
Nobody writes this post. A customer asks a good question on the phone, the answer gets stored, and two days later an agent goes looking for exactly that kind of moment and writes it up. Here is the whole loop.
standalone version →Somebody called this week and asked do you do drywall, or just demolition?
Both. Usually on the same job.
She wanted a wall gone and did not know what was behind it. We spent a few minutes on the phone working out what was load bearing, what it costs to find out, and which parts she could handle herself.
If you have been staring at a wall for a year, that call is free.
The interesting part is not the automation, it is the source material. A
social post invented out of thin air sounds like it was invented out of thin air. A post
built from a question a real person actually asked on the phone lands differently, because
somebody else was already wondering the same thing. The transcripts sit in
facts next to the reviews and the jobs, so the agent that writes the post is
reading from the same brain that knows the service area and the phone number.
One publisher runs off Wayne's camera roll — he finishes a job, uploads photos, and the system writes it up. The other wakes up once a week, goes through the phone calls, and finds something worth saying that nobody thought to write down. Both check the brain first so they never post the same thing twice.
standalone version →↔ swipe the diagram
Finished a full bathroom remodel in Springville this week. New tile, new vanity, and a floor that is finally level.
Six photos, before and after, in the comments.
Somebody called this week and asked whether we do drywall or just demolition. Both, usually on the same job.
She wanted a wall gone and did not know what was behind it. That call is free.
The second publisher is the interesting one, and the check in the middle is why.
Before it writes anything it reads every post that has already gone out, so week eleven does not
quietly repeat week three. That check is only possible because the posts live in the same place
as the calls and the jobs — a social_post row sits next to a
call_transcript row, so "have we said this already" is a query rather than somebody
scrolling back through a Facebook page trying to remember.
Every client gets a channel and a brain of its own. Somebody on the team types a question in a client's room and the answer comes back from that client's data — never from anyone else's. Multiply the whole picture by however many clients you have; the shape does not change.
standalone version →↔ swipe the diagram
Which channel the question was typed in decides which brain answers. Nobody picks a client from a dropdown and nobody can forget to. Ask in Wayne's room, get Wayne's numbers.
Each client's connections belong to that client — his listing, his page token, his phone number, his domain. The agency room holds the agency's own tools. The two never mix, which is what makes handing a client back to them a real possibility instead of a painful unwind.
Nothing in this picture is per-client code. Adding a business means a new room and a new tenant row. The loaders, the agents, and the seal all work the same on day one as they do on client forty.
The interesting question is not how the answer gets written, it is how the system
knows whose data to read. Here the channel carries the tenant. A question typed in
#all-things-handy is scoped to Wayne before it reaches the database, and the
database refuses to return anyone else's rows even if something upstream got it wrong — that is
what the dotted line to the other brain means. SET LOCAL app.tenant_id is a
belt, and row-level security is the suspenders.
A review lands on Google. A customer calls and the voice AI takes it. Messages come and go all day. Wayne uploads photos from a driveway. All of it flows into one brain — and on Tuesday afternoon something reaches back in and writes a post out of it.
standalone version →↔ swipe the diagram
Somebody called this week and asked do you do drywall, or just demolition?
Both. Usually on the same job.
She wanted a wall gone and did not know what was behind it. We spent a few minutes on the phone working out what was load bearing, what it costs to find out, and which parts she could handle herself.
If you have been staring at a wall for a year, that call is free.
Four streams in, three readers out, one brain in the middle. The streams do not
know about each other and do not need to — a review, a phone call, a text thread, and a photo
from a driveway all land in facts as rows with a different kind. That
is the whole trick. Because they share a table, the thing that writes Tuesday's post can read a
Monday phone call and the service area and the brand voice in one query, and none of it had to
be typed in twice.