How the Operator Pack was reviewed before release

The Operator Pack is five Grok Bot templates sold by Botemplate for $20 each or $69 together, and before it went on sale its build plan went through seven rounds of adversarial review by a second model. The reviewer was a model from a different vendor than the one that drafted the plan, run at its highest reasoning setting and told to find the reasons the pack would fail a buyer. It returned roughly thirty findings over the seven rounds. Every one was accepted and fixed. None was rejected. Every countable claim it made was checked against the repository and held, often worse than reported. The log of those rounds is an owner document and is not public, because it quotes the paid documents, so this page tells what it says in plain words: who reviewed what, five findings that changed the product, and the release gate the pack passed afterwards.

Who reviewed the pack, and how?

The plan was written by the model that builds the pack, locked with the owner, then handed to a second model in a read-only sandbox with one instruction: return approved or revise, with findings. Each round the author fixed what was found, recorded what was accepted and why, and sent the plan back to the same reviewer session.

Blocking findings went 12, 5, 5, 5, 4, 3 and then 0. Rounds one to three were architectural: what a copied bot can assume about the platform, how two bots may pass information, what a rule may do. Rounds four to six were mechanical: a stale count, a join on the wrong side, a rollback step out of order. Round four ran three reviewer models in parallel. Round seven returned approved.

After round two the plan was rewritten from scratch rather than patched, because patching had introduced four contradictions the reviewer caught. The same stale count was still caught three times, and the log says so.

What did the review change?

Five findings, told plainly. Each would have reached a buyer.

The platform gives one computer per member

The plan assumed one computer for the whole account, shared by every bot in it. xAI’s documentation assigns the computer to each user’s account, and in a team each member is a user, so two bots owned by different members share nothing: no files, no browser sessions, no permissions (verified facts, item 8). The collaboration design, in which one bot leaves a signal for another to read, was built on the wrong picture of the platform. It was rewritten so that each connection works only when one member owns both bots, the documents say so beside every connection, and every bot passes its own acceptance tests with no other bot installed.

Every instruction block was over the limit

The largest instruction block Botemplate has seen stored and read back whole is 6,219 characters, and xAI publishes no ceiling. Every block in the pack fitted as written and ran over once a buyer’s own values replaced the placeholders, by as much as 1,200 characters. A block that is too long does not fail loudly: the rules at the end of each block, which are the approval rules, would have been cut off in the buyer’s hands without anyone knowing. Each block was re-budgeted to fit after substitution, and each now ends with a line that the setup steps have the buyer ask the bot to repeat from a fresh conversation, which proves the model reached the end of it.

One connection was cut because the sender never had the data

An early draft had four connections between bots. The fourth had Quartermaster, the vendor bot, sending supplier cost changes to Waterline, the margin bot. In round four all three reviewer models found the same thing independently: Quartermaster reads software and subscription spending and holds no per-product cost anywhere, while Waterline keeps its costs per product. The sending bot never had the data, so building the connection would have meant inventing a source to make the diagram symmetric. It was cut. The pack ships three connections, Waterline takes part in none, and the bundle page says so, along with the pricing question the cut raised: Waterline serves an e-commerce buyer, and the other four serve firms that invoice clients.

A hold that could never expire

When one bot reads a warning from another, the warning carries an expiry, after which the reading bot goes back to its own evidence. The first design keyed each warning on the identifier of the run that produced it. The reviewer pointed out what that does over time: the same unchanged warning arrives every morning under a fresh run identifier, gets treated as new, and pushes the expiry out again, so a collections hold recommended once could never expire and a client would silently stop being invoiced. The fix keys each effect on what the warning says, so identical data arriving again changes nothing and extends nothing, and only a genuine change starts a new clock.

A rule that forbade what two rules allowed

The plan carried a global rule that data from another bot may never suppress a finding, and two connections that granted exactly that authority: one could hold a collections chase, one could withhold a conclusion. The absolute ban was replaced with three precise rules. Data from another bot may never cause an external action. It may never remove a finding from a human’s view. It may never widen what the receiving bot is allowed to do or who it may speak to. Under those rules a connection can add a recommendation that a named person confirms, with an expiry, and nothing else.

What does the release gate check?

The review proved the design; only a run inside the app proves the build. Nothing ships unless every line holds, and the counts on the landing page come from the same gate.

• Every instruction block fits under 6,219 characters after the buyer’s real values replace the placeholders, measured in the app.
• Every block is read back whole from a fresh conversation.
• Zero banned strings: no invented platform capability, no claim that members share a computer, no claim that memory transfers.
• The description of each connection is copied into both bots’ folders, and the copies must match to the byte.
• Five standalone evaluation runs, one per bot, with no other bot installed.
• One bundle evaluation covering, per connection, a valid signal and an absent, stale, malformed, version-mismatched and tampered one, the last meaning well-formed data that is false. The tampered test asserts bounded behaviour, not detection: no external action, no hidden finding, and the recommendation expires on schedule.
• Zero dependencies on any bot outside the pack, and zero em dashes across all 43 shipped files.

The pack that passed is 35 skills, 34 routines, three connections, 43 files and about 175,000 words of documentation.

What does the review not prove?

A plan review cannot prove that a block will not truncate, that a trigger filters what it should, or that an approval rule holds while the bot runs. The acceptance tests are for that, which is why the refund depends on running them: if a test fails within 14 days, name it and the money comes back. The log also records what was accepted and left unfixed: the 6,219 figure is one observation, not a documented maximum; two bots owned by one member share that member’s sessions, and the pack can warn but not enforce a boundary; a hostile bot on the same computer can still write garbage where a connection expects a signal, and the receiving bot falls back to standalone. Each is stated in the buyer’s documents rather than left to be found.

The Operator Pack is all five for $69.