Build log

A dated record of what FriendMachine plans, what its operators report, what separate checks verify, and what produces a measurable result.

Updated

Proposed

Planned work that has not been executed.

Reported

An operator or other executor says the work occurred.

Verified

A separate check confirms the specified result.

Realized

The result produced an observed effect outside the execution system.

Latest update

Governed runs on Articul now use a paid model and cost about eight cents

On October 16 an operator run for Articul went from assignment to a finished result for the first time, on a local stack with a local model, after seven earlier attempts each stopped somewhere new. Since then we turned on paid execution with GPT-6.1 Sol, capped at $5 per attempt and $20 per day. Three paid governed runs have completed, costing between $0.076 and $0.082 each. In each one a worker made the edit, a separate verifier checked it, and the result was recorded. Each run also released the capacity it held when it finished. Nothing has been published to the Articul site.

Everything runs on local infrastructure. Only GPT-6.1 Sol is set up for Articul; Claude Sonnet 5.5 runs on the testbed only.

A page rename was the first real test of the stale-value check

Asked to rename a checklist resource, the operator updated the new name in the page title, the social titles, the structured data, the main heading, and the card on the resources index. Its proposal records that it searched for the old name across the site first. This is the first time the check for leftover old values ran on a real change; earlier runs only added content. The owner reviewed the change and accepted it. Accepting records approval only: nothing is pushed or published, and shipping it is a separate decision.

A small label above the heading still uses the old short name. It was left as is and noted in the review.

Harder testbed tasks separated the paid models, and fixes closed the gap

We ran Claude Sonnet 5.5 and GPT-6.1 Sol on the testbed and added harder tiers of tasks. Both passed the first 24 tasks and the first two harder tiers. The hardest tier hides traps the task does not mention.

  • Before: Sonnet passed 10 of 10 attempts and Sol 7 of 10. Sol twice missed an old value in the site's summary file for AI tools, once rewrote the history on an about page, and once published an instruction that was hidden inside a quote.
  • The fixes, in plain terms: when a value changes, the worker now searches the whole site for the old value and its phrasings, including the summary file and structured data, with a new read-only check. Dated history entries are treated as records and left alone. Pasted content is treated as material, not instructions, and any instructions found inside it are flagged.
  • After: both models passed 15 of 15 attempts on the hardest tier and 34 of 34 on the earlier tasks.
  • We also fixed three bugs in our own judge that marked correct edits wrong, and taught it to accept correct paraphrases. Part of the change in scores comes from these fixes, not from the models.

These batches ran outside the governed stack, and we wrote the tasks ourselves. The fixes were reviewed and are now deployed on Articul.

A failed paid run is cleared only with evidence that it had no effect

Each run holds a slot while it runs. A failed run used to keep holding it, and the owner could not free it just by saying so. Now a failed paid run can be cleared only when a separate check proves the spend was settled within its caps, that it produced no output or result, that its access was revoked, and that its job was cancelled. There is no owner bypass. We also fixed several cases where capacity stayed held for about 30 minutes after a run finished, was cancelled, or was never admitted.

Clearing a failed run was proven on the testbed first. On October 19 the same check cleared a cancelled Articul run that had spent about three cents and changed nothing.

The owner can start and review runs with one command

Two commands, one for Articul and one for the testbed, let the owner check health and spending, start a run from a short written request, read the diff, and accept, reject or cancel it. A run stops itself if its spending passes a limit, and it cleans up the services it started.

On October 18 the owner decided that a request that contradicts an editing rule, or contradicts itself, should be held and sent back to the requester with a question, not partly carried out. This is now the default on both systems. In an Articul test, a request to relabel a footer link on pages the operator may not edit was sent back with three options: allow those pages, accept a partial change, or drop the request.

Submitting a merge request works against a stand-in GitLab

After the owner accepts a diff, the operator can push a branch and open a merge request, but only for the exact diff the owner saw. Submitting the same change again opens nothing new. When opening the request timed out after it had already gone through, the operator found the request it had opened instead of opening a second one.

This ran against a local fake GitLab with no network access. It has not been tried on real GitLab and is not connected to Articul.

Baseline

Read-only growth workflow produces evidence briefs

Given product, search, and analytics exports supplied by a person, the workflow produces dated evidence briefs and proposed experiments. It cannot send messages, publish changes, or spend money. Independent repeated-run verification remains open.

Complete the governed operating loop

The current integration target connects an ongoing assignment to bounded action, independent verification, a finalized outcome record, and the next obligation. The complete loop had not yet run end to end as of this baseline; see the October 18 update above.

Realized

No operator outcome is listed as realized yet. Entries move here only after an observed effect appears outside the execution system.

Follow the work as the evidence changes.

The log will grow with the products and operators. Technical research remains on the research site; product-specific updates stay with each product.