The Auto Marketing
Engine, operated.

How to use this manual

This is a working manual for a system that is already running, not a brochure for one that might. Everything in it was read from the live engine and its case files; where a number appears, it is a real number with a real source.

Read it three ways, depending on why you are here:

• To understand it — read Parts I and VII. Part I is the plain-English picture of what the engine does; Part VII is the proof it works, with measured before-and-after results.
• To operate it — read Parts III and IV. Part III describes every department in detail — what each one actually reads off your site and what it produces. Part IV is the day-to-day workflow, the four phases from onboarding a business to the quarterly review.
• To administer or upgrade it — read Parts II and VIII. Part II is the architecture: the service, the scoring model, the datastore. Part VIII is the runbook: restarting the service, the daily cron, refreshing the library, and safely adding a department, a niche, or a check.

Part V documents the marketing-skills system the engine is built on, and Part VI covers each special-purpose engine in the WholeReach family. Two conventions recur throughout:

↓ Table of contents

What the Auto Marketing Engine is

The Auto Marketing Engine is a marketing department that runs as software. You give it a web address; it reads the site the way a marketing team would on their first day, scores what it finds, drafts the fixes, and holds every one of them for a human's approval before anything goes live.

It is not a chatbot, and it is not a single tool that does one thing. It is structured like the department a growing business would otherwise have to hire — a set of roles, each with one job, all feeding one approval queue. The difference is that the repetitive work is carried by software running on a schedule, and the judgment stays with a person.

Three commitments define it, and they run through every chapter of this manual:

• It reads the real page. Every finding comes from an actual fetch of your live site. When it cannot reach the page, it says so and produces nothing, rather than inventing a plausible-looking result.
• Nothing ships without a yes. The engine drafts; a human approves, edits, or rejects. There is no auto-publishing, and outbound email is never sent automatically.
• Every change is reversible. When an approved fix goes live, the engine snapshots the file first. One click restores it.

The product lives at automarketingengine.com. It has been running on the operator's own network of live sites before ever being pointed at a client's — which is why this manual can show measured results, not projections.

The loop: audit, draft, approve, ship, measure

Everything the engine does is one loop, run over and over. A good marketing department runs the same loop; the engine's contribution is carrying the repetition while keeping a person in the one seat that matters.

The five stations, shown on the cover and repeated here because they are the spine of the whole system:

1. Audit. You enter a URL. The engine fetches the page and scores it 0–100 across five disciplines — SEO, Content, AI Search, Social, and Technical — plus a sixth, Reach, that is measured from real traffic rather than read off the page (Chapter 6).
2. Draft. Each role produces its work from the same page read: the SEO fixes, the content briefs and calendar, the social drafts, the schema, the conversion and analytics recommendations. All of it is specific to your site's actual signals.
3. Approve. Everything lands in a queue. You approve, edit, or reject. This is the seat you keep, and the reason the engine is safe to point at a real business.
4. Ship. Approved work goes live. On the operator's own test beds this writes directly to the site's files, after taking a snapshot; for a client store it goes through the platform's own API on the same approve-first, reversible terms.
5. Measure. Scores re-run on a schedule. The workspace keeps a history, so a fix that moved a number shows up as a real before-and-after (Part VII).

Where the engine sits in WholeReach

WholeReach is the house for automated marketing — the aggregator the whole engine family lives under. The Auto Marketing Engine is the working product; the other properties are editions, workspace builds, and live case files that all run on the same backend.

The family, and how to read it: one engine, several front doors. Each site stands on its own — its own address, its own sitemap, its own audit — and they share the engine and the skills library, not a login. Part VI gives each its own chapter; in brief:

The full, linked directory of the family lives on the aggregator at wholereach.com/#directory. This manual documents the engine that all of them share.

The backend service

The engine's brain is a single Python service. It is deliberately small and dependency-free — the standard library only — which is why it is easy to run, restart, and reason about.

It listens on the loopback address, so it is never exposed to the internet directly; a reverse proxy sits in front of it. It runs under systemd, so it starts on boot and restarts itself on failure. The facts, read from the source:

The request handler strips a leading /api/ from every path, so each route works both bare and under /api/. Full route tables are in Appendix A; the routes that matter most are POST /analyze (run an audit), POST /ship and POST /rollback (publish and undo), POST /assist (the "ask your marketing team" chat), and GET /report/<domain> (a shareable branded report).

The audit pipeline, end to end

