Auto Marketing Engine

1 Executive summary

The Auto Marketing Engine is a multi-tenant web application that performs the work of a small marketing department. A user enters a web address; the engine fetches the live page, extracts 26 structural signals, scores the site against 51 discrete checks across five weighted disciplines, reads the site's real interior pages, matches the site to a curated industry knowledge base, and generates a slate of concrete deliverables — content briefs, on-page fixes, social drafts and growth assets. Approved on-page fixes are written directly to the live site with a snapshot backup and one-click rollback.

This document specifies the system as built. Parts A–D describe the Available now production release in operational detail, including a step-by-step walkthrough of setting up a real site with real output. Part E specifies Roadmap proposed development, including deeper competitor analysis and an expanded video library.

2 System architecture

The platform is four cooperating services behind a single authenticating reverse proxy. Requests carry the signed-in user's identity from the edge inward, which is how per-account isolation and plan limits are enforced consistently.

                    ┌────────────────────────────────────────┐
      browser ──────►  Reverse proxy (TLS, auth_request)     │
                    └──────┬───────────────┬─────────────┬───┘
        auth check ────────┘               │             │
   ┌───────────────────┐   identity hdrs   │             │
   │ Account service   │──────────────────►│             │
   │ · signup / login  │  X-AME-User       │             │
   │ · plans / billing │  X-AME-Admin      │             │
   │ · admin console   │  X-AME-Site-Limit │             │
   └─────────┬─────────┘                   │             │
             │ SQLite users.db             ▼             ▼
             │                    ┌─────────────────┐  ┌──────────────┐
             │                    │ Engine          │  │ Commerce     │
             │                    │ · fetch + score │  │ · live       │
             │                    │ · generate      │  │   checkout   │
             │                    │ · ship/rollback │  │ · host-aware │
             │                    └────┬───────┬────┘  └──────────────┘
             │                         │       │
             │            workspace JSON│       │ knowledge bases
             │              (per site)  ▼       ▼   (per industry)
             └──────────────────►  /workspaces   /kb/*.json ◄── weekly gatherer

Component responsibilities

Storage model

The engine deliberately uses a file-per-site JSON workspace rather than a relational database. Each site's entire state — analysis, scores, checks, research, deliverables, approvals, activity log and score history — is a single self-describing document. This makes every site independently portable, inspectable and restorable, and makes a corrupted or experimental site a one-file problem rather than a schema migration. Writes are atomic (temp file + fsync + rename) under a process lock.

3 Processes & scheduled jobs

Available now

A1 Step 1 — Account, access and plan resolution

A visitor to the application without a session receives the public marketing page; the application itself is never exposed unauthenticated. Signup offers two paths:

• Subscribe — live checkout; on payment confirmation the account becomes active.
• Request a free account — the account enters trial_pending and an administrator is notified for approval; on approval it becomes trial.

Account states are pending → trial_pending → trial / active, with rejected for revoked access. Only trial, active and administrators pass the gate.

Identity and limits propagate inward

On every request the edge calls the account service, which returns three headers that travel with the request to the engine:

A non-administrator sees only workspaces they own. Adding a new site is refused once the account is at its plan limit — re-analyzing a site already owned is always permitted, so a limit never blocks maintenance of existing work.

Available now

A2 Step 2 — The analysis fetch

The user enters a domain (e.g. ferrospring.com). The engine normalizes it to a URL and performs a live fetch presenting a standard desktop browser profile, because many CDNs and WAFs serve different markup to obvious automated clients. Behavior:

• Protocol fallback — if HTTPS fails to connect at all, HTTP is attempted.
• Rate-limit awareness — a host that throttles is marked and subsequent requests to it are paced; transient 429/503 responses are retried with backoff.
• Scoreability gate — if no markup is captured, the run fails loudly rather than scoring an empty page. The previous analysis is preserved untouched.
• Readability gate — pages that return markup but are not a readable site (authorization walls, bot challenges, parked or "domain for sale" placeholders, error pages, login walls, or fewer than 20 words) are rejected and never become a managed site.

Supplementary probes

After the homepage, the engine probes, best-effort: /sitemap.xml (including nested sitemap indexes, recursed and summed), /robots.txt, /llms.txt, /AGENTS.md, /openapi.json, an MCP card, an ai-plugin manifest, Markdown content negotiation, and any available traffic measurement for the domain.

Available now

A3 Step 3 — Signal extraction

The captured markup is parsed into a structured signal set — the evidence every later score, finding and deliverable refers back to. The engine extracts 26 fields:

Alongside these, an extra record holds the probe results: sitemap_pages, robots, llms, agents_md, openapi, mcp_card, ai_plugin, index_md, traffic and reach.

Available now

A4 Step 4 — Scoring: 51 checks, five disciplines, one weighted score

Each check is evaluated to pass, warn or fail and carries a weight, a plain-language why (the observed evidence) and a fix (the corrective action). The complete check set:

SEO — 9 checks  (discipline weight 1.15)

Title tag (40–60 chars) · Meta description (130–160 chars) · Heading hierarchy (one H1, ≥3 H2, no skipped levels) · Canonical tag · XML sitemap depth · robots.txt · Search Console verified · Title/H1 keyword alignment · Breadcrumb schema

Content — 8 checks  (weight 1.00)

Homepage depth · Section headings · Image alt text · Internal linking · Outbound authority links · Content freshness · Media richness · Answer-style content

AI Search / AEO — 17 checks  (weight 1.15)

llms.txt · AGENTS.md · Structured data (JSON-LD) · Rich answer schema · Agent read API · ai-plugin manifest · Markdown negotiation · Agents allowed in robots · Open Graph complete · AI answer identity (sameAs) · Answerable Q&A (FAQ schema) · Question-based headings · Citable answer passages · Freshness signal · Bylined authorship (E-E-A-T) · Cites sources (trustworthiness) · Identity & authority in schema

The rich-answer test distinguishes rich schema types that assistants can quote (FAQPage, HowTo, Article, Product, Event, LocalBusiness, Service, Recipe, Review, VideoObject, Course, QAPage and others) from generic boilerplate types (WebSite, Organization, WebPage, BreadcrumbList) that carry no answerable content.

Technical — 12 checks  (weight 1.10)

HTTPS · Mobile viewport · Language declared · Healthy response · Favicon · Charset declared · Security headers · No mixed content · Compression · HTTP caching · Crawlable HTML size (<2 MB) · Response integrity

Social — 5 checks  (weight 0.80)

Social profiles linked · Share image · Twitter/X card · Share preview complete · Social identity in schema

Reach — measured, not assumed

Where real traffic data exists for the domain it is mapped to a 0–100 reach score on a logarithmic scale. Reach then acts as a reality cap: a measured site's overall score cannot exceed 50 + reach/2. A technically flawless page nobody visits cannot present as excellent. Where no traffic data exists, reach is reported as unmeasured and never penalizes the score — instead a check advises connecting analytics.

Aggregation

Discipline scores are the weighted share of checks passed, each capped at 90 — deliberate headroom, because acing every check in a discipline is rare and a perfect score invites complacency. The overall score is the weighted mean across disciplines, then the reach cap is applied.

Worked example — ferrospring.com

// live workspace output
overall  57
  SEO        68      Content   35      AI Search 33
  Technical  90      Social    58
checks: 51 evaluated, 26 passed

// top priorities, ranked by severity × weight
fail  AI Search  Rich answer schema
fail  SEO        Breadcrumb schema
fail  Content    Homepage depth

Every finding carries its evidence and remedy. The "Rich answer schema" failure, for instance, reports the schema types actually found and prescribes marking up real content with two or more rich types so assistants can quote the page directly.

Available now

A5 Step 5 — Deep research (reading the real site)

Scoring judges the homepage; deep research is what makes the generated content specific to the business. The engine harvests same-domain links from the homepage, filters out non-content destinations (cart, checkout, account, login, policy and asset URLs), ranks the remainder by content value — product, service, solution, about, blog, guide, FAQ, use-case, industry, feature, how, case — and fetches up to five real interior pages, plus up to two named competitor homepages from the intake.

From each page it extracts the title, the H1/H2 section names (filtered of navigational noise) and any question-form headings. The result is stored on the analysis as:

research: {
  pages:       [ { url, title, headings[] } ]   // up to 5 real interior pages
  real_topics: [ … ]                            // the site's actual section names
  faqs:        [ … ]                            // the site's actual questions
  competitors: [ { name, title, angles[] } ]    // live competitor positioning
}

Example — ferrospring.com returned four interior pages (Product line, FAQ, Shipping, Contact), real topics including Demos & Kits, Tools & Accessories, Device Mounts, Alignment, Rotational & Detent, Latch, and real FAQ questions including "What is a coded (programmable) magnet?".

Available now

A6 Step 6 — Industry cluster match

The engine derives a niche from the site's own language and matches it against the keyword map of every installed industry knowledge base, longest keyword first. The matched cluster is recorded on the analysis and governs the intelligence used in generation.

A site that matches no cluster is fully supported — it simply generates from its own research without industry grounding. New clusters are added by configuration alone, with no engine change.

Available now

A7 Step 7 — Onboarding intake

The audit cannot infer commercial intent, so a structured intake captures it. Every field is consumed downstream — this is not a form for its own sake.

Intake can be revised at any time and is carried forward automatically on every re-analysis.

Available now

A8 Step 8 — Activation: the opening slate

Activation is the single, explicit act that starts the department. On first activation the engine produces:

A real activation of ferrospring.com produced 28 deliverables: 6 content briefs, 6 social drafts, 5 SEO fixes and 15 growth assets — all pending, none published.

Available now

A9 Step 9 — Review, edit and approve

Every deliverable is a structured record the user can read, edit and decide on. A content brief carries a headline, primary keyword, outline, direction points, CTA, channel, publication date and a provenance label stating where the topic came from.

Verbatim brief — ferrospring.com

title    Every FerroSpring coded magnet, by category
keyword  every ferrospring coded magnet by category
source   From a real page on your site
publish  2026-08-04      channel Blog

outline
 · Direct answer (40–60 words) — open with the one-sentence answer so
   AI answer engines can quote it verbatim
 · Why this matters for magnetics readers
 · The specifics — 3–5 scannable H2 subsections
 · A plain-English FAQ answering real questions from the site:
   "What is a coded (programmable) magnet?" …
 · Call to action + built-in lead capture

direction points
 · Cornerstone topic for the "magnetics / magnets" niche — link it into
   the homepage's 11 existing internal links.
 · Primary keyword goes in the H1, the URL slug and the first sentence.
 · Close a real gap while you publish — Meta description: add a 130–160
   char description that earns the click.
 · Draw the contrast with K&J Magnetics — make plain what you do differently.
 · Cross-link to your real pages: Product line, FAQ, Shipping.
 · Turn these real sections into H2s: Demos & Kits, Tools & Accessories …
 · Position against the field — K&J, Eclipse, Bunting, Master Magnetics.
 · Cite authoritative sources — Correlated Magnetics Research.
 · Cover the pillars readers come for: Align, Latch, Spring, Hold, Detent.
 · Industry angle: coded magnets deliver behaviors ordinary magnets can't …

Note the composition: points 1–3 come from the audit, points 4–6 from deep research on the site itself, and points 7–10 from the industry knowledge base. That layering is what separates this output from generic content generation.

Editing and the approval state machine

Any field can be edited in place; edited items are flagged, and editing an SEO fix's recommended text regenerates its copy-paste code so the two can never drift. States:

pending ──approve──► scheduled / done ──(hosted site)──► shipped ──rollback──► scheduled
   ▲
   └──────────────── reset ◄── rejected ◄──reject──┘

Pending, approved-in-process and rejected items are displayed as separate persistent groups, so approving an item never makes it disappear from view.

Available now

A10 Step 10 — Ship to live, and roll back

For sites the platform hosts, approving an on-page fix is publishing it. The publish path is deliberately narrow and fully reversible:

Before any write the engine snapshots the target file. If the edit would change nothing, it reports that rather than writing. Every ship is recorded in the site's activity log with a rollback point, and rollback restores the previous file exactly and returns the item to approved.

Publishing is restricted to an explicit allow-list of hosted domains. A live commercial storefront can be deliberately excluded from auto-publishing while still being audited — the engine will produce the fixes but never overwrite the page.

Available now

A11 Step 11 — Daily operation

Once activated, a site receives a bounded slate of fresh work per run: 2 new content briefs (advancing a persistent topic cursor so topics rotate rather than repeat), social drafts for the lead topic, and one rotating growth asset chosen to avoid duplicating a type already pending.

Production is capped at 32 pending items per site. When the queue is full the engine stops producing and waits for the owner — the queue can never balloon into an unreviewable backlog. Each run appends to the site's activity log and score history, so movement over time is preserved.

B1 Content briefs Available now

Fields: title, keyword, outline[], points[], cta, channel, publish_date, source. The outline always opens with a 40–60 word direct answer (quotable by answer engines) and always includes an FAQ section — populated with the site's real questions where they exist, or composed from the site's real sections where they don't. Provenance is one of: From your onboarding article ideas · From a real page on your site · From the site's live "…" section · Niche-tuned cornerstone topic.

B2 SEO / AEO fixes Available now

Each fix carries before (what is live now), after (the recommendation), note (the rationale) and code (copy-paste-ready markup).

type   Title tag rewrite
before FerroSpring — Programmable (coded) magnets
after  Magnets that align, latch, spring, and hold — on purpose. | FerroSpring
code   <title>Magnets that align, latch, spring, and hold — on purpose. | FerroSpring</title>

The set comprises: Title tag rewrite · Meta description rewrite · Schema / JSON-LD to add · Internal-link plan (built from the site's real H2 sections) · Publish /llms.txt · Publish /AGENTS.md · AISO refresh — FAQ schema.

B3 Social drafts Available now

Per-channel drafts (LinkedIn, X/Twitter and others) derived from the lead content topic, written to stand alone rather than merely linking. Drafts are produced only for channels the client marked active, and never post automatically.

B4 Growth & off-page assets Available now

C1 Industry Intelligence Available now

Each industry cluster is a curated, machine-refreshed store with a fixed schema:

A dedicated interface step presents this to the user: the competitive field with live positioning, sources worth citing, current developments, buyer pillars, product line and key concepts. The same data is injected into every content brief, which is what makes drafts read as sector-literate rather than generic.

Example (magnetics): competitive field K&J Magnetics, Eclipse Magnetics, Bunting Magnetics, Master Magnetics, Dexter, Apex; authority Correlated Magnetics Research; pillars Align, Latch, Spring, Hold, Detent, Twist-release, Shear resistance; 38 real products across 8 categories.

C2 Video pages Available now

One action assembles a /videos/ page of up to 20 videos on the client's subject. Videos are discovered per cluster by sector-specific queries, then each candidate is independently verified to be public and embeddable before inclusion — a dead or restricted embed never reaches a client page. The generated page is a responsive, lazy-loaded grid with title and channel attribution, canonical URL and description, and is published to the live site for hosted clients (with the same snapshot-backup discipline as any other publish).

C3 Portfolio management Available now

The "My Domains" dashboard lists every site the account owns: brand, domain, overall score, all five discipline sub-scores and niche — sortable on any column, searchable across sites, niches and fixes, and filterable by band (Strong ≥75 · Needs work · Rough <55 · Not reached). Selecting a site opens a detail panel showing its score and grade, discipline bars, the signals the engine read, and its full priority list, with a direct route into that site's workspace. A portfolio-wide run analyzes every site in sequence with live progress reporting.

C4 Client-facing report Available now

Every site has a branded, shareable report at a stable URL: overall readiness with a grade gauge, the five discipline scores, top findings with evidence and remedy, a 30/60/90-day roadmap, a live signal strip (title length, word count, headings, sitemap URLs, JSON-LD blocks, internal links, social profiles, Agents-First status) and real sample deliverables. It is generated server-side from the same workspace data the application uses, so a report can never disagree with the dashboard.

C5 Weekly digest Available now

A scheduled email per account: site count, average readiness, per-site score with week-over-week movement (computed against a snapshot taken at each run), items awaiting approval, and what shipped live that week — with a direct link to the dashboard. Delivery is controlled per audience, so digests can run internally before being extended to clients.

C6 The account center Available now

Every registered user has a self-service account center at /account/ — the single place a customer manages their relationship with the product, requiring no administrator involvement.

C6.1 Stored payment methods — primary and backups

The billing section is a wallet, not just a link. Every method the customer has saved is listed on the account page with its type, brand or bank name, last four digits and expiry, and is clearly labelled Primary or Backup:

💳  Visa ···· 4242        Card · expires 09/29          [ Primary ]
🏦  Wells Fargo ···· 6789   Bank (ACH) · Checking        [ Backup  ]

2 methods saved · the Primary method is charged; backups are used
automatically if it fails
     [ Add a payment method ]   [ Manage & set primary ]

• Primary is the method charged on renewal — the processor's default payment method for the customer.
• Backups are retained on the customer record and used automatically if the primary is declined or expires, so a failed card does not interrupt service.
• Add a payment method deep-links straight into the processor's add-method flow and returns the user to the account page.
• Manage & set primary opens the full portal to reorder, remove, or promote a backup to primary.
• With a single method saved, the page prompts the customer to add a backup; with none saved, it explains what to add and why.

C6.2 Bank transfer (ACH) — offered by request on the corporate plan

Card and debit are self-serve for every customer. Bank transfer is not self-serve. It follows the model used by established infrastructure vendors: it is offered only on the top corporate tier, the customer must request it, and a human reviews and enables it. This protects against ACH fraud and chargeback exposure, keeps bank-debit volume with vetted accounts, and gives the operator a natural touchpoint with the highest-value customers.

The approval workflow

1. Customer on the Command plan clicks Request bank transfer (ACH).
2. The account is flagged requested and the operator is notified by push and email.
3. The request appears in the admin console beside that account with an 🏦 ACH requested badge and Enable ACH / Decline ACH actions.
4. On approval the account is flagged approved and the customer is emailed automatically that bank transfer is now available.
5. The customer adds a bank account through the processor's hosted verification flow (micro-deposit or instant verification), then sets it primary if they wish.

The ACH endpoint is guarded server-side: a request from an account that is not approved is refused regardless of what the interface offers, so eligibility cannot be bypassed by calling the route directly.

Payment-data handling — a deliberate architectural boundary

Although the account page displays what is stored, the application never renders a card or bank-account input field and never receives a card or ACH number. It reads back only non-sensitive metadata — brand, bank name, last four digits, expiry — for display. Payment-method management is delegated entirely to the payment processor's hosted billing portal: the account center creates a scoped portal session for the signed-in user's customer record and redirects to it; the processor returns the user to the account center when finished.

A single durable customer record is created on first billing use and reused for every later checkout, so payment methods, invoices and subscription history remain one continuous account rather than a series of disconnected transactions.

C6.1 Roles

The role is a per-account flag that can be granted or withdrawn without affecting the user's own data; administrators retain a normal account center of their own.

D1 Data model

One JSON document per site. Top-level keys as stored in production:

{
  domain, brand, niche, owner, created, updated,
  analysis: {
    domain, url, brand, niche, analyzed_at, reached, reach_reason, http_status,
    signals   { … 26 extracted fields … },
    research  { pages[], real_topics[], faqs[], competitors[] },
    cluster,                       // matched industry knowledge base
    extra     { sitemap_pages, llms, agents_md, robots, openapi,
                mcp_card, ai_plugin, index_md, traffic, reach },
    scores    { overall, SEO, Content, "AI Search", Social, Technical },
    checks[]  { area, label, state, why, fix, w },     // all 51
    priorities[], roadmap {d30,d60,d90}, calendar[], social[],
    recommendations { seo[], aiso[], cro[], analytics[], paid[], research[] }
  },
  intake        { … onboarding fields … },
  checklist[]   { id, text, area, done },
  deliverables[]{ id, kind, type, title, keyword, outline[], points[], cta,
                  channel, publish_date, source, status, created, edited,
                  before, after, note, code,
                  ship_applied, ship_target, ship_backup, shipped_at },
  approvals{}, connections{}, activity[], score_history[],
  activated, activated_at, topic_cursor, seq, loc, last_run, videos_page
}

Deliverable kind values in production: content, seo, social, leadmagnet, coldemail, pricing, abtest, socialhooks, positioning, competitor, research, socialplan, linktargets, linkoutreach, digitalpr, designbrief, weekplan, editorialplan.

D2 API surface

All endpoints are authenticated at the edge and receive the caller's identity headers.

D3 Interface map

A single-page application in which every view is a deep-linkable URL, so any screen can be bookmarked or shared. Views are grouped in the navigation rail:

A persistent control returns the user to the portfolio from any view at any window size; on narrow viewports the rail collapses behind a labelled menu. Logged-in users land on their dashboard (or directly on their site, if they manage only one); logged-out visitors receive the public marketing page at the same address.

D4 Security & data integrity

• Edge authentication on the application and its data API; the account service is the single authority for access decisions.
• Per-account isolation — workspaces are owned on first analysis; non-administrators can only enumerate and open their own.
• Plan enforcement in depth — the site limit is resolved by the account service, carried in a header and enforced at the point of creation in the engine.
• Secure recovery — password reset via a signed, time-limited link with no account enumeration.
• Payments — handled entirely by a PCI-compliant processor with server-authoritative pricing; the platform never stores card data.
• Publish safety — allow-listed domains only, snapshot before write, one-click rollback, and an activity log of every live change.
• Content integrity — no fabricated metrics; unreadable pages rejected rather than scored.

D5 Non-functional characteristics

E1 Deeper competitor analysis Roadmap

Today: the engine names the competitive field, fetches competitor homepages for positioning, and produces a competitor-teardown asset.

Proposed: promote this from context to a measured discipline —

• Full competitor audits — run the same 51-check model against each named competitor and store their scores.
• Side-by-side gap matrix — client vs. rivals across every discipline, with the specific checks where the client is behind.
• Content & keyword gap — topics and questions competitors cover that the client does not, ranked by opportunity.
• Schema & AEO gap — which rivals are winning answer-engine citations and the markup that earns them.
• Share-of-voice tracking — movement against the field over time, not a one-off snapshot.
• Change alerts — notification when a tracked competitor materially changes positioning or publishes in a target topic.

E2 Expanded video library Roadmap

Today: 20 verified embeddable videos per industry cluster, one-click page build and publish.

Proposed: more videos per cluster with per-category playlists and paginated pages; sub-topic pages (e.g. a page per product category); short text summaries and transcripts for SEO/AEO weight; VideoObject structured data on generated pages so the videos themselves become answer-engine assets; the client's own channel featured alongside curated content; freshness scoring to retire stale videos automatically; and per-page refresh scheduling.

E3 Long-form draft generation (metered, opt-in) Roadmap

Today: the engine produces the brief — structure, sources, keyword, angle and direction — and a human writes the piece.

Proposed: an opt-in tier that turns an approved brief into a complete long-form draft, grounded in the same real research and industry knowledge, priced as a metered add-on so cost remains explicit and controllable. The human approval gate is unchanged.

E4 Publishing & scheduling integrations Roadmap

Today: on-page fixes publish to hosted sites; content and social are produced as drafts for manual posting.

Proposed: authenticated connectors for common CMS platforms and social networks so approved items schedule and publish on a calendar, with per-channel queues and a unified publishing history — retaining approval-before-publish.

E5 Measured outcomes Roadmap

Today: reach is measured where traffic data exists, and score history is recorded per run.

Proposed: first-class analytics and search-console integration — keyword and ranking movement, answer-engine citation monitoring, and attribution that ties measured lift back to the specific changes the engine shipped, closing the Audit → Draft → Approve → Ship → Measure loop with client-ready evidence.

E6 Platform & scale Roadmap

• Cross-domain single sign-on across the branded deployment family (today each domain authenticates separately).
• Client-authored industry clusters — a self-service editor for the knowledge base.
• Agency multi-tenancy & white-label — sub-accounts, client-branded reports, delegated approvals.
• Public API & webhooks — programmatic analysis, deliverable retrieval and event notification.
• Team roles & audit trail — multiple users per account with scoped permissions and per-user action history.
• Localization — non-English analysis and generation.

F1 Time-to-value: the first ninety seconds Roadmap

Observed problem. A new user enters a URL, waits through a live fetch, and then lands in a system with 18 navigation destinations and ~28 pending deliverables. The product's value is real but it is discovered rather than delivered. Nothing in the first screen says "here is the single most valuable thing you should do right now."

Proposed design

• The "first win" screen. Immediately after the first analysis, present exactly one screen: the readiness score, the three highest-impact fixes, and one primary button — Fix the biggest one now. One click ships one real improvement to the live site (or copies the snippet). The user experiences the product's core loop before being shown the product.
• Progressive activation. Do not generate 28 deliverables on first activation. Generate three, prove the loop, then offer Generate the full slate. Volume should be earned, not imposed.
• Live analysis narration. Replace the wait with a running commentary of what the engine is actually reading — "reading your homepage… found 4 interior pages… checking structured data… comparing against 6 competitors in your sector." The wait becomes a demonstration of depth.
• Instant preview before signup. Allow an unauthenticated visitor to analyze one URL and see the score plus two findings, gated only at the point of acting on them. The score becomes the acquisition hook.

Acceptance criteria. A first-time user ships or copies their first real fix within 90 seconds of arriving, without visiting a second navigation destination; ≥60% of first-run sessions reach a shipped or copied fix.

F2 Approval at scale: the reviewer is the bottleneck Roadmap

Observed problem. The engine produces faster than any human approves. A production portfolio currently shows 2,557 items pending approval across 248 sites. At that volume the approval queue stops being a control and becomes an obstacle — the human gate silently becomes a wall, and the value already produced sits unshipped.

Proposed design

• Confidence scoring per deliverable. Every item carries a machine confidence (0–100) derived from signal strength, reversibility and blast radius. A title rewrite on a page with a 12-character title is high confidence; a positioning statement is low.
• Trust tiers, set by the user. Three explicit modes per site: Review everything (today's behavior) · Auto-approve high-confidence reversible fixes, review the rest · Auto-approve all reversible on-page fixes. The gate remains, but the user chooses where it sits. Irreversible or outward-facing items (email, publishing) are never auto-approvable.
• Batch review surfaces. Group identical fix types across the whole portfolio — "Meta description rewrite · 61 sites" — with a single scannable list, per-row diff, and Approve all / Approve except…. Reviewing 61 similar items should take one screen, not 61.
• Triage ranking. Order the queue by impact × confidence ÷ effort rather than creation date, and show the projected score movement per item ("+4 readiness"). The user always works the highest-value item first.
• Queue health signal. Surface age and backlog explicitly ("31 items older than 30 days") and pause production automatically for sites whose queue has gone stale, rather than continuing to add.
• Keyboard review mode. A dedicated full-screen reviewer: J/K to move, A approve, R reject, E edit, U undo. Power users should clear 100 items in minutes.

Acceptance criteria. Median time-per-decision under 4 seconds in batch mode; portfolio pending backlog reduced by ≥80% within two review sessions; zero auto-approved items that are irreversible.

F3 Progressive disclosure and role-based modes Roadmap

Observed problem. The navigation exposes 18 destinations to every user regardless of expertise or intent. A small-business owner who wants "make my site better" faces the same surface as an agency operator running 200 sites. Real users have been observed unable to find their way back to their own site list.

Proposed design

• Two modes, one product. Simple — four destinations: My Sites · What To Do Next · Approve · Results. Full — today's complete department view. Mode is a single toggle, remembered per user, switchable at any time, with no feature removed in Simple, only deferred.
• Role-shaped entry points. On first run ask one question — "Are you running your own site, marketing for a client, or managing a portfolio?" — and set the default mode, dashboard and digest cadence accordingly.
• Earned complexity. Reveal advanced destinations (Paid Media, Board of Advisors, Prompts) only after the user has completed the core loop once, with a persistent "Show everything" escape hatch.
• Task-based navigation. Supplement discipline-named sections ("SEO & AI Search") with intent-named entry points ("Get found on Google", "Get quoted by AI assistants") — users search for outcomes, not departments.

Acceptance criteria. A first-time user completes analyze → approve → ship without opening more than three destinations; navigation-related support questions fall to near zero.

F4 Explainability: never show a number without its reason Roadmap

Observed problem. Scores and recommendations are trustworthy — every one traces to a real signal — but the chain of evidence is not always visible at the point of decision. A user asked to approve a title rewrite cannot see, in that moment, why this title, what it will change, or what it is predicted to do.

Proposed design

• "Why this?" on every deliverable. An inline expander showing the exact signals used, the check it closes, the research page or knowledge-base entry it draws on, and the predicted score movement.
• Score attribution. Make the readiness score clickable down to the individual checks, weights and evidence — including what would change if you fixed this.
• Before/after preview. For any on-page fix, render the actual live page with the change applied, side by side with current — including the search-result and AI-answer preview, not just raw markup.
• Confidence and reversibility, stated. Each item labels how confident the engine is and exactly how it can be undone, before the user commits.

Acceptance criteria. Every approve/reject decision can be justified from the screen the user is on, with no navigation; measured reduction in rejected-then-reopened items.

F5 Learning from the user Roadmap

Observed problem. Users edit and reject deliverables, and the system does not learn. The same style of item that was rejected last week is produced again next week. Every rejection is a discarded signal.

Proposed design

• Rejection reasons, one tap. Off-brand · Wrong audience · Already done · Not a priority · Factually wrong. Five choices, no free text required.
• Preference model per site. Accumulate accept/reject/edit patterns into an explicit, user-visible and user-editable preference record — "Prefers shorter titles · Avoids exclamation marks · Rejects cold-email assets." The user can read and correct what the system believes about them.
• Edit-diff learning. When a user edits generated text, capture the delta as a style signal (length, tone, vocabulary) and apply it to subsequent generation for that site.
• Suppression rules. Reject a deliverable kind twice and the engine offers to stop producing it for that site.
• Brand voice profile. Let the user paste two or three pieces of their own best writing; extract measurable style attributes and hold generated drafts to them.

Acceptance criteria. Rejection rate declines measurably over a site's first 60 days; the preference record is legible and editable by a non-technical user.

F6 Mobile and asynchronous approval Roadmap

Observed problem. Approval is a short, high-frequency decision task — ideally suited to a phone — but it currently requires a desktop session in a dense application.

Proposed design

• Approve-from-email. Signed one-click approve/reject links in the weekly digest and in per-item notifications, with a confirmation page rather than blind action.
• A phone-first review surface. Card-based, swipe-to-decide, full item context on one screen, offline-tolerant with queued decisions.
• Digest as a working document. Make the weekly email actionable — the three highest-impact pending items inline, approvable in place, rather than a summary that requires a desktop follow-up.
• Scheduled review windows. Let the user declare "I review Mondays at 9" and have the engine time production and notification around that rhythm.

Acceptance criteria. A user can clear a week's queue from a phone in under five minutes; ≥30% of approvals originate outside the desktop app.

F7 Trust, error states and the honesty surface Roadmap

Observed problem. The system is unusually honest internally — it refuses to score unreadable pages and never fabricates numbers — but that honesty is under-communicated. A rejected site currently reads as a failure rather than as the system protecting the user's data.

Proposed design

• Explain every refusal in the user's terms. "We couldn't add this site because it's behind a login — the engine only scores pages a real visitor can see. Here's how to grant access."
• A visible data-provenance panel. Per site: when it was last read, which pages, what was blocked and why, what is measured versus unmeasured. Make the engine's epistemic limits a feature.
• An "unmeasured" badge, everywhere. Where reach or freshness cannot be measured, say so at the point of display rather than showing a bare number.
• Undo everywhere, stated everywhere. Every destructive or outward action names its reversal path in the same sentence as the action.
• Change log per site. A plain-language, chronological record of every change the engine made to the live site, with one-click rollback per entry.

Acceptance criteria. No error state that fails to state a cause and a next action; users can answer "what did this system change on my site?" in one screen.

F8 Accessibility, performance and craft Roadmap

• WCAG 2.2 AA conformance as a release gate: contrast, focus visibility, keyboard operability of every control, screen-reader labelling of score and status semantics (not colour alone), and prefers-reduced-motion support.
• Performance budget: interactive in under 1.5s on a mid-range device; virtualized rendering for portfolios of 500+ sites; skeleton states rather than spinners.
• Plain-language standard: a controlled vocabulary applied across the interface — one name per concept, consistent from button to toast to email. No unexplained jargon in a primary path.
• Print and export fidelity: client reports exportable to PDF with correct pagination, so the deliverable survives leaving the browser.
• Dark mode and density control for operators who live in the product all day.

F9 Instrumenting the experience Roadmap

None of the above can be evaluated without measurement. Proposed product analytics, privacy-respecting and first-party:

G1 Making the engine agentic Roadmap

Today the engine is a pipeline: it runs a fixed sequence — fetch, score, research, generate — and stops. It does not pursue goals, revise its own work, or decide what to do next. Making it agentic means giving it objectives, memory, and the ability to act and check its own results.

G1.1 Goal-directed operation

Replace "produce work every day" with "pursue the client's stated objective." The user sets a goal — "reach 80 readiness", "get cited by AI assistants for these five questions", "double organic traffic to the product pages" — and the engine plans backwards from it: selecting which fixes to prioritize, which content to commission and in what order, and reporting progress against the goal rather than against activity volume.

G1.2 The closed feedback loop

Today the loop ends at ship. Agentic operation closes it: after shipping a change, the engine re-reads the page to confirm the change took, watches the affected metric over a defined window, records the observed effect against the predicted effect, and updates its own prioritization model from the difference. Changes that reliably move the needle get promoted; changes that don't get demoted for that site type.

G1.3 Specialist sub-agents with real division of labor

The current role-agents are presentational groupings of one generation pass. Proposed: genuinely separate agents with distinct inputs, tools and success criteria — an Auditor that only measures, a Researcher that only gathers, a Strategist that sequences, a Writer that drafts, and a Critic that reviews the other agents' output before a human ever sees it, rejecting weak work internally. Quality rises because the first reviewer is not the customer.

G1.4 Self-verification before delivery

• Every generated fact traced to a source in the workspace or knowledge base; unsourced claims blocked from delivery.
• Every generated title, meta and schema validated against the standard it targets before it is offered.
• Every proposed link checked to resolve.
• A pre-flight check that a proposed change will not regress another passing check.

G1.5 Persistent memory per client

A durable record of what has been tried, what worked, what the client rejected and why, what the site looked like at each point in time — so the engine's hundredth week of work is visibly better informed than its first. This is also the substrate for F5 (learning from the user).

G1.6 Conversational operation

A natural-language surface over the whole workspace: "why did my score drop?", "what should I do this week?", "write three more briefs like the one about detents", "undo everything you changed on Tuesday." The engine already holds grounded structured state; this exposes it conversationally with actions attached, and every action still passes the approval gate.

G2 Agents-First: making the engine legible to AI Roadmap

Software discovery is moving from search results to assistant recommendations. When a business owner asks an AI assistant "what should I use to improve my website's marketing?", the answer is increasingly a short list the assistant composes — and a product that is invisible or illegible to assistants is absent from that list. The engine already scores its clients on Agents-First readiness across 17 AI-Search checks; the proposal is to hold the product itself to the same standard, publicly and verifiably.

G2.1 Publish the full machine-readable surface

G2.2 Structure every public page for extraction

• Rich schema, not boilerplate: SoftwareApplication with offers and ratings on product pages, FAQPage on every answer page, HowTo on every walkthrough, Article with author and date on every guide, VideoObject on video pages, Organization with complete sameAs identity — the exact "rich answer schema" test the engine applies to clients.
• Question-form headings that match real queries, each followed immediately by a 40–60 word directly quotable answer — the same structure the engine prescribes in every content brief.
• Stable canonical entities: one canonical page per concept (what a readiness score is, what AEO is, what an Agents-First site is), consistently linked, so assistants resolve the concept to this source.
• Visible freshness and authorship on every page, since both are weighted trust signals for AI answers.

G2.3 Be the citable source, not just a vendor

Assistants cite sources that define and measure things. The strongest position is to become the reference definition of marketing readiness:

• Publish the methodology. A permanent, versioned public page documenting all 51 checks — what each measures, why it matters, how it is weighted. Citable, linkable, quotable.
• Publish an open benchmark. Aggregate, anonymized readiness data by industry — "the average readiness score in home building is 54; 71% of construction sites have no FAQ schema." Original data is the single most cited content type, and the engine already produces it as a byproduct of normal operation.
• Publish a free public checker at a stable URL that returns a real score for any domain, with a shareable result page carrying full structured data. Every shared result is a citable artifact pointing back to the source.
• Maintain a glossary of record for the vocabulary (AEO, Agents-First, readiness, maxel-level specificity per sector) so assistants resolve those terms here.

G2.4 Eat the dog food, publicly

Run the engine against its own marketing sites, publish the resulting readiness score openly on the site, and keep it above 90. A marketing engine that publicly scores its own site — and shows the score moving — is both a credibility argument to buyers and a continuously refreshed, structured, highly specific page that assistants can quote.

G3 Search and answer-engine ranking strategy Roadmap

Classic ranking and AI citation now require different, overlapping work. Both are addressed by the same content engine the product already runs — the proposal is to point it at ourselves systematically.

G3.1 Topical authority through programmatic depth

• A page per check. 51 checks × a canonical explainer each — "What is FAQ schema and why does it matter for AI search?" — each with definition, why it matters, how to fix it, and a live example. This is 51 high-intent, low-competition pages that map exactly to what people search when they have the problem.
• A page per industry cluster. "Marketing readiness in home building: what 200 sites reveal" — powered by the benchmark data, refreshed automatically as the corpus grows.
• A page per comparison. Honest, specific comparisons against the categories buyers evaluate (audit tools, content generators, agencies), with a clear statement of who each is right for.
• Interlink by concept, not by navigation — the internal-link plan the engine already generates for clients, applied to our own estate.

G3.2 Answer-engine specific tactics

• Target question queries directly: harvest the real questions from client sites and support conversations, publish a definitive answer page for each, structured as FAQPage with a quotable opening answer.
• Optimize for extraction, not for dwell time: short paragraphs, explicit definitions, tables of facts, no critical information locked in images or scripts.
• Freshness cadence: a scheduled refresh of every cornerstone page with a visible dateModified, because staleness is an AI-answer disqualifier.
• Entity consistency: identical product name, description and sameAs identity across every deployment, profile and directory, so assistants resolve one entity rather than eighteen.

G3.3 Off-site presence assistants actually read

• Complete, consistent profiles in the software directories and knowledge bases that assistants ingest.
• Documentation and open resources published where developers and agents look (public docs site, structured changelog, versioned methodology).
• The open benchmark released as citable research with a permanent URL, inviting reference by journalists, agencies and assistants alike.

G3.4 Measure the thing itself

Track AI citation share as a first-class metric: periodically ask the major assistants the queries that matter ("best tool to audit a website's marketing", "how do I get my site cited by AI"), record whether and how the product is named, and treat that share as the KPI this program moves. This capability doubles as a client-facing feature (E5) — we would be the first to sell what we measure on ourselves.

G4 Competitive position, moat and sequencing Roadmap

Where the advantage actually lies

Proposed sequencing

4 Plans & commercial model

Administrator-approved free trials are available. Limits are enforced platform-wide and raise immediately on upgrade; re-analysis of existing sites is never limited.

Glossary

• AEO / AISO — Answer Engine Optimization: being found and cited by AI assistants, distinct from ranking in classic search.
• Agents-First — publishing machine-readable descriptors (llms.txt, AGENTS.md, read APIs) so autonomous agents can use a site correctly.
• Check — one of the 51 evaluated tests, each with state, evidence, remedy and weight.
• Cluster — a curated per-industry knowledge base.
• Deliverable — a produced unit of work moving through the approval state machine.
• Deep research — reading the client's real interior pages to ground generation.
• Readiness score — the weighted share of real checks a live site passes.
• Ship — apply an approved change to the live site, always with a rollback point.
• Workspace — the complete JSON state document for one site.