From Evidence to Commit and Back: The Full Iteration of an Autonomous SEO System

Scope and Claims

Our earlier publications described the architecture of an autonomous search optimization system and then its living strategy across ninety days.^[2][1] This paper documents the full iteration of that system as it ran on October 24, 2026, after more than three months in production: the loop from evidence to a commit in the client’s repository and back to evidence, the contexts and processes that carry it, the decision system built to read its own measured outcomes, and the field record of the eleven properties that ran it in Full Autopilot, the platform’s mode in which the system authors, activates and ships its work without a person approving each step.

The claims are bounded by design. We show how the loop is built and bounded, what it did on the operator’s workspace, and what search visibility the eleven properties recorded between June 30 and October 18, 2026, with every window named. We do not claim that the system caused that visibility: a causal claim requires a declared treatment date and a prespecified counterfactual, which this record lacks, and the study that would supply both is stated in the closing sections.^[10]

Figure 1 shows the combined Search Console impressions and clicks of the eleven properties, week by week. Over the 111 days from June 30 to October 18, 2026 they recorded 435,461 impressions and 1,866 clicks.^[15]

Summary of Contributions

The contributions are listed in the order in which the paper documents them. Each is traceable to a versioned change, an executed contract test or a ledger read cited in the sources.^{[15][16][17][18]}

• A complete description of the loop as it runs, from evidence to a commit in the client’s repository and back to evidence, with the bound on every stage.
• Repository-native execution, in which the agent works in the client’s own repository and the platform alone publishes, verifies the deployment and the page, and can revert.
• A measured-outcome decision system: one priority order, routing to existing pages, consent by priority, settle holds and controlled 28-day assessments whose evidence may reorder work only within its class.
• Realtime keyword evidence inside the agent’s run, written back as page ownership that the next review reads.
• A scheduler that reports failure honestly: five daily parts, begin and end records for every part, and the rule that a pass whose every attempt failed is a failure.
• The economics of owned hardware: 241 orders and 58.6 hours of agent time, the 46.8 hours on owned desktops at no metered model cost.
• A field record of eleven properties that extends the September study by 21 days with its published series reproduced exactly, and corrects one of its rank figures.
• A recomputable data module from which every chart and every search-results table in this paper is generated.

Background: Four Iterations in Fourteen Weeks

The system was not designed in one piece. Its record shows four iterations, each closing a gap that the previous one exposed (Table 1).^[18]

Table 1. The four iterations of the system, July 13 to October 24, 2026

The scale of the change is visible in the record. Between July 17 and October 24 the service’s version advanced from 1.0 to 3.0.360 through 378 distinct versions, and the change log records 342 releases of the third major version, at a pace that rose from 20 in the week of August 31 to 89 in the six days from October 19. The ported engine grew from 53,566 lines of source in 21 files on July 18 to 177,251 in 185, and its tests from 105 lines to 181,643; on October 24, 4,586 test cases passed with none failing.^[18][19]

The founding observation, the port, the context work, the honesty taxonomy, the guardrail inversion, the silent-failure doctrine and the local-first queue are documented in earlier papers.^{[3][9][8][7][5][6][4]} This paper builds on them and does not restate them.

System Description: The Loop

Figure 2 shows the loop as it ran on October 24. Its first two stages are the living strategy of the September study.^[1] The eight that follow are what this iteration added or completed: a decision stage that reads measured outcomes, a context compiled for each order, execution inside the client’s repository, publication and verification kept on the platform, submission to the index, and a measurement that the next decision reads.^[17]

Four invariants hold across every stage. The strategy is a single authority with several projections, so two agents working one property cannot act on different versions of it.^[2] A measured row outranks a cached echo, and a missing source stays absent rather than zero. Every product rule is a recorded advisory, never a hold, a skip or a discard; only security and tenancy fences hold or refuse, among them the callback token, the commit claim, tenant pins, denied paths, the tenant’s protected pages, the stale-base fence, the configured publish mode and a genuinely new credential.^[5][18] And every stage writes its own receipt, so the loop can be read back from its ledgers rather than from an agent’s account of its own work.^[7]