When a URL arrives at POST /analyze, it runs through a fixed pipeline. Understanding these steps is the key to understanding every department, because every department reads from the same single page-fetch.

Step by step, from run_engine(url, intake):

1. Normalize & fetch. The URL is normalized and fetched, with an automatic http → https retry. The result sets reached = bool(page["ok"]) — the single flag that gates the honesty guards in Chapter 10.
2. Parse to signals. analyze_html() turns the raw HTML into a sig dictionary: title and its length, meta description, H1/H2 counts and text, word count, canonical, internal/external link counts, JSON-LD blocks and their schema types, CTA hits and buttons, forms and field counts, trust signals, images and alt-text, socials, and more.
3. Probe machine surfaces. The engine best-effort fetches /sitemap.xml, /robots.txt, /llms.txt, /AGENTS.md, /.well-known/ai-plugin.json, /index.md, an OpenAPI doc and an MCP card — the surfaces AI readers look for — plus real traffic via the site's AWStats.
4. Score. score_site(sig, extra) returns the checks, the per-discipline sub-scores, and the overall (Chapter 6).
5. Detect niche & brand, then build priorities, the 30/60/90 roadmap, the content calendar, the social posts, and the six recommendation channels via seo_aiso(...).
6. Merge & store. Back in analyze_and_store, the result is merged into the site's workspace — checklist, approvals, connections, deliverables, and a rolling 40-entry score history — and written to disk.

The scoring model

The 0–100 score is not a vibe. It is a weighted roll-up of concrete, pass/warn/fail checks read off the live page, with two deliberate rules that keep it honest: a first-audit ceiling, and a reality cap tied to measured traffic.

Scoring lives in score_site(sig, extra). Each check is registered with an area, a human label, a pass/warn/fail state, the reason, the fix, and a weight. The checks roll up per discipline, and the disciplines roll up to the overall.

The six disciplines

Five are read from the page; the sixth, Reach, is measured from real traffic and is never fabricated.

The two rules that keep the number honest

The headroom cap is a design choice, not a bug: a site the engine has just met should never read 100/100, because there is always something to improve and a perfect score on day one would be a lie of exactly the kind the engine exists to avoid. The reality cap ties the headline number to whether anyone actually visits — a technically flawless page that no one reaches cannot post a top overall score.

The niche detector

Before it drafts anything, the engine works out what kind of business it is looking at, because a coffee shop and a magnetics manufacturer need different advice. It does this from the page's own words, not from a guess.

detect_niche(sig, dom) scores each of sixteen niches by counting whole-word keyword matches across the page's title, H1s, H2s and meta description. Highest score wins; ties go to the earlier (higher-priority) niche.

Two refinements matter. First, an own-domain shortcut: the family's own sites (deptmatic.com and its subdomains, automarketingengine.com, and the rest) return automated marketing directly. Second, a fallback: if nothing matches and the page is a genuine 200-class response, the engine names the niche from the first salient noun in the title rather than pretending to certainty.

The workspace datastore

There is no database server. Each site the engine has audited is a single JSON file, which makes the whole datastore inspectable, backup-friendly, and portable.

A workspace at /opt/autoengine/workspaces/<domain>.json holds everything the engine knows about that site: the latest scores, the full checks, the role recommendations, the priorities and roadmap, the content calendar and social drafts, the deliverables with their approval status, the account connections, and a rolling score_history of up to forty entries. That history is what turns a claim into proof — because a fix that shipped shows up as a dated jump in the numbers (Chapter 43).

Each deliverable carries its own lifecycle fields — for a shipped one, a shipped_at timestamp, the ship_target file it wrote, and the ship_backup snapshot it can be restored from. That structure is what makes the next chapter possible.

Ship & rollback

Shipping is the moment an approved draft becomes a live change. The engine treats it as reversible by construction: it never writes to a live file without first taking a snapshot it can put back.

The mechanism is two functions, ship_deliverable() and rollback_deliverable(), exposed at POST /ship and POST /rollback. Ship copies the current live file into a timestamped backup, then writes the approved change. Rollback copies the snapshot back. It is whitelisted to the operator's own test beds; a client store goes through the platform's own API on the same approve-first, reversible terms.

This is not a described capability — it has run. Chapter 43 walks the logged evidence: a real ship followed by a rollback on a live site, two seconds apart.

The honesty guards

