How Everything Fits: The Architecture Behind Our Knowledge, Assets, Agents, and Code
Tier: Public | Owner: Dennis | Last reviewed: 2026-08-15
Most of our team has been handed one component at a time — a tier, a repo, a skill file, a propagation rule — without ever being shown the machine those parts belong to. This is the machine.
Nobody can operate a system they have never seen whole
We have thirteen Spotlight domains, a task library in the low hundreds, thirty-one scheduled agents, a knowledge base with four permission tiers, two Git hosts, a Basecamp project per client, and a weekly rhythm that ties all of it together. Every one of those pieces has been explained somewhere. The whole has not.
That is a real failure, and it is ours, not the team’s. When someone is shown the tier decision guide without the promotion path, or the master-first propagation rule without the component library, or SKILL.md without CCS, the honest reaction is the one we keep getting: I understand it conceptually and I can see applications to my current work, but I’m sure there are other things I’m not picking up. That is not a comprehension problem. That is an architecture that was never drawn.
So here is the drawing. It is public on purpose. You do not need to be an architect to do excellent work here, but the people who want to go deeper — current team, future team, and anyone who wants to build the same thing for their own business — should be able to read the blueprint without asking permission.
Scope note: This article describes the intended architecture and states plainly where reality has not caught up to it. Sections marked as gaps are open, not aspirational prose. Counts and dates carry the day they were observed.
Everything anchors to the 9 Triangles, including the parts that look purely technical
The 9 Triangles is not a marketing framework we bolt onto client work. It is the reason our infrastructure is shaped the way it is. If you know the triangles, the architecture stops looking like a pile of tools and starts looking like one argument.
Three of them do most of the load-bearing here.
CCS — Content · Checklist · Software. Turn knowledge into content, content into a checklist, a checklist into software. You cannot write a useful checklist for something you have not documented as content, and you cannot write software for something you have not reduced to a checklist. This is the entire pipeline from an office-hours answer to a SKILL.md file to a scheduled agent. Every layer of our stack is CCS caught at a different stage of hardening.
LDT — Learn · Do · Teach. You learn from someone who has done it, you do it yourself, and only after you have done it successfully three times are you equipped to teach. This is why our knowledge tiers run outward rather than inward, and why office hours produce course material rather than the reverse.
MAA — Metrics · Analysis · Action. Gathering metrics is not analysis, and analysis is not action. This is the weekly loop that keeps the whole system from silting up — applied to campaigns, to the agent portfolio, and to the propagation registry alike.
The others are present too, and worth naming so the map is complete. SBP (Specialist · Business · Partner) is why the public tier exists at all. GCT (Goals · Content · Targeting) is the shape of every client engagement. AEC (Audience · Engagement · Conversion) is what the Money Tree measures. CID (Communicate · Iterate · Delegate) — always post your work — is the rule that makes Basecamp threads mandatory rather than optional. DDD (Do · Delegate · Delete) is triage, and increasingly the “delegate” leg means an agent. MOF (Marketing · Operations · Finance) is the balance check on the whole business.
If a proposed change to our infrastructure cannot be traced back to one of those nine, it is probably a preference rather than a principle, and we should say so out loud before we build it.
Five stores, one system, one rule about which is true
Assets do not live in one place, and they should not. What matters is that each store has exactly one job and that nothing has two homes.
Google Drive holds knowledge. Documents, playbooks, SOPs, templates, context packs, client records. Permissions are mature and free in Drive, so access control lives here and nowhere else.
GitLab holds code, agents, and decisions. agent-runtime — 9,396 files at last push, re-synced and pushed by a nightly job — is the audit ledger for all thirty-one scheduled agents. dennis-os (63 files) holds the operating instructions. Second Ring’s engineering source lives in its own project with CI definitions, privacy-aware issue templates, and migration-drift checks. Decisions that affect code belong in the merge request, not in a meeting.
Basecamp holds work and approvals. Business truth: what the client asked for, what we promised, who signed off. Clients on the learn-alongside path are copied on the working threads so they see how the work actually happens rather than a summary of it. That is CID made structural.
The Spotlight Network holds published assets. Thirteen domains — checked against registrar RDAP records and the GoDaddy portfolio on August 3, 2026, and re-verified against every live site on August 10 — running one component library with industry skins. The registry is the source of truth for what exists and what state it is in.
The entity layer holds proof. Knowledge panels, schema, Wikidata, citations, and positive mentions. This is the only store we do not own, which is exactly why it is the one that counts.
The rule that keeps five stores from becoming five contradictions: cross-link, never duplicate. A Basecamp thread links to the merge request; the merge request links to the Doc; the Doc links to the published article; the published article links back to the Doc. When two systems both claim to be true about the same fact, we have not built redundancy, we have built an argument that will be settled by whoever is loudest.
Knowledge is tiered by one question asked twice
Four numbered folders, and the number tells you how wide the audience is.
00-Governance holds the rules of the library. 01-Public holds the master copies of what we publish to the website. 02-Members holds playbooks, SOPs, and templates. 03-Team holds client records, pricing, internal SOPs, and the context packs we pin into every AI project.
The classification test is one question asked twice. Would we be comfortable if this appeared, attributed to us, on the open internet? If yes, it is Public. If no: would we be comfortable if a member forwarded it to a friend? If yes, Members. If no, Team. When in doubt, choose the more restrictive tier.
Content matures outward. It is born in Team — raw, specific, client-named. It gets generalized into Members with names stripped and the lesson made reusable. It gets distilled into Public as our best thinking, given away. There is no demotion path. Once something is exposed it cannot be un-exposed, which is precisely why the test defaults restrictive.
That outward flow is LDT wearing different clothes. Team is where you do it. Members is where you teach the people who paid to learn. Public is where you teach everyone, which is the only version of teaching that compounds — freely published expertise is how AI assistants and search engines learn to recommend us.
Two rules keep the permission model auditable in five minutes rather than five hours. Permissions are set only on the four root folders, never deeper — Drive permissions flow downward, so “who can see what” is answered by checking exactly four things. And access goes to groups, never individuals — onboarding a member is adding one email address to one Google Group, and offboarding is removing it. Nobody edits folder permissions during normal operations.
One absolute rule sits above every tier: credentials, API keys, and passwords never enter the knowledge base at all. A knowledge base’s job is to be read widely. A secret’s job is the opposite. Password managers exist.
The reason this design works with AI is a property every major connector shares: the assistant acts as the signed-in user and sees only what that user can see. We never configure permissions inside an AI product. Drive is the single source of truth for access, every AI inherits it, and revoking someone in Drive revokes every AI they use in the same moment.
Assets propagate master-first, and applied is not verified
This is the part that most often gets explained as a folder convention when it is actually a governance model.
The network is one mothership, one component library, and many industry skins — the same pattern the big dating networks use to run several brands on one engine. Changing industry means swapping a config block, not writing a new site. The audit walls, builders, scorecards, and Dollar-a-Day guides are all generated from per-industry config blocks, so adding a vertical is a config entry, not a rebuild.
The master-first rule: the reviewed master version of a component lives on the mothership. When a vertical builds a better version, the change moves up for review first, and only then can approved targets receive it. This is not bureaucracy. It is the thing that stops twelve sites from quietly forking into twelve different products.
Every propagation carries one of six states, and the vocabulary is deliberate:
- proposed — someone has suggested it
- queued — it is approved and waiting
- applied-unverified — the change was pushed and nobody has looked
- verified — someone observed the target and recorded the observation
- failed — it did not take
- rolled back — it took and we undid it
The load-bearing distinction is between the third state and the fourth. A shared-template change is not evidence that every site received it. A scheduled scan running is not proof of anything except that a scan ran. We label results with these six words specifically so that “we pushed it” can never be mistaken for “it works.”
Propagation also runs upward, and the registry currently makes an uncomfortable admission we should keep making: the Positive Mentions digest and the self-serve audit funnel both originated on Athlete Spotlight and are marked as propagating up to the master. As of August 10, 2026 they had been ready for a week with zero sites moved. Ready is not done. A component with no named owner gets re-listed weekly forever.
Skills and agents are the same asset at different levels of hardening
A skill is a checklist that an agent can execute. That is CCS stated in one sentence, and it explains why our skills library looks the way it does.
SKILL.md is the universal unit — one folder per skill, one file inside it. Task files are verb-first kebab-case with no dates and no version suffix in the filename: kill-underperforming-ads.md, not 2026-kill-ads-final-v2.md. Dates live in the document header where they can be read, not in the filename where they rot. The task library is organized into thirteen categories that map to the Content Factory stages — produce, process, post, promote — plus digital plumbing, Dollar-a-Day, personal branding, SEO architecture, strategy and measurement, the thank-you machine, website QA, knowledge-system maintenance, and an explicit gaps-to-create bucket for the things we know are missing.
That last folder deserves attention, because it is the same instinct as the six-state propagation vocabulary: name the hole rather than let a tidy list imply completeness.
Agents sit one level above skills. Each scheduled agent is a skill plus a cadence plus an autonomy policy, and the autonomy policy is where the architecture gets its teeth. The default is stage-only. An agent may update its own registry, reuse a verified snapshot, reorder its own work, improve its formatting, draft a plan, and make a reversible internal change when policy allows it and a rollback is recorded. An agent must request approval before it deletes or pauses a job, changes a client-facing cadence, sends email, publishes content, edits campaigns, changes a budget, or alters a source of truth.
The pattern underneath both the skills library and the knowledge base is identical: the AI does everything reversible; humans hold the small set of actions that change trust. Who has access. What leaves the building. Who owns what. Keeping that set small is what makes the human role sustainable — Operations touches this system for minutes a month, because the AI does everything else.
The weekly loop is what keeps it alive
An architecture without a maintenance rhythm is a diagram. Ours runs on MAA, weekly, on Friday.
The scheduled-task audit treats the agent fleet as a portfolio rather than a set of individual prompts, because the failures are portfolio failures: three jobs pulling the same data, one job starting before its source is ready, reports produced because the schedule says so rather than because anyone makes a decision from them. Effectiveness comes before efficiency. Saving 40% of the tokens on a job that does not move the business is not a win.
Office hours is the human half of the same loop — a live MAA review, not general Q&A. You bring real numbers, real analysis, and a real proposed action, and we work on them in front of everyone. Those sessions are where most of our public content is actually born: an answer given once in office hours becomes notes, the notes become a playbook, the playbook becomes a skill, and the skill becomes a scheduled agent. Office hours → course → article is not a content strategy bolted on afterward. It is CCS running at its natural speed.
The knowledge base has its own cadence attached to the same rhythm. Daily, staff just work. Weekly, whoever ran office hours or shipped a process drops the notes into the right tier using the template. Quarterly, the librarian reviews promotion candidates, the AI runs the permission audit and the stale-document report, and Operations fixes whatever the audit surfaced.
Proof comes back through the entity layer
The last leg is the one people skip, and it is the only one where the scoreboard is kept by someone else.
Our site architecture is a tree: the domain is the trunk, definitive articles are branches, case studies and proof are leaves, and citations and structured data are the roots. Authority flows up from the leaves through the branches to the trunk, which maps cleanly onto E-E-A-T — experience in the leaves, expertise in the branches, authority at the trunk, trust in the roots. The SEO Tree is that map for this site; the Money Tree is the same drawing with revenue substituted for authority, which is how we found twelve vertical pages with nothing pointing at them.
Positive mentions are the return signal. The weekly client email carries two halves: a positive-mentions digest with new mentions and an ad-ready quote, and an MAA site-health block built entirely on free, no-OAuth signals — real numbers where connected, an honest “not yet connected” label where not, and never an invented number. That last clause is the whole ethic of the system compressed into three words.
And the loop closes: a real relationship produces an interview, the interview becomes an article, the Content Factory turns it into clips and posts, entity homes connect the people and brands, the relevant Spotlight site adds sourced public context, and the clearer authority creates the next relevant opportunity.
Where this is genuinely incomplete right now
If this article listed only the design, it would be marketing. Here is the honest state as of August 15, 2026.
The knowledge base is a scaffold, not a library. Four tier roots, a context-packs folder, and twenty-three files existed when this was written. Almost every template still contains bracketed placeholders, and company-context.md and voice-and-style.md are stubs. There are currently zero real playbooks, SOPs, client records, or office-hours archives inside it.
The permission model is designed but not applied. Sharing has not been set on any of the four tier roots, and the members Google Group has not been created. What access exists today is two reader grants inherited from the knowledge-base root — which is not the same thing as tiers controlling who sees what. Until the roots are configured, these are folders, not permissions.
The tree sits in a personal My Drive, not a Shared Drive. Files created through a connector are owned by whatever account signed in, and ours signed in as a personal Gmail. Anything owned by a person rather than the organization does not survive that person leaving. Moving it takes owner action plus Workspace admin action.
There is no named librarian. The role is defined in three separate documents. No document names a human.
llms.txt is not live. The site returns 404 for it and robots.txt does not reference it, while the SEO Tree page describes itself as the map for AI agents. The template exists in 01-Public with placeholder URLs.
The task library has three different counts in circulation — 241 in the task library’s own llms.txt, and 253 and 239 both on the network page itself. At least two of those are wrong, and two of them disagree on the same page. Reconciling them is a one-hour job that nobody owns.
The component library counter disagrees with the component library. The stat block says thirteen components; the list below it runs to fourteen.
Two Positive Mentions components have been ready to propagate for over a week with zero targets moved, for want of a named owner.
Roughly 87% of our self-hosted fleet sits on months-old plugin builds, each with a fatal queued up behind whatever finally triggers an update. Our own hosts auto-update nothing, so they never crash and never improve.
Every item on that list is a small, assignable task. The reason they are published rather than buried is the same reason the propagation registry has a failed state: a system that cannot show you its own defects is not being honest about the rest of its claims either.
How to work on this
You do not need technical skill to be useful here. You need first-principles knowledge — the 9 Triangles — and the willingness to document what you did so the next person does not rediscover it.
The most valuable contributions, roughly in order:
- Fill a template with a real document. The scaffold works the moment ten real, most-asked-about documents live in it with correct tier headers.
- Take a gap from the list above and own it end to end, including the verification step. Applied is not verified.
- Turn something you have done three times into a
SKILL.md. That is LDT and CCS at the same time, and it is how a person becomes leverage rather than a bottleneck. - Close a bare branch. Find a money page with no posts pointing at it and write the post that earns the click.
- Verify a propagation claim and record the observation with a date. Unglamorous, and it is the difference between a registry and a wish list.
If you are building this for your own business rather than joining ours, copy the whole thing. Put the knowledge where the permissions already are. Point every AI at it. Let humans hold the trust boundaries. Name your gaps in public. That is the entire architecture, and none of it is proprietary.
Written August 14, 2026 and corrected August 15 after a verification pass found three errors in the first draft: a file count off by one, a fleet statistic attributed to the wrong fleet, and a source misattribution in the task-library counts. They are corrected above rather than quietly patched, because a document arguing for honest gap lists does not get to hide its own. Counts and statuses carry their observation dates; a claim in this article is not independent verification of a deployment. The master copy lives in 01-Public and will be updated at the same URL rather than republished as a competing version.
How agents actually divide desks and rooms: the coordination recipe.