The strategy layer remains the most active part of the loop. On the operator’s workspace 268 strategy versions have been activated since July 26, 170 of them in October, and the nightly review authored and activated 242 of them since September 12, 165 of those in October. On October 24 it created its first four new clusters, on three properties, each grounded in demand the review could list.^[16]

The Contexts Each Agent Receives

Every agent in the loop starts from a compiled context, never from the whole client state. The design follows a principle recorded as owner doctrine: accurate context outperforms restrictions.^[8][18] A model does not reliably use a fact placed in the middle of a long input, so each context is small, complete for its task and ordered by what the task needs first.^[11] Table 2 lists the contexts the system compiles.

Table 2. The contexts the system compiles, the agents that read them and their bounds, October 24, 2026

Two measurements describe how these contexts are used. A desktop article run processes about 5.9 million tokens and writes about 41,000; across the 205 runs with a usage record, 96.4% of the 1.13 billion tokens processed were cache reads, the prefix a long agent turn re-reads at each step.^[16] When a context must be fitted to its bound, the fit shortens the site inventory, then the strategy, then the evidence, before it ever touches the brief; a fix pack that is fitted now records an advisory instead of being cut silently, as 30 of 49 were before the October change.^[18][19]

Chains, Schedules and the Operating Day

The loop is carried by schedules rather than by a resident process. The schedule holds 15 jobs, which drive three orchestrators: a fifteen-minute tick of 18 steps, an hourly pass of 7 registered steps of which five or six run in any one hour, and a daily pass of 17 steps split into five separately scheduled parts. A morning refresh chain, four retention jobs, a weekly knowledge sync, a Monday position-tracking sweep and an hourly watchdog complete the schedule (Figure 3).^[16][18]

Work that does not fit one invocation is chained. A completing research stage dispatches its successor at once instead of waiting for the next tick. Research runs that had taken 49 to 179 minutes from creation to last update before that change shipped in July took a median of 22 minutes over the five runs completed in late July and August, 42 over September’s ten and 19 over October’s five; the context paper reported roughly six to eight minutes for a full run, and this ledger measure includes parks and retries. The setup drain and the morning refresh chain re-invoke themselves under a lease until their queues are empty. Model work that would outlast an invocation runs on the worker lane, which offers each job to a signed-in desktop first and to a cloud runner only after a grace of 255 minutes (Table 3).^[4][8][16]

Table 3. The chains that carry the loop, with the thirty days to October 24, 2026

Each step writes its own ledger row as it finishes, and each part writes a begin and an end record, because a part that the platform stops at its compute limit writes nothing for the steps behind it.^[6] Over the thirty days to October 24 the ledger recorded 55,236 step rows, of which 55,172 completed (99.88%), 61 were deferred, 58 of them by the time budget, and three failed, none twice in succession. That rate counts rows that exist. Measured against the schedule, 15 of 2,880 tick slots and 3 of 720 hourly slots wrote no row at all, and 531 of 548 expected daily step-days were present. Since the part records shipped on October 23, 206 of 207 parts have ended; the one that did not is the subject of a correction below. In the seven days to October 24 the ledger recorded 13,421 rows with no failed step.^[16]

Agents in the Client Repository

Many search optimization tools stop at a recommendation. A person must then translate it into the site’s templates, registries and build configuration, ship it, and remember to check whether it worked. Each of those handoffs loses context and time, and the last is often skipped. In this system the agent works inside the client’s own repository, and the platform carries the change from there to the live page and into the measurement. Seven problems change shape as a result.

• The implementation gap. The agent edits the files the site is served from, so a recommendation and its implementation are one order; a run that finds nothing to change is recorded as a finding, not a failure.
• Context loss. The agent reads the site as it is built, its components, registries and routes, which is why the file allowlists of August failed against legitimate work and gave way to advisory scope.^[5]
• Unsafe write paths. The desktop never pushes. The platform alone writes to the repository, one commit per order, as a direct push under Full Autopilot or a pull request under manual review, and a stale-base fence refuses a change written against a page that moved underneath it.
• Unverified claims. The live check reads the site’s own build or hosting deployment for the commit before it reads the page, and a failed site build mints one repair order.
• Irreversibility. Any dispatched commit can be reverted as one forward commit that lists the paths it refuses to touch, and a change an owner reverted is never sent again automatically.
• Disconnected measurement. The journal row and the page’s keyword ownership are written at the moment the change applies, so the measurement and the next brief know exactly what changed and where.
• The client’s own tooling. An unattended run loads only the runner’s own settings; the client repository’s instructions are read as data and its hooks are never run.