The engine's most important feature is the work it refuses to do. Three guards in the code stop it from inventing findings — the failure mode that makes most "AI marketing" untrustworthy.

Guard 1 — no page, no findings

The four page-specific roles (CRO, Analytics, Paid Media, Market Research) only run when the fetch succeeded. When reached is false, each returns the same honest note instead of a fabricated result:

Guard 2 — unmeasured Reach stays unmeasured

If there is no traffic data for a site, Reach is recorded as a "warn" with no score. The engine does not fill the gap with a zero or an average — an unmeasured number is shown as unmeasured.

Guard 3 — no fake social proof

When a site has no social profiles, the Social discipline scores low and stays low. The engine will not inject a fabricated sameAs to inflate the number. Every case-study site in Part VII carries a real, low Social score for exactly this reason — and the case files say so out loud.

The department model — three honest layers

People ask "how many roles does the engine have?" The honest answer is that "the department" exists at three layers, and they don't all carry the same number. Confusing them is the single most common way to overstate what the engine does, so this manual keeps them separate.

The color-coding in the app makes the layers visible: blue role cards are live today, red are the critical roles coming online, black are future. In the current data the four roles Tim's deck flagged as critical — CRO, Analytics, Paid Media, Market Research — have all been promoted from red to live, and their pages carry the line "one of the critical roles from Tim's deck — now live."

The Auditor

The Auditor runs first and re-runs on a schedule. It is the role that reads your site like an AI reader would and turns it into the 0–100 scorecard everything else works from.

Reads: the full page-fetch and machine-surface probe from Chapter 5 — title, meta, headings, links, schema, CTAs, forms, trust signals, and the AI-reader surfaces (llms.txt, AGENTS.md, sitemap, robots).

Produces: the five discipline sub-scores plus measured Reach, the overall, and a ranked list of the highest-impact fixes with the concrete change for each. In the app this is the Audit & Report view — every real signal in a sortable table — and the shareable branded report at /report/<domain>.

Discipline: the Auditor is where the honesty guards bite first. If it could not read the page, it says so and the downstream roles produce nothing. Its report carries the line, verbatim: "Every number on this page comes from a real fetch — nothing is invented."

The SEO Manager

The unglamorous work that decides whether you are found: structure, schema, internal links, sitemaps. The SEO Manager is a real backend channel, built inside seo_aiso().

Reads: the SEO signals from sig and the SEO sub-score.

Produces: four to five ranked SEO recommendations — the first gated on the SEO sub-score being under 80, so a site already strong on SEO isn't handed busywork. Typical items: title and meta rewrites to the right lengths, a single clean H1 with matching keywords, sitemap depth and Search-Console verification, breadcrumb schema, and internal-link structure.

In the app: the SEO & AI Search view. Because SEO and answer-engine optimization share a page-read, they are drafted together and presented side by side.

The Answer-Engine Analyst (AEO)

The role that decides whether ChatGPT, Claude and the other AI readers can find, quote and cite you. This is the engine's sharpest edge — the "Agents First" discipline that most marketing tools don't pair with a full department.

Reads: the machine-surface probe results — whether /llms.txt and /AGENTS.md exist, the JSON-LD blocks and their schema types, FAQ markup, and whether the page opens with a crisp lead answer.

Produces: four recommendations — publish /llms.txt and /AGENTS.md, add JSON-LD (Organization, FAQPage, and the types that fit the niche), add FAQ markup, and write a 40–60 word lead answer an AI reader can lift verbatim. This is precisely the fix shipped across the homebuilding case study in Chapter 41.

The Content Desk

Drafts the pages and posts your customers actually search for — from your real facts, never invented ones. The Content Desk is where niche detection pays off, because the calendar it builds is tuned to what your kind of business should publish.

Reads: the detected niche, the page's word count and heading structure, and the positioning themes in the H2s.

Produces: a publishing calendar tuned to the niche, content briefs for the pages worth writing, and the raw drafts. In the app this is the Content view: calendar plus briefs plus social drafts in one place.

Discipline: the Content Desk drafts from your real facts. It will flag a thin page (under 800 words on the homepage) as a Content weakness rather than paper over it, and it never fabricates claims about your business — the "correct the brief" step lets you point it right in one line and have it redo the work.

The Social Scheduler

Turns what you publish into a steady, honest presence — drafted ahead, approved by you. The Social Scheduler is also where the third honesty guard lives.

Reads: the page's linked social profiles and the content the Content Desk produced.

Produces: social drafts derived from your real content, scheduled ahead for approval. Nothing posts without a yes.

The Email Writer

Builds the list and drafts the sends. Every email is drafted for approval — and, uniquely, outbound email is the one thing the engine will never send on its own, even after approval settings are configured elsewhere.

Produces: list-building recommendations and drafted sends, all held in the approval queue.

Conversion Rate Optimization

The role that reads your live page for the things that turn a visitor into a customer — or fail to. cro_recos(d, niche) is a real analyzer, up to eight recommendations, all computed from the page.

Reads: CTA hits and buttons, forms and their field counts, trust signals, the H1 and headline, whether a phone number or mailto is present, and the viewport.

Produces: up to eight conversion recommendations — diagnostics on how many CTAs exist and whether they're clear, whether forms are too long, whether trust signals are present, and whether the headline states the value in the first five seconds.

In the app: the Conversion view, which runs realRole against the fetched page and falls back to a generic playbook only when there's no workspace loaded.

Paid Media

The role that drafts what you'd run and gates whether you should. paid_recos(d, niche) builds keyword themes and a real ad draft from your own page — but won't tell you to spend until you can measure it.

Reads: the H1s and title (for keyword themes and ad copy), the niche, the CTA presence, forms, and whether analytics is installed.

Produces: up to seven items — keyword themes and a responsive-search-ad draft written from the page's own H1 and title, plus a gate: paid spend is only recommended once there's a clear CTA and tracking in place. The engine will not send you into an ad auction blind.

Data & Analytics

The role that checks whether you can even see what's working. analytics_recos(d, niche) produces up to eight measurement recommendations from what the page reveals about its own tracking.

Reads: whether analytics is installed, Search-Console verification, the forms and CTAs (to know what a conversion even is), and the word count.

Produces: install GA4, verify Search Console, define conversion events for the real actions on the page, add UTM discipline, and stand up a dashboard. This is the role the Manager Agent reads at each interval to know whether the other roles' work is landing.

Market Research

The positioning read: who you're up against and who you're for. research_recos(d, niche) produces up to six recommendations from your page's own positioning language.

Reads: the H2s (as positioning themes) and the linked socials.

Produces: a competitor map, an audience definition, and a customer-interview plan — the homework a marketing department does before it spends a dollar. Anything material feeds the Board's quarterly review (Chapter 24).

Outbound / Demand Gen

The pipeline half of the department — the outbound motion that complements the inbound work of SEO, content and AEO. It appears in the app as the Outbound view.

Produces: the demand-generation pipeline — prospecting lists, cold-email sequences (drafted, never auto-sent, per Chapter 17), and the outbound cadence. It draws on the skills library's prospecting and cold-email playbooks (Part V).

The Manager Agent

The CMO seat — the executive overview that reads across every role and tells you what got done, what's waiting, and what to do next. Its real mechanic is the daily run.

What it shows (the Manager view, Phase 3 · Operations): four stat cards — active roles, deliverables shipped, items awaiting approval, and critical roles coming online — a Daily → Weekly → Monthly → Quarterly → YOY interval strip, a "what got done" list, and "recommendations for your approval" that are analysis-driven when a workspace is loaded.

Its real mechanic: there is no single manager() function; the Manager's engine-side action is the /run-daily endpoint, which runs the department's daily production for one site or the whole network. The Manager view is the human-readable face of that run.

The Board of Advisors

The quarterly review, run by software. The Board reads the scorecard, names your weakest discipline, and points the next quarter's goals at closing that gap.

How it works (the Board view, Phase 4 · Review): it reads analysis.scores, finds the strongest and weakest of the five disciplines, and prints, for example: "Overall readiness N/100. Strongest: X (n). Weakest: Y (n) — the board points this quarter at closing that gap." The weakest discipline maps to a strategy — SEO/AI-Search/Content point to "own your search," Social to "drive demand," Technical to "fix conversion" — and that option is flagged ★ Board's pick. Adopting it sets your next-period goals.

Four standing advisor voices frame the review: a Growth Strategist, Brand & Content, an Answer-Engine (AEO) advisor, and Performance & Finance.

The Approval Queue

The most important role has no AI in it at all. The Approval Queue is the human gate — approve, edit, reject — and it is the reason every other chapter is safe.

What it is: every deliverable the department drafts lands here with a status. You approve it, edit it, or reject it. Approved work becomes eligible to ship (Chapter 9); nothing moves without your action. In the app it is the Approvals & Setup view, which also holds the account connections and the managed-engagement terms.

Why it's a role, not a step: the whole product thesis is that software should carry the repetition and a person should keep the judgment. The Approval Queue is that principle made concrete — the one seat that is deliberately never automated.

Tim's four phases: onboard, set up, operate, review

The engine's operating rhythm is a four-phase lifecycle, built into the app as a clickable strip that runs across the top of every phase view. It came from a client's own marketing-system deck and was implemented verbatim.

Phase 1 — Onboarding

You tell the engine who you are. The onboarding form collects goals and channels (as chip toggles), your audience, and budget, and takes a URL. This is wired to the real backend: submitting posts { url, intake:{ goals, channels, audience, budget } } to /analyze, runs a live audit, and lands you on an accurate report with real deliverables already generated. The intake is remembered and carried forward on re-audit, so the 30/60/90 roadmap is personalized to what you said you wanted.

Phase 2 — Set Up

You pick the department. The roster is presented with each role's auto-versus-supervised setting and report frequency; you choose which roles run and how much rope each gets — remembering that outbound email can never be set to fully automatic.

Phase 3 — Operations

The department runs. The Manager Agent (Chapter 23) gives the executive overview, deliverables flow into the approval queue, and the /run-daily mechanic produces fresh work on the interval you set.

Phase 4 — Review

The Board (Chapter 24) reads the quarter's scores, names the weakest discipline, and sets the next period's goals — which flow back into Phase 2. The loop closes.

What Agent Skills are

"Skills are markdown files that give AI agents specialized knowledge and workflows for specific tasks. When you add these to your project, your agent can recognize when you're working on a marketing task and apply the right frameworks and best practices." That is the definition from the source repository, and it is exactly how the engine uses them.

The library is coreyhaines31/marketingskills — "a collection of AI agent skills focused on marketing tasks, built for technical marketers and founders who want AI coding agents to help with conversion optimization, copywriting, SEO, analytics, and growth engineering." It follows the open Agent Skills specification, so the same skills work across Claude Code, OpenAI Codex, Cursor, Windsurf, and any conforming agent.

Each skill is a single SKILL.md file with YAML frontmatter — a name (lowercase, hyphenated, matching its folder), a description of when to use it, and a version — followed by a markdown body of frameworks and best practices. A skill is invoked in three ways:

• Natural language: "Help me optimize this landing page for conversions" → the agent recognizes the task and applies the cro skill.
• Direct invocation: /cro, /emails, /seo-audit.
• Installed: npx skills add coreyhaines31/marketingskills, or the Claude Code plugin /plugin install marketing-skills.

The dependency architecture

The skills are not a flat list — they form an interconnected system. One skill sits at the root, and every other reads it first. This is the single most important structural fact about the library, and the engine honors it.

In the repository's own words: "Skills reference each other and build on shared context. The product-marketing skill is the foundation — every other skill checks it first to understand your product, audience, and positioning before doing anything." That is exactly what the engine's niche detection and intake do before any department drafts a word — establish who the business is, so the rest is grounded.

The seven categories and 47 skills

The library ships 47 skills. The engine groups them into seven categories in its own generator, matching the repository's structure. Here is the full set — the complete list appears again, alphabetized with descriptions, in Appendix B.

In the product, this is the Marketing Skills tab (view #17): the seven groups, each skill a card that opens to its full playbook and reference docs, folded directly into the engine so the department can reach the right framework for any task.

The prompt library

On top of the 47 skills, the engine ships a library of ready-to-paste prompts — the operational layer that turns a skill's framework into a task you can run today. The count is exact and verified from the source files.

The 24 industry packs are what make the library concrete for a real business rather than generic: travel, cruise ships, villas, non-MLS real estate, robotics, radio, TV and streaming, coworking, coffee shops, car dealers (new and used), and more. Each pack is a set of prompts written for that vertical's actual customers and searches — the "real, genuine verticals to test on" that keep the engine honest, because a prompt that works on a live coffee shop or a live magnetics guide is provably useful in a way a generic one is not.

Full skills coverage: the engine enabled in all 47

This is the chapter that answers the operator's real question — is the engine actually enabled in every one of the 47 skills? Yes. Each skill is covered in one of three modes, and this matrix names the mode and the department for all 47, with nothing left out.

The three enablement modes:

• Live analyzer — the engine computes page-specific findings for this skill from your real site, through one of the six backend channels.
• Playbook + prompts — the engine delivers this skill through its full SKILL.md playbook plus ready-to-paste prompts, driven by the responsible department.
• Generator — the engine produces this directly (the content calendar, social drafts, the 30/60/90 roadmap).

License and attribution

The skills library is open-source, and the engine uses it on those terms — openly, with attribution, as the library's author intends.

The Marketing Skills library is MIT licensed — "Copyright (c) 2025 Corey Haines" — which the repository summarizes as "use these however you want." The engine adapts the skills into its own generator (gen-ame-skills.py → the in-app library) and carries the attribution verbatim on the Skills and Prompts pages: "Skills adapted from coreyhaines31/marketingskills (MIT)."

The repository also names its wider world — Conversion Factory (Corey's agency), Swipe Files (his newsletter), and Magister (an autonomous AI CMO built on these skills). The engine is a distinct, independently built system that stands on the same open foundation.

Auto Marketing Engine — the flagship

automarketingengine.com is the only property with the full working app: the ignition form, the live audit, the department roster, the approval queue, and the Skills and Prompts libraries. Everything else in this part is a variation on it.

It is the site that runs the real backend described in Part II, presents the department of Part III, and follows the lifecycle of Part IV. When this manual says "the engine," it means the machine that lives here. Its front door offers a free audit — one URL, no signup, nothing asked in return — which is the honest top of the funnel: a real result, given away, that proves the machine before any conversation about price.

The three editions

Deptmatic, Deptless, and Auto Marketing Dept are the same engine told three ways. Under the hood they share the backend; on the surface each tells the story to a different audience.

• deptmatic.com — the department edition, the product line. "An AI marketing team that audits your website, drafts the SEO, content and social fixes, and ships them — you just approve."
• deptless.com — "run marketing without the department," paired with the honest feature chart that compares every edition, gaps included. This is where a skeptic goes to check the claims.
• automarketingdept.com — the marketing-department-as-a-service framing: every role a filled position, the payroll you never run.

The editions are kept at parity so any could stand in for the flagship — a deliberate resilience choice. Each is self-canonical and independently indexed.

The dashboard build — a.deptmatic.com

The four-step setup workspace. a.deptmatic is the build that answers "what does onboarding feel like?" — set it up in four steps, then watch it read your site, produce real work, and hold every deliverable for approval.

It is the clearest expression of Phase 1 → Phase 3 of the lifecycle: a guided path from a cold URL to a working department with deliverables waiting in the queue.

The command edition — b.deptmatic.com

The department at scale. b.deptmatic is the build for running many businesses on one engine: a network-wide leaderboard across every site, a command palette, bulk approvals, and a planning simulator.

Where the flagship manages one business well, the command edition manages a portfolio — the same approval discipline, but with the tools to triage and act across dozens of sites at once. It is the operator's cockpit.

The magnetics case engine — c.deptmatic.com

The engine pointed at a real, hard, technical niche: programmable magnets. c.deptmatic runs the engine end to end on two live magnetics guides and builds three department concepts for the company behind the technology, Polymagnet.

Its own headline stat strip, verbatim: "2 live guides audited & run on the engine · 3 department concepts, all built for Polymagnet · engine avg 63/100." The full numbers are the subject of the case study in Chapter 42. What makes it a proof rather than a demo is its own disclaimer: "Nothing below is a mockup. Every number and every link is live."

Those are the live scores as read from the case file on 2026-07-16 — and each card publishes its real punch list. Queued next for the review: Search Console verification, H1/title keyword alignment, and a complete share-image stack. Queued for the guide: Search Console verification, breadcrumb schema, linked social profiles, and outbound authority citations. The case file calls these "the engine's real, current punch list" — the same queue an operator sees.

The homebuilding case engine — d.deptmatic.com

The most complete proof the engine has: one engine run end to end on six real homebuilding sites, each with a shipped, re-audit-verified fix. This is the case file for Tim and Melissa's own industry.

Its stat strip, verbatim: "6 live sites audited & run on the engine · 3 service lines mapped for homebuilding media · engine avg 64/100 after the shipped fixes." What shipped to each site was FAQ-schema (FAQPage JSON-LD) markup — "verified by re-audit, live on the site now, and one-click reversible." The per-site before-and-after is the centerpiece of Chapter 41.

Scores as read live on 2026-07-16. The shipped fix on every site was the same: FAQPage JSON-LD markup, drafted by the engine, approved by a human, verified by re-audit, and one-click reversible. The AI Search column moves the most because that is exactly what FAQ schema feeds.

The Polymagnet rebuild — 1.deptmatic.com

Not a case file about the engine — a finished thing the engine's thinking produced. 1.deptmatic is a full marketing rebuild for the programmable-magnets maker, live and readable as the output end of the pipeline.

Where c.deptmatic shows the audit and the concepts, 1.deptmatic shows what "shipped" looks like when the department's work is carried all the way through — the before-and-after made whole.

What "carried all the way through" means, as published on the live rebuild: a full product story for the programmable magnet — the five programmed behaviors (Attach, Align, Latch, Spring, Torque), each explained as engineering rather than magic; an applications library spanning consumer electronics, positioning devices, and industrial design; and the company's own proof points restated cleanly — 100+ issued U.S. patents, energy focused up to 5x stronger than a conventional magnet of the same size, days from prototype to hand.

The site is a complete department-grade build: Applications, Catalog, Design Software, Magnetizers, Custom Solutions, FAQ, Resources, About, and Contact — with "Request a sample" as the conversion spine. Set it next to the audit cards in Chapter 37 and you are looking at both ends of the pipeline at once: the punch list, and the finished thing.

Day in the Life — automarketing.wholetech.com

The department as a live 24-hour timeline. This build answers "what does the department actually do all day?" with a running clock and a "now" line showing what each role is doing this minute.

Technically it is a data-driven dashboard — it reads a per-site data file of role activity rather than the live /analyze output — so it is the family's showpiece for the rhythm of the department: seven desks (content, SEO, social, email, revenue, analytics, creative) plus an Ops desk, each ticking through its day. It is the long-form feature: "the department that runs on a schedule, not a payroll."

Six homebuilding sites, before and after

The clearest evidence the loop closes. The engine audited six real homebuilding sites, drafted the same fix for each — FAQ-schema markup, the Answer-Engine role's signature move — shipped it after approval, and re-audited to confirm the lift. Every number below is from the live case file at d.deptmatic.com.

Read the pattern, not just the numbers: the same fix, applied by the same role, moved the AI-Search score on every site — because FAQ-schema is exactly what an answer engine needs to quote a page. Content rose where the FAQ added substance (Green Home Video 70→80, Earthscrapers 70→80). Overall climbed everywhere. And it was verified by re-audit — the engine re-scored after shipping, so this is measured lift, not a projection.

Two magnetics guides, audited live

The engine run on a genuinely hard technical niche, to show the audit holds up outside easy verticals. Both scores are current, audited values from c.deptmatic.com.

The report for multipolemag.com cites the exact page facts it read: "Title length 79 chars, homepage words 1023, H1/H2 1/4, sitemap URLs 35, JSON-LD blocks 2, internal links 38, social profiles none." The score history in the workspace shows this site's audited overall climb — 54 → 55 → 60 — as fixes shipped over two days. The report's disclaimer, verbatim: "Every number on this page comes from a real fetch of multipolemag.com — nothing is invented."

Ship-and-rollback, proven end to end

The single most important proof in this manual: the engine has demonstrably shipped a real change to a live site and rolled it back — logged, timestamped, with the snapshot files still on disk. This is what makes "reversible by construction" a fact, not a promise.

A ship and its rollback, two seconds apart, on a live site — that pair is the whole safety model working under real conditions.

The number moving, with timestamps

The strongest proof isn't a claim of improvement — it's the improvement happening in the log. The multipolemag.com workspace keeps a score_history, and it records the overall score climbing as fixes shipped over three days. This is not a projection or a mock-up; it is the datastore's own timestamped record.

At scale — this is not a demo

The evidence is not one lucky site. The engine's own datastore shows the breadth of real work:

Two hundred seventy-three sites audited, twenty-four fixes shipped to live production, every one of them reversible — with the snapshots to prove it. That is the difference between a working system and a slide deck.

Network readiness at scale

Beyond individual case studies, the engine's discipline shows up across the whole network it runs on. The Agents-First readiness audit — the same AI-reader criteria the engine scores — puts nearly every network site at the top of the scale.

The /api/analyze endpoint is the same one the onboarding form calls — so the audit a prospect runs on their own site is the identical machinery that scores the network. When it read wholetech.com it returned real signals: 3,969 words, three JSON-LD blocks, schema types including FAQPage and Organization, 396 sitemap pages, an llms.txt and an AGENTS.md both present. Nothing simulated.

Test it yourself: a protocol for humans and agents

Proof you can reproduce beats proof you have to believe. This chapter gives two runnable test tracks against the live system — one for a person, one for an agent — plus the pass criteria that together demonstrate the engine reads real pages, refuses to invent, gates on approval, and reverses cleanly.

Run either track, or both. Nothing here mutates a site you don't own: the audit is read-only, and the only write path (ship) is whitelisted to the operator's own test beds. Everything below hits public endpoints.

Track A — the human test (browser, ~10 minutes)

No tools beyond a web browser. Each step states what to do and what a pass looks like.

Pass all seven and you have confirmed, by hand, the four core claims: it reads the real page (A2), it's deterministic (A3), it refuses to fabricate (A4, A5), and it keeps a human in control (A7).

Track B — the agent test (shell, scriptable)

For an AI agent or an engineer with curl and jq. These are assertions, each with an expected result. An agent can run them in sequence and report pass/fail.

Track C — measuring success over time (AWStats)

Tracks A and B prove the engine works. Track C proves it helps — the outcome that actually matters. The engine's sixth discipline, Reach, is measured from real AWStats traffic (Chapter 6), so the honest success metric is simple: after the engine ships fixes, do the numbers move in the weeks that follow?

The method is a clean before-and-after: record the baseline (audit scores + the last full AWStats month) before any fix ships; ship the approved fixes; then compare the next full month. The lift is real because Reach is measured, and the engine refuses to fabricate it (Chapter 10) — an unmeasured month reads as unmeasured, never as a flattering guess.

The scorecard

Together, the three tracks test every load-bearing claim in this manual — that it works (A, B) and that it helps (C). Map them to what they prove:

Running and restarting the service

The engine is a systemd service. Administering it is ordinary systemd — start, stop, restart, check status, read logs.

Because it binds loopback only, you test it locally on the host and let the reverse proxy serve it publicly. It restarts on failure automatically (Restart=on-failure), so a crash self-heals; a code change needs a manual restart to take effect. The sibling autom-api.service handles the launch/intake and domain-check API and is controlled the same way.

The daily cron

The department produces fresh work every day without anyone pressing a button. That is daily-run.sh, on a midnight cron.

The job at /opt/autoengine/daily-run.sh runs at 00:00 CT and drives the engine's daily production — the mechanic behind the Manager Agent's "what got done" list. It is the automated half of the loop; the approval gate is still the human half, so "produced" is not "published."

Refreshing the skills library

The 47 skills and 427 prompts are regenerated on a weekly cron and synced to every property in the family. The one thing to know as an administrator: the order is not arbitrary.

The refresh is /root/ame-refresh.sh, run Monday mornings. It regenerates the prompts, then the skills, then copies the built /prompts/ and /skills-preview/ directories out to every mirror.

Upgrading the engine safely

The engine is meant to grow — more live analyzers, more niches, more checks. Here is how to add each without breaking what runs, following the patterns already in the source.

To promote a skill to a live analyzer

The path CRO, Analytics, Paid Media and Market Research already walked: write a <role>_recos(d, niche) builder that reads real fields from sig, wire it into seo_aiso()'s return behind the reached guard (so it honors the fabrication rule), and add its view to the app. Never let it produce output when the page wasn't reached — inherit the honest note.

To add a niche

Add a (label, keywords) tuple to the NICHES list in priority order. Position matters: earlier niches win ties, so place a specific niche (like magnetics) ahead of a general one (like marketing). Give it enough distinctive keywords to score reliably.

To add a check

Inside score_site(), register it with add(area, label, ok, why, fix, weight). It automatically joins its discipline's roll-up. Respect the headroom cap — a new check should never let a first audit reach 100.

The deployment discipline

Edit the generator, not the output. The reliable pattern across the whole network is: write the change as a script, copy it to the host, run it, and verify live — never hand-edit a generated file that a cron will overwrite. Restart autoengine after any server.py change. And for the family sites, keep the editions at parity: an essential, safe upgrade to the flagship propagates to the mirrors.

GET

POST

Descriptions summarized from each skill's purpose; the authoritative SKILL.md for each lives at github.com/coreyhaines31/marketingskills/tree/main/skills.

↑ Back to top