On the operator’s workspace the fix lane issued 84 orders between August 11 and October 24, 77 of them without human action and 9 from the page-optimization loop, and every one was a direct push on a Full Autopilot property. Of those orders, 30 were verified on the live page, 35 were committed and awaiting a verifier able to prove them, 6 completed with no change, 11 failed, 1 timed out and 1 was held for review. None was reverted, no failed site build was recorded in the thirty days the ledger keeps and no repair order has been minted; the deployment readback ran on 61 orders and the stale-base fence on 53.^[16] The article lane publishes through the same mutator, and 96 of its orders have been verified in the client’s repository and on the live page.

Autonomous Run Time and Its Economics

We measure agent run time from the claim of an order to its finalization, so the figure includes callback latency and the runs that ended at a reaper. Since June 3, 2026 the operator’s workspace issued 241 orders: 156 articles, 84 fixes and one report. Of these, 200 started with no human action, and in the last thirty days 112 of 118 did. The runs accumulated 58.6 hours of wall time: the median run lasted 8.5 minutes, nine in ten finished within 22.8 minutes and 223 of 241 within half an hour. Two stalled article runs, later superseded by an owner’s retry, account for 9.0 of those hours (Table 4).^[16]

Table 4. Agent run time by work, runner and outcome, all 241 orders, June 3 to October 24, 2026

Every article order created after August 13 and every fix and report order ran on a desktop runner: a machine the operator already owns, signed in to a model subscription. The runner records the real token counts of each run and no metered cost, because the subscription is a fixed cost. The 18 cloud article runs that carry a usage record cost $45.59, a median of $2.30 each; on the desktop lane the same work records no marginal model cost, and the budget becomes wall time instead.^[4][16] The doctrine draws the consequence that on owned hardware a run is bounded by time, not spend: a desktop article turn defaults to 45 minutes and may be set up to 240, a fix may run for up to 120 minutes and a group of fixes on one page for up to 180, and the cloud lane keeps its limits of 45 and 80 minutes.^[18]

The spend that remains is research data and the model calls the platform makes itself. Through the unified budget ledger the operator’s workspace settled $152.95 between August 17 and October 24, of which $60.30 fell in the last thirty days. In October the median property cost $1.83 to that date, against $10.96 in September, a month that carried ten cancelled research runs costing $40.05, and a complete initial research run settled a median of $2.82. The ledger’s one cloud writer reservation since mid-August, $2.25 on October 6, was settled at its estimate by the reaper after its dispatch never ran.^[16] At August’s effective metered rate the October desktop tokens to the 21st would have cost about $170; that is the price the subscription absorbs, and the subscription’s own limits, rather than money, now bound throughput.^[19]

The nightly reviews run separately on the worker lane: 284 have completed since August 23, a median of 2.4 minutes each and 14.1 hours in all. Their failure rate fell from 32 of 48 jobs in August to 22 of 122 in September and 3 of 171 in October, a change that coincides with desktop releases and the review’s working rules; the record does not isolate which change moved it.^[16]

The Decision System

The decision system released on October 21, 2026 is not a separate model. It is a set of seams that read what the platform’s own changes measurably did and pass that reading to the next choice of work (Figure 4).^[17]

Its gates are listed in Table 5 with their state on October 24. Three properties of the design matter most. First, routing sends any query the site already ranks for to the page that holds it, rather than to a new article that would compete with that page; the striking-distance band, positions 6 to 20, raises a page’s score but never decides its route. Second, learned evidence may only reorder work within its priority class, by a factor between 0.85 and 1.15, and missing evidence leaves the order unchanged, so a thin or noisy measurement cannot promote a weak change over a strong one. Third, a result counts only when it is supported: a full 28-day window after the change, a frozen baseline before it, at least three untouched control pages and no open confounder, where a change is beyond noise only when clicks or impressions moved by at least the larger of 3 and twice the square root of the combined counts.^[10][17]

Table 5. The decision system’s gates and their state on October 24, 2026

The receipts show the routing at work. Across 6 scheduled content runs the router classified 483 opportunities: 75.4% to improving an existing page, 11.8% to resolving which page owns a query and 12.6% to a new page and one to further research, with no supporting article qualifying, and 36 queued topics moved from the content queue to page work. The ladder minted 59 unattended orders and the page loop 9 between October 14 and 24, and no property has received more than 4 unattended orders in a day since both lanes began to read one pace rule on October 21.^[16]

The decision system reads outcomes only on full windows. An assessment compares the 28 days after a change with the 28 days before it against untouched controls, and a property’s learned factor holds its neutral value of 1 until it has five qualified supported observations, as it did across all 1,294 score receipts of October 24. The feedback half of the loop is deployed and writing receipts; its first full-window assessments fall from about November 21, 2026, and from then a supported result can reorder work, return a page to the ordinary queue or bring a decision to the owner.^[16][17]

Realtime Keyword Evidence

A decision is only as current as its evidence. The October iteration made keyword evidence available at three speeds, inside a run, every day and every week (Table 6).^[17]

Table 6. Realtime keyword evidence: channels, bounds and use on October 24, 2026

The most consequential channel is the first. A page or research order launches its one agent turn with exactly two tool servers: the platform’s own first-party reads and a keyword-data provider’s live tools, from keyword suggestions and ranked keywords to result pages, competitors and search intent. Paid calls draw on the project’s own monthly data budget, ten dollars by default, with no per-call rationing, so the agent can check a phrase’s demand and the live result page while it edits the page that should rank for it. When the change applies, the run’s report writes back which phrases the page now targets; a cluster’s owning page moves only through the nightly review, which reads volume, intent and these claims together.^[17][18]

Since October 14, 39 research orders carried the live tools; paid keyword calls on the same property fell inside the runs of 18 of them, 24 calls settling $0.41, an attribution by time window that an attended session in the same minutes would share; agents have written 69 ownership rows on 7 properties, 1.7% of the keyword map. On 4 of the eleven properties the query reads fill the 1,000-row cap over 28 days. Across 1,242 rank captures in the thirty days to October 24 an AI Overview appeared on 49.1%, and since citation capture began on October 18 the property was cited in it four times.^[16]

Breakthroughs and Efficiencies

Table 7 lists the architectural turns of the iteration: the changes that altered what the system can do, rather than how well it does something it already did.^[18]

Table 7. Architectural turns, July to October 2026

Table 8 lists the efficiencies the record measures on either side of a change. They are measurements of the system, not of search outcomes, and several coincide with other changes that the record does not separate.^[16][18][19]

Table 8. Efficiencies measured on either side of a change, July to October 2026

Read together, the two tables describe one movement. The system began as a pipeline that produced content and reported on it; each turn moved a decision that a person used to make, or a check that a person used to skip, into a mechanism with a receipt. The efficiencies are what that movement made affordable: work that once cost a metered call per draft now costs desktop time, and checks that were once impractical, such as submitting every new article or reading every deployment, now run on every change.

Materials and Method

The population is every property that ran the SEO Command Center in Full Autopilot on October 24, 2026: eleven properties, described by vertical and state under the anonymization policy of this index, under which no property, domain or client is named (Table 9). The seven properties of the September study keep their letters. We matched them by reproducing that study’s published series from the current ledger, and 67 of 67 weekly points and 394 of 394 trailing windows agree exactly. Site J is the property that study excluded with seventeen days of data; Sites K, L and M entered the program in October. Site I, a news network site read outside the ledger in September, is not part of this population.^[1][15]

Table 9. The eleven properties

The date a property entered Full Autopilot is not recorded, so its first strategy activation serves as the program-entry date. Several properties received earlier platform work; Sites B and C ran the earlier content pipeline from June 4. Search figures come from the daily capture of single-day Search Console totals, summed into Monday-to-Sunday weeks and fixed 28-day windows. Average position is Search Console’s impression-weighted figure for each window, which the platform’s totals request reproduces to within 0.002 of a position. Days before a property’s Search Console data begins are never counted.^[14][15]

The window runs from June 30 to October 18, 2026. It extends the September study’s window by 21 days and keeps its first 28 days, and October 18 closes the last week in which every property has seven captured days. Rank figures come from the weekly measured rank panel on its organic basis, in force since October 4. Operations figures come from the platform’s order, run, usage, budget, scheduler and learning ledgers for the operator’s workspace, which runs every property in the population; the scheduler ledger keeps thirty days. Every read was a read-only query made on October 24, 2026, and no paid call was made for this paper.^[15][16]

Results: Search Visibility

Measured as the September study measured, the first 28 days against the last, the seven properties of that study were level: the median impressions ratio was 0.98× and the median clicks ratio 0.99× (Table 10). Average position improved on six of the seven. On the constant roster of four properties with a complete series, clicks rose from 347 to 397 (1.14×) while impressions held (0.98×) (Figure 5).^[15]

Table 10. The first 28 days against the last 28 days (September 21 to October 18, 2026), 28-day totals

Over the most recent month the picture is modestly better. Against the 28 days before, August 24 to September 20, clicks on the nine properties with data across both windows rose from 468 to 522, or 11.5%, while impressions fell from 139,515 to 101,056; Site C’s seasonal fall from 86,788 to 47,928 impressions exceeds the whole of that decline. With Sites J and M, whose data begins inside the earlier window, the eleven properties’ clicks rose from 479 to 558. Across the nine properties the median ratio was 1.09× in impressions and 1.12× in clicks, and clicks rose on six of the nine (Table 11).^[15]

Table 11. The last 28 days against the 28 days before, properties with 28 days of data in both windows

The strongest result is Site D, a tree service in Kansas. Between the first and last windows its impressions rose from 10,648 to 17,930 (1.68×) and its clicks from 82 to 131 (1.60×), with average position improving from 24.1 to 18.5; its weekly impressions rose in each of the last three weeks, to 5,748 in the week of October 12, the highest week in its capture (Figure 6). The result holds on every instrument, and it needs two qualifications. Most of the rise from the June window predates the property’s entry into the program on August 18: against its own 28 days before entry the change is 1.23× in impressions and 1.13× in clicks. And the property received the fleet’s densest concurrent work, 39 journaled changes in the last 28 days, so no single change can be credited.^[15]

Site C, a heating and cooling contractor in Ohio, shows the value of a seasonal control. Inside 2026 its impressions fell to 0.84× of the summer window, a seasonal fall its 2025 data repeats, while its clicks held, 110 to 109, and average position improved from 26.2 to 18.2. Against the same 28 days of 2025, impressions rose from 12,871 to 47,928 (3.72×) and clicks from 37 to 109 (2.95×), at an average position 13.5 places better; the seasonal fall itself was milder in 2026 (0.53× from late summer, against 0.34× in 2025). Nine of the twelve months between the two windows predate the program, so the comparison describes the property, not the program’s effect (Figure 7).^[15]

Smaller results follow the same pattern of observation without attribution. Site F, a voice-automation software company, moved from an average position of 16.8 to 6.8 and held it, at a small absolute level. Site J’s homepage, changed six times by the system between September 13 and 21, rose from 1,609 to 9,937 impressions and from 10 to 32 clicks between the 28-day captures ending September 20 and October 18, the first weeks of a property new to Search Console. Site L stepped up on October 13, two days after it entered the program, on pages the system’s record does not cover; that step is reported and not attributed.^[15]

Three properties declined. Site G’s clicks fell from 15 to 8 between the windows, and from 26 to 8 against the 28 days before, a fall the closing audit traced mostly to its homepage; the cause is not established, and its diagnosis is the first open item on that property. Site H’s clicks fell from 22 to 6 while its impressions rose on a single new article that drew none, and its pages were split between two host forms until the system consolidated them after the window. Site B remained on the plateau the founding note described, with 104 clicks in the last window against 115 in the first.^[3][15]

Where the visibility sits matters for what the system should do next. In the 28 days to October 18 homepages held 60.7% of the fleet’s page-level clicks, and pages the system itself had published held 2.6% of page impressions and 2.6% of clicks; Site D is the exception, with 10 of the 15 clicks on system articles. The October decision system routes 75.4% of opportunities to existing pages, which is where the visibility already is.^[15][16]

Results: The System’s Own Measurements

The system keeps its own record of every change it ships. On the eleven properties the impact journal holds 320 changes. Of these, 39 have settled, all reviewed between June 11 and August 15 and all from before the noise floor existed; read through today’s outcome words they hold no measured improvement, 4 mixed results, 3 lower results and 32 changes implemented without a readable result. Another 85 closed unmeasured because they had no baseline, and 196 are in measurement, 161 of them from October, read under the noise floor introduced on October 22.^[15]

The learning system supplies what those unmeasured changes lacked. Since October 21 it has frozen 36 decisions and 24 pre-change baselines across the fleet, each to be read against untouched controls, and on October 24 its observer checked 57 sources in one pass with 0 errors. Its first full-window assessments fall from about November 21, 2026.^[16]

New articles have no baseline to compare against, so the system describes rather than judges them, with one immutable reading at day 28, 56 and 90. The first 54 day-28 readings, written on October 24, cover posts that went live between July 5 and September 24: 37 appear in the page data, with 2,708 impressions and 6 clicks in all, and 1,593 of those impressions belong to two posts of Site H.^[15]

On the rank panel’s organic basis the tracked non-brand keywords sit mostly beyond the top 20. On the latest captures 25 of 330 keyword-device rows rank in the top 20, 17 in the top 10 and 9 in the top 3, and over the one to three weeks of like-for-like captures 17 rows improved, 18 declined, two held their place inside the top 20 and 263 stayed beyond it. Local properties are visible in the map pack instead, where the property holds a top-three place on 50 of the 330 rows. An AI Overview appeared on 155 of the latest rows; since citation capture began on October 18 the property was cited on 4 of the 236 rows checked.^[15]

At the moment of submission Google reported 18 of 33 inspected articles indexed. Every article inspected within two days of publication was still unknown to Google, and 9 of 11 inspected three to eleven days after publication were indexed. The day-14 re-inspections fall from November 5.^[15]

Edge Cases and Verified Corrections

The cases below were identified by reading production rows against the code, most of them in the closing review of October 21 to 24, and each correction is pinned by an executed test or stated as a rule of this paper.^[19] The first corrects a figure in the September study.

The pattern is the one the earlier papers predicted: the model was rarely the failing component. A rank rule, a compute limit, a counting rule, a copy seam, a matching rule, a missing submission and a missing pace each produced a confident wrong answer that no prompt could have corrected, and each was found by reading the real modules against the real rows.^[7][19]

Expected Behavior in Production

Every behavior below is what the code and the live configuration will do if nothing changes. Each is a forecast with a source, not a measurement.^[16][17]

Table 12. Expected events, October 24, 2026 to January 2027

• Pace and consent. At most two open orders per site and four unattended orders a day; unattended fixes only within each site’s ladder; a manual send is never refused.
• Holds. A measured page waits for its window, 31 to 38 days; a changed page and technical changes wait 14 days; canonical and indexation verdicts wait at least 28.
• Spend. A blank monthly budget runs against a fifteen-dollar default and never blocks; a set budget binds; live keyword calls draw on a ten-dollar monthly default; raising a spend setting needs an owner or an administrator.
• Failure. A step whose every attempt failed reports failure; a third consecutive failure raises an alert; the watchdog reports any part that began and did not end within thirty minutes.
• Silence. No client receives a notification until their portal is active, and a report regenerated for accuracy keeps its one original notice.
• Capacity. Orders wait for a signed-in desktop, with the cloud runner an opt-in fallback, so the number of desktops online bounds throughput.

We expect the first measured outcomes in late November. A learned reordering will follow only after a site accumulates five qualified, supported observations of one change type, and it will move work by no more than 15% within its class.^[17]

Discussion

The September study described a system that optimized a policy: which intents a site should own, which pages own them and what to write next. This iteration closes the two edges that policy left open. On the near side, the decision now reaches the repository without a person translating it, and the platform verifies it on the live page. On the far side, the measurement is built to return as an input to the next decision under a controlled assessment, instead of a before-and-after that the system merely displays; the first full-window assessments fall from late November. To our knowledge no published system combines repository-native execution, deployment and page verification, and controlled outcome assessment in one scheduled loop across a portfolio of client sites, and we make the claim cautiously and would welcome a counter-example.^[1][12]

The engineering record is firmer than the search record, and it should be read that way. The system started 200 of its 241 orders without a person, its nightly reviews fail on 1.8% of jobs where they failed on two thirds in August, and its ledger now reports a silent kill as a failure rather than as an absence. The search record is consistent with the September study and no stronger: the seven properties of that study are level at the median over the longest comparison, the nine properties with both recent windows are modestly up in clicks over the last month, and one property rose consistently, most of it before it entered the program. The more instructive result is where visibility sits. Homepages hold three fifths of the clicks and system-written articles under 3%, and the decision system that shipped in October already routes three quarters of opportunities to existing pages. Whether that routing improves outcomes is the question the first supported assessments will begin to answer from late November.^[15][16]

The constraint on the system has moved. In July it was model cost; on the desktop lane that cost is now fixed. The binding constraints are execution capacity, meaning the number of signed-in desktops online, and measurement time, meaning the 28-day windows that a supported result requires. Both are properties of the design rather than defects, and both are stated as limits below.^[4]

Limitations and Future Work

• Eleven properties in one operator’s portfolio constitute a fleet record, not a sample; no control group exists and no treatment date was declared before the window.
• Program entry is dated by the first strategy activation because the mode change itself is not recorded, and several properties received earlier platform work.
• Seasonality is controlled for only one property, by its own previous year; for the others it is unknown, and impressions are visibility, not revenue.
• Search Console figures carry the provider’s aggregation and privacy thresholds; stored captures were capped at 40 page rows until October 19 and at no more than 100 query rows until October 21.
• The rank panel changed its roster, scope, basis and depth during the period, counting organic results only since October 4, and the September study’s market-city figures are corrected here.
• The scheduler ledger keeps thirty days, so reliability before late September rests on the change record rather than on the ledger.
• Run time is wall time from claim to finalization and includes callback latency and two stalled runs that together account for 9.0 hours.
• Desktop runs record no metered cost under a subscription whose price is fixed and whose usage limits bound throughput; a run also depends on the machine’s signed-in session, and a refused session ends the run, a case now classed apart from a writing failure.
• No business outcome, such as a call, a form or revenue, is measured, and no property has a validated conversion event, so the conversion arm of the learned factor cannot leave its neutral value.
• Ledgers and source are private; the series are published as a curated data module with every window and instrument named, and the search figures can be recomputed from it.

The next study is the one the compiler paper specified: a declared treatment date for each property, a prespecified counterfactual and a lagged comparison.^[2][10] The controlled assessments and the article cohort that shipped in October are the instruments it needs, and the first of them are expected to close their windows from late November.

Conclusion

Between July and October 2026, in production throughout, an SEO system built as a content pipeline became a closed loop. It observes, compiles a strategy, decides, briefs, executes inside the client’s repository, publishes, verifies, submits and measures, every stage writes a receipt, and its learning stage measures every change against untouched controls. On the operator’s workspace it started 200 of 241 orders without a person, ran 58.6 hours of agent time, 46.8 of them on owned hardware at no metered model cost, and kept every boundary a person owns.

The principal advances of the iteration are the edges it closed: implementation without a handoff, verification on the live site, realtime keyword evidence inside the run, and a decision system built to read its own measured outcomes on full 28-day windows. The search record across eleven properties is reported as observation. The discipline that produced it, executed tests over real rows and adversarial review of every change, is the practice we carry into the causal study.

Data Availability and Document Record

The series plotted and tabulated in this paper are published as a curated data module in which every window, instrument and capture date is named. Every chart, the search-results tables (Tables 9 to 11) and the run-time table (Table 4) are generated from that module and can be recomputed from it; the schematic figures, the context, chain, gate and channel tables (Tables 2, 3, 5 and 6), the change tables and the document record state their figures as read and are not derived from it. The platform ledgers and source are private and are cited by version and by executed contract suite.^[15][16][18]

Table 13. Document record