DEV Community: zxpmail

The Definition Is the Kernel. What Still Runs After the People and the Model Change Is the Asset.

zxpmail — Tue, 13 Oct 2026 10:37:12 +0000

The Definition Is the Kernel. What Still Runs After the People and the Model Change Is the Asset.

2026-10-11

A while ago I read a piece from Tencent's engineering team. The real change, it argued, is not AI coding alone. It is the whole development process. Their OK platform delivers requirements end to end with AI. Automation is 68%. 51% of requirements finish within two hours.

The numbers are bright. They show that requirements can be finished fast. They do not answer a second question. In this way of working, what stays with the organization, and what leaves with the people and the model.

I spent an afternoon on that question with my boss. His judgments sit closer to this layer than that piece does. What follows is only the part that survives one test.

Change the people. Change the model. Change the vendor. Can the system still run at a similar quality and speed?

If it can, it belongs to the organization. If it cannot, it is one person's feel, one generation of model, or a lock-in to one vendor. "Quality" in that sentence cannot be graded by the system itself. The outside measure is in section 7.

1. A problem with no boundary is a wish

My boss opened with two lines. What problem are you solving. Who is it for.

Most teams landing AI stop one step earlier. "I want to study what software an industry needs." "I want to build a general agent platform." Those are wishes. A wish has nowhere to stop, and no way to be checked.

His split has three steps. What the problem itself is. Who is looking, and from which angle. Where the boundary is: the domain.

"Study industry software" became three problems, each able to stop. In the agent era, what software does an industry actually need. That is the demand baseline. What can current open-source projects provide. Are they stable. Can they be integrated. How large is the gap. That is the supply side. How software of any kind becomes components. That is the technical method.

Once they are separated, each one has a place to converge.

A definition decides what to do, and what counts as right. A definition written on a wiki and executed by no one is a liability. A definition welded to one set of tools, gone when the tools are swapped, is not yet an asset. The kernel is the layer that is still there after the carrier changes, and that can still constrain the next run. The toolchain and the runtime are the carrier. How that layer is drawn is in section 4.

2. There has to be structure. Structure inside the prompt cannot stop what already happened.

One line from him stayed with me. There is nothing wrong with form. Without form, the content has nothing to sit on. Without a body, what soul is there to talk about.

He did not mean more stamps on a document. He meant the content needs a structure to hold it.

Most prompts are one linear sentence. "Help me look up what software this industry has." The model can only guess. He asks for these, written apart: goal, context, conditions and constraints, output format, the agreements that matter, where to inject, which passage to cite. Goals can have sub-goals. Context loads as needed. Constraints go in by layer. Checkpoints in the flow are marked on their own, not mixed into the same sentence.

A prompt should be folded, injectable, and full of variables. The way a loop or a queue is organized in code is the way a prompt should fold. Longer is not better. Less redundancy and clearer folding work better.

This only says one thing. One linear sentence carries too little. It has not yet met the harder failure.

You write in the prompt, "if it does not pass, clarify." The model has already produced an answer. It treats the step as done, and goes on. Your sentence never gets a chance to run.

Structure is still necessary. Structure written inside the prompt is soft. For the flow to be able to stop, the check has to sit outside the model. A primitive in the runtime. A forced checkpoint in a script, before execution and after. No pass, no next stage. Whatever is not exposed can be bypassed. This is the same thing as design by contract. Preconditions, postconditions, and invariants are part of the system. They are not a reminder in a document.

If these checks live only inside one product, the set disappears when the vendor changes. What has to stay is what the check looks for. Where the check is built does not have to stay.

3. The same rule, put in two places, has two results

He had another abstraction. High-dimensional data can be used as a program. A program is itself data. Dictionaries, knowledge bases, specs, and rules look like data. When the structure is good enough, they drive the flow. A program can also be injected, folded, and combined. Write fewer fixed steps. Write the rules that generate the steps.

That sentence needs a minimal scene, or it stays a label. The scene takes only one kind of rule. If it is missing, there is no next step.

A cross-domain request needs five dimensions. The other side gave two.

Put "stop if the dimensions are incomplete" into the prompt. The model fills in the form, treats the step as handled, and continues.

Write the same rule as a record the runtime must read before submit. Five fields. Three missing. This step does not open.

The first hopes the model will obey. The second says the condition does not hold, so the next step does not exist in the flow. For a dictionary or a spec to act as a program, something outside the model has to read it. The model can be the machine that generates the content. The gate does not read a wish in the prompt. The gate reads the record.

He also made another comparison. Three of the five dimensions are themselves vague. There is no unique answer. Another person could not produce one either. That is a different failure. It belongs in section 6. The gate does not handle it.

4. The ontology describes the world. The gate checks this time.

The request in the last section was about the gate. It did not yet say how the gate relates to the ontology. One sentence here. The ontology describes what this world contains. The gate checks whether this time is allowed. A specification can say "confirm shipment." That does not mean this shipment may go. The gate has to stand independent of the ontology.

At the end of the conversation he reduced things to four words. Things, relations, actions, plus context. Entity, relation, action, context.

The split below is one I added while organizing this. He had not already separated it.

An action inside the ontology is a business verb. Check inventory. Confirm shipment. It describes what can happen in this world. A relation describes what connects to what. Context is the scene this time. Written down, this is a specification. It makes it possible for a person or a model to get it right.

An action on the gate is whether this time is allowed. Are the fields complete. Does it pass to the next stage. This layer is not written into the specification in the hope that it will be obeyed. It is a check at execution time.

He also split evolution into three levels. What a spec looks like in each domain is the top level. The concrete content under that shape is the middle level. A particular instance is the bottom level. Higher is more general. Lower is more specific.

The kernel takes only the layer that can still constrain the next run after the carrier changes. The shape of the spec belongs to this layer. It decides which slots exist, and what counts as right. Content in the slots counts only while someone keeps it true. If no one maintains it, the kernel is only the shape. Expired content can be carried across intact. The next run is no longer constrained by it.

What the check looks for is "what counts as right," taken and executed. The shape is how the problem's boundary, and that sentence "what counts as right," get written down. When the two sides match, it is still this one layer. When what the check looks for does not match "what counts as right," that is a fault. It is not an extra layer.

Which product this check is built into is the carrier. What leaves when the model changes is the instance inside one prompt, and the gate inside one vendor's product.

A general method, plus the entities of a domain, is what can land in that domain. That does not mean every industry must invent its own method. An empty template does not automatically become an industry conclusion. He later turned to manufacturing first. That is a decision. The meta-method lands in manufacturing first. It does not spread across every industry first.

5. Mistakes will happen. The cage decides whether you dare to use it.

One practical line from him. An agent cannot avoid mistakes. What matters is how a company dares to use an agent that will make them.

Give it a cage. A gate at the entrance. A check at the exit. Rollback when it is wrong. A person at the decisions that matter. When it reaches past its authority, a person decides whether to grant it.

The prior check sits in the cage too. Three of five fields are missing. That step should not start. Checking whether the input is valid is required. It is not something you look at after the run.

This check can stop a missing field. It cannot stop the case in the next section. The slots are full, and the problem still has no unique answer.

6. Two things are still unsolved

The direction is right. The conversation already showed two hard limits.

The first is how formalization continues. Structure, dictionaries, knowledge bases, specs. Who writes them. Who changes them. Who updates them before they expire. Too coarse, and they do nothing. Too fine, and they freeze. In the conversation this showed up as "it cannot be written," "it is too fragmented," "it is not normalized." That is not a team that failed to try. Formalization is expensive. Tools can lower the cost. People still find it troublesome. They call it formalism. When a person leaves, knowledge that was never written into the system breaks. That is a further layer. Why would an organization keep writing things down as structure. Tools do not lower willingness. The system can already be cheap, and people still will not use it. If no one maintains it, the kernel is only the shape.

The second is how you find out the structure itself is wrong. Back to that request. If the five dimensions are simply unfilled, the gate can close. The other half of what he said: three of them are themselves vague, and there is no unique answer. All five slots contain words. The gate lets the request through. Another person still cannot produce a unique answer. The gate can stop a missing field. It cannot stop "these five dimensions were the wrong five." It cannot stop a knowledge base running along a wrong map. Wrong content, kept as if it were true, still counts by the kernel's own ruler. So "the quality is still there" cannot be graded by the kernel.

A model that cannot read a structure that is too complex, or that gets worse when the context is too long, is today's floor on ability. This method cannot run in every setting yet. That floor is not a permanent boundary of the method.

7. What you can take with you

Models will be replaced. They will become ordinary goods. They will be open-sourced. Prompt technique will lose its price quickly. Rules that only sit on a wiki are a liability. Rules welded into one toolchain, or one product, disappear when the carrier changes. Those are not assets either.

What you can take with you is that layer. It is still there after the carrier changes, and it can still constrain the next run. The toolchain, the runtime, and which product the gate is built into, are the carrier.

Whether the quality is still there has to be read from results the kernel cannot alter. Can the thing that was handed over be used. Can the person receiving it actually take it. When it is wrong, can someone outside see it. A wrong kernel can move intact onto the next carrier and, by its own ruler, feel that it still runs well. That is still not an asset.

Apply the same test to the OK platform. 68% automation, and 51% of requirements finished within two hours, answer "fast." Fast is an outside number. It measures throughput. It does not answer whether, after a new model, a new group of people, and a new vendor, someone outside can still see a similar quality. That number is not there yet. Until it is, the piece shows throughput. It does not show an asset.

This is organized from an internal conversation. The judgments are my boss's. In section 4, the relation between the ontology and the gate, and the split of action into two layers, are additions I made while organizing. Collapsing the kernel into "the layer that can still constrain the next run," counting content only while someone keeps it true, and reading quality from outside results, are boundaries I drew while organizing. Other errors in the organizing are mine. This is a direction, plus engineering problems that are not finished. It is not a completed answer.

A General World Model Is Still Far. Next-State Prediction Already Runs.

zxpmail — Thu, 08 Oct 2026 08:14:54 +0000

A General World Model Is Still Far. Next-State Prediction Already Runs.

2026-10-08

World Labs put the phrase back in circulation. Marble turns a picture into a 3D scene you can walk through. Atlas, released in September 2026, is billed as a next-generation world model: text, images, video, and 3D go into one spatial context, and the model generates what comes next. It is meant to power later versions of Marble, and to feed robot simulation.

It looks as if machines are close to understanding the physical world.

A general world model is still far away.

That claim has to be split. Left in one piece, it is either empty pessimism, or the reverse exaggeration: a trajectory predictor in a car, called a finished foundation model.

1. The name covers three things

Generative world models. Sora, Genie, Marble, Atlas. A picture or a sentence goes in. A video, a 3D scene, or a new camera view comes out. Genie takes actions. Atlas does more than paint the next pixel. It puts several inputs into one spatial representation.

Looking right is still not understanding. Gravity breaks. Objects vanish. Over a long stretch the scene stops matching itself. The model learns what usually comes next. A larger scale might grow some physical intuition. There is not enough evidence to treat a demo as an ability. There is also no evidence that scaling cannot produce it. Leave both open.

Next-state prediction already running in engineering. This layer is old, and it often does not use the name. Trajectory prediction, occupancy networks, and ego dynamics in driving. Grasp and motion prediction in robots. Cloud simulators that manufacture rare cases and run closed-loop tests. The job is the same: given the state and an action, estimate what happens next.

Draw the line. Under this definition a bicycle model, a Kalman filter, and the physics engine inside a simulator all count. "World models are already in use" means this function is old. It does not mean a new foundation model is done.

Occupancy networks and trajectory predictors enter decisions because they write the world as grids, trajectories, and occupancy, and those can be scored. A collision is measurable. A miss is measurable. A generative model leaves the state in the picture, and a mistake often only looks a little odd. Both learn statistics. Both can break physics. The difference is where the state is written, and whether a mistake can be caught.

The general world model. This is the one Fei-Fei Li and Yann LeCun are after. One representation that holds 3D space and time, objects, cause, and interaction. It still works in another scene and on another body. It can answer what would have happened if the action had been different. Planning that uses it beats a special-purpose module in a closed loop.

That one is far.

2. "What was seen" does not give "what if I act"

The usual explanation is that data and compute are short, and enough of both will grow the ability. Atlas's own bet is the same: more training compute, more ability.

That bet is not falsified. It should not be treated as already falsified. Hard only means it cannot be done today.

The gap that can be stated is narrower. Next-frame training learns what usually follows what was seen. Planning asks what the world does if I take an action that never happened.

Records of what already happened do not separate the two. A cup falls because I pushed it, or because it slipped. Correlation can look convincing. Telling the cause takes an action, then the result. More samples make "what usually happens" more stable. If the data has no record of acting, intervention and counterfactuals do not appear on their own.

A few concrete difficulties follow.

Representation. Geometry, meaning, material, dynamics, and intent still live in different tools. One shared context means the model can read them together. Reading them together is not a representation you can intervene on.

Interaction. The model has to separate a change I caused from a change the world made on its own. Action has to be a condition, and the actions cannot be only the ones people already took.

Closed loop. On a robot, in a car, or in AR/MR, trying it yourself is expensive, risky, and full of rare cases.

Evaluation. Accurate pixels are not correct physics. Physics tests and closed-loop tests exist. They do not line up with each other, and they do not predict whether a system can ship. The missing piece is a standard that matches real action.

Latency. A car and a robot need low delay, and a failure that can be explained. Today's generative models do not sit in that seat.

3. Driving is the cleanest test

Some people say autonomous driving does not use a world model. On the vehicle it is perception, prediction, and planning. That is half right.

The vehicle will not run an explicit generative world model. Compute, latency, safety checks, and the need to explain a failure all forbid it. In that sense, driving does not run that kind of world model.

The vehicle still cannot do without "what happens next." Trajectory prediction estimates how other vehicles and people move. An occupancy network estimates which space will be taken. A dynamics model estimates how the vehicle responds after an action. Cloud simulation uses the same kind of method to build rare cases and run closed-loop tests. These are narrow predictors, and they can be checked.

When planning uses dynamic programming or model predictive control, this term is that predictor:

V(s) = min over a of [ R(s, a) + γ Σ P(s' | s, a) V(s') ]

A model-free method can skip writing down P(s' | s, a) and learn the action directly. Closed-loop control depends on how the environment changes, either as an explicit probability or welded into the policy.

An end-to-end network that drives shows that it reacts to the road. It does not show that a piece can be pulled out and asked, "what if I change lanes now?" Reacting and being available to ask are different things.

What the car already has is a special-purpose predictor on a narrow state: lanes, vehicles, occupancy. The argument is about another road, another kind of road user, an action never seen, and whether that answer is more reliable than the modules already there.

4. AR/MR supplies samples, not the model

AR/MR is often pulled into the same picture. Its value is not a few extra labels. In real 3D space it records, continuously and with position, what the scene was, what the person did, and what the scene became.

Camera pose, depth, meshes, and point clouds record space. Object class, material, and whether something can be handled record attributes. Gesture, gaze, speech, and grasp trajectories record action. The scene before, during, and after the action records order in time.

The samples are useful. They are still mostly trajectories of what was seen. Force at contact, mass, and friction are often missing from the picture. AR/MR is a data factory and a proving ground. It is not a general world model.

5. How to tell it is getting close

"Far" has to be something that can be proven wrong.

Long consistency. For minutes, objects remain, physics still holds, and the scene still matches itself.

Intervention. Given an action, the model predicts how the state changes. A next frame that merely looks reasonable does not count.

Counterfactuals. What if the action had been different. A harder check: two models can tie on "does the next frame look right" and disagree on "what if I had not done that." A high prediction score does not pin down the counterfactual.

Closed loop. On a robot or a driving task, planning with the model beats the special-purpose method already in use. This is the ledger. If the earlier items fail, this one does not arrive.

Physics. Gravity, collision, friction, and occlusion hold steadily, rather than by an occasional lucky guess.

Cause. It separates occurring together from causing. It supports both "I act" and "what if I had not."

None of these is stably met for the general case. "Still far" has criteria.

6. What is actually true

Next-state prediction, as a function, already runs in engineering. The thing called a world model, and expected to be a third foundation model after language models and vision-language models, is early. Across scenes. An action never seen. A counterfactual. A closed loop where it beats a special-purpose module.

On the vehicle, the stack is still perception, prediction, and planning. Large models carry meaning and reasoning. Next-state prediction sits in a special-purpose module, or is welded into an end-to-end policy. A generative model does not run there on its own.

In cloud simulation the method is already useful: rare cases, closed-loop tests, synthetic data.

AR/MR is a source of data and a place to check.

Robots are the closest proving ground, and the least mature. Here the system has to act and then see the result. "What was seen" and "I acted" start to come apart.

7.

Two extremes are both wrong in the same way. Each one flattens the word.

One says a world model is about to change everything. A demo is treated as an ability. Generation is treated as understanding.

The other says a world model is hype and useless, and throws out the predictors already running in cars and simulators.

The direction is right. Representation, prediction, and action in the physical world are a main line after language models and vision-language models. The work will enter driving, robots, and AR/MR in pieces, by domain, sometimes as its own module and sometimes welded into a policy. It will not arrive one day as a single general model and rewrite the rest.

Maturity is three questions. Can the world be written as a state a program can use. Can change be predicted reliably. Can the system act safely on that prediction.

On a narrow task, a lane or a grasp, usable versions of all three already exist. Change the body, the physics, or the action to one never seen, and all three break.

The third question is the watershed. The first two can stop at "looks real." The third requires the answer to be right, because a wrong action causes harm. In the general sense, that watershed is still far.

Ontology, Gates, and a Human Backstop: Three Defenses for Enterprise AI That Don't Spin Empty

zxpmail — Mon, 05 Oct 2026 11:12:50 +0000

Ontology, Gates, and a Human Backstop: Three Defenses for Enterprise AI That Don't Spin Empty

2026-10-05

Enterprise AI usually lands in one of two extremes.

One side says: build the ontology and the AI will understand. The other says: an ontology is soft, it cannot hold the line, and what matters is gates plus a human backstop.

Each side is only half right.

An ontology makes it possible for the AI to get it right. A gate makes it hard for the AI to do the wrong thing on its own. A human backstop keeps a mistake from becoming a disaster. Use the three together, and close the loop: the ontology hands objects and rules to the gate, the gate hands anything out of bounds to a person, and after the person handles it they ask whether a term or a threshold should change. Without that return path, people keep putting out the same fire.

The weight shifts with the scene. The short board sets the ceiling. High frequency, low risk, reversible: the ontology and automated gates set the experience and the cost. Low frequency, high risk, irreversible: the gate and the human backstop are what keep you safe. Heavy regulation and heavy responsibility: all three have to be hard. Open questions can tolerate a wrong answer. Data that should not enter the context still has to be stopped.

Whether this works is not a question of whether the article is complete. It is whether the three tables can be filled in for one concrete scene. A cell you cannot fill means that question may not be answered, and that action may not be taken.

1. What each layer handles

Layer	What it handles	When it fails
Ontology	Whether the system understands	The answer is fluent, and wrong
Gate	Whether it may, and whether the figure is the right one	It acts at random, exceeds its authority, or does something irreversible
Human backstop	Who is responsible, and how a mistake is written back	The damage cannot be undone, and the same kind of mistake keeps returning

Do not ask which layer matters most. Ask which layer is the short board in this scene, then ask whether that layer's table is filled in.

2. Ontology: start from a specification

An ontology here is a business specification: what a word means, what it does not mean, and which field on which document the figure comes from. It is soft, like an employee handbook. It does not itself block an action. The part that can be made hard has to become a check outside the model.

Split the content into two kinds first:

Kind	Where it lives	What a mistake does
Helps the model choose the right meaning	Terms, relations, definitions. The model may read them	The wording drifts, and can still be corrected
Must not be allowed to happen	Written as a program check	The action cannot occur

"Collected payment is not the invoice amount" is the first kind. Putting the words in a table does not stop the model from answering with the invoice amount. A wrong figure is stopped by the input gate: what is handed to the model this time contains only the field named on the authoritative source. The invoice amount is not included.

"Do not send it to the customer on their behalf" and "do not pay above this amount" are the second kind. Written into the prompt for the model to obey on its own, they are still soft.

Each common word gets four lines: how people say it, what it is, what it is not, and which field on which document is the authoritative source. "What it is not" matters most.

One word binds to one authoritative source. If a finance definition and a management definition are both legitimate, they are two words. Do not switch sources on the same word. When two owners disagree, follow the owner of this word, the person on the side of the authoritative source. When the definition changes, new documents use the new version. Documents that already happened keep the old version.

If the source has no record yet, the answer is "no figure yet." Do not fill it from another set of books. Also write how long the business can wait. If the wait expires and there is still no figure, point to a named person. Do not repeat the same sentence. If the wait is not written down, people will go look somewhere else, and this gate has nobody walking through it.

Write only relations that have actually been asked. Three to five is enough. Write the rules, and mark which kind each one is. A rule of the second kind lands on a gate at that moment.

Each word has an owner, an update trigger, a version, and a minimum set. It also has a reviewer and a review cycle. A trigger without a review lets the table go stale when nobody reports an error.

3. Gates: start from what is forbidden

Write what must never be done: which fields cannot be changed, which approvals cannot be skipped, what cannot be sent outside, which tools cannot be called, and above what amount a person is required. Talk about permission only outside that forbidden zone.

Level	What the system does	What the person does
Read only	Looks up and answers	Judges for themselves
Suggestion	Offers a suggestion	Does the thing themselves, including sending it
Confirmation	After the person agrees, the system does it	Agrees, and is responsible for what cannot be undone
Automatic	Does it directly, and leaves a trace	Can be inspected afterward, and can be rolled back
Forbidden	Does not do it	Not applicable

Anything not explicitly allowed is forbidden. If read-only is enough, do not grant a write. An automatic action must be reversible or have a remedy. The judgment sits outside the model. Waiting for a person has a time limit. When the time is up, the action stops. A stop is not the same as a person refusing, and it must not be turned into an automatic action.

Use the checkpoints the scene needs. All seven are not required:

Checkpoint	What the program does
Input gate	Which documents and which fields are allowed this time
Term gate	Checks an allowlist. Which words a conclusion may use is written in advance, and so is which slots the output has
Tool gate	Which tools may be called, and whether the parameters are allowed
Action gate	Which fields may change, and which states may move
Approval gate	Above a threshold, across parties, or outside the country, hand it to a person
Provenance gate	Compares only fields that have already been written down with the authoritative source
Audit gate	Who let it through, when, which version of the terms, which document

The term gate does not guess afterward which word the conclusion depended on. That falls back to letting the model judge for itself. The allowlist and the output shape are written first.

The provenance gate compares fields only. In collections, the amount, the customer, and the invoice number can be cells. The suggested wording is not compared. An analysis, a long conclusion, or a judgment tangled in several conditions cannot be made into stable fields, so do not install this gate there. Those scenes keep the input gate, the forbidden zone, and the audit. The conclusion stays with a person.

A confidence score the model reports about itself is not a gate.

To rise from "the system acts after a person agrees" to "the system acts on its own," write five things first. The count comes last:

What counts as one error. If that is not written, a count means nothing
Who decides it was an error. What they check against, and how much time is set aside for that check. If nobody decides, the action stays at its current level. A name with no time is only a stamp
The sample has to cover the main situations of this kind of action. A pile of easy cases is not enough, even if the count is large
The action can be undone, or has a stated remedy
If it errs again, it drops back one level

Low-frequency, high-risk, irreversible actions do not become automatic by accumulating a count.

4. The human backstop: the last layer

It has to exist. It cannot be the main path. People are expensive, they get tired, and they spread the responsibility thin.

Kind	What it does
Exception handling	Handles what a gate stopped, and what the program cannot match
Responsibility	Signs for an irreversible action
Return path	Decides whether the terms change, or the gate changes. If neither changes, write the reason

Escalate only when the case hits the allowlist, an approval, or provenance. Each backstop has a handler, a time limit, a next person, and someone who counts whether the time was exceeded. If nobody counts, the time limit is empty.

While the system only suggests and the person does the thing themselves, whether the amount was stated wrong is compared by the program. Do not ask another department to certify the sending. Certification is only for what the program cannot see: a source delay the business will not accept, or a disputed definition. Once the system sends on its own, a sending error needs a separate person to certify it, and that person needs the time above.

5. Fill the tables once, with collections

The scene is fixed. A salesperson asks about a customer's collected payment. The system answers from the finance receipt only, with an amount and a suggested wording. The salesperson decides whether to send it, and sends it themselves. This is a suggestion. It is not "the system sends after someone nods."

This scene has four output slots: customer, booked amount, whether anything is still unbooked, and suggested wording. The only conclusion word on the allowlist is "collected payment."

What can be filled in:

Item	Decision
What collected payment is	Money the customer actually paid into the company account
What it is not	Not the invoice amount, not the contract amount, and it does not include prepayment
Input	Only the booked amount on the receipt. The invoice amount is not included
Sending	No send tool. The system does not change the document
Provenance	Compare only the customer and the booked amount. Do not compare the wording
Unbooked	Say "no figure yet." Do not fill it with some other number
Level	Stays at suggestion. It does not rise

Empty, and therefore not allowed yet:

Empty cell	Therefore not allowed yet
Which system holds the receipt, and which field	The input gate cannot be drawn, so the amount cannot yet be a formal answer
How a customer id matches a receipt	Do not answer "this customer's collected payment"
How an invoice matches a payment received	Do not answer "whether this invoice has been paid"
Which day overdue starts, and after how many days it counts	Do not answer about overdue
How late the source may be	"No figure yet" cannot go live yet, or people will go around it
Who handles a mismatch, how long, whom they call, who counts timeouts	The backstop is only a name so far
Who reviews the three tables, and how often	The tables are not built yet
What counts as one error	The system does not send on its own yet, so this may stay empty. It must exist before the system sends

A management definition is a different word. This scene does not ask it, so that row is not built.

6. Different scenes trim the tables

The three tables are one way of filling things in. They are not a full copy for every line of business.

Scene	How the tables are used
Documents, processes, and fields are clear	The input gate, the allowlist, the provenance gate, and the audit gate can be used together
Low frequency, high risk, irreversible	Keep the forbidden zone, approval, and a signature. Do not schedule automatic action
Open questions, analysis reports	Keep the input gate, the forbidden zone, and the audit. Do not turn provenance into fields. A person owns the conclusion
Heavy regulation, accountability required	Every row used above needs a version, a person who certifies, and a review

Consider automatic action only for something that can be undone, and only after "what counts as one error" is already written.

7. Order of landing

Pick one scene. Write the terms and the forbidden zone first. Mark which of the two kinds each rule is.
Fill the three tables. A question you cannot fill in is removed from what may be answered.
Go live as read-only. Use a fixed set of questions to see whether the error is the definition, the wrong field, or a missing source.
Suggestion: the system suggests, the person acts.
Confirmation: the system acts after a person agrees. The person who certifies, the time limit, and the person who counts timeouts already exist.
The error definition, the sample, and the rollback are written before automatic action is considered.
Every backstop returns. On the review day, look for a stale table even if nobody reported an error.

Those are the column headers. Delete rows the scene does not use. Do not leave a gate that nobody walks through.

Ontology: term or rule, kind, definition, what it is not, authoritative source and field, owner, how to answer when there is no record yet, how long to wait, update trigger, version, reviewer and cycle.

Gate: checkpoint, rule, where the line is drawn, what happens after a stop, who agrees, who certifies an error, what happens when time is up, the log, whether it can be undone, the error definition required before a level rises, rollback, reviewer and cycle.

Backstop: what was hit, who handles it, how long, whom they call if they cannot, whether the term changes or the gate changes, whether it was finished, who counts timeouts.

8. Close

An ontology lets the AI know the business. A gate keeps the AI from acting at random. A human backstop keeps a mistake from becoming a disaster. The return path keeps the same kind of mistake from repeating.

If the tables for one scene cannot be filled in, the three layers are not there yet. The empty cells are the boundary of this defense.

Weld the Tenant Boundary on the Server

zxpmail — Thu, 01 Oct 2026 12:55:50 +0000

Weld the Tenant Boundary on the Server

Subtitle: A reported name can be noted. It cannot be trusted blindly.

2026-10-01

In a multi-tenant system, the cheap path is: the request path names an org, the token names an org, and the model passes an org again when it calls a tool. If the three agree, the data is treated as belonging to that tenant.

All three can be swapped. The path can point at someone else's org. The claim in the token can be only a hint. The model can fill in a different repo in its arguments. The cheap path treats "who reported the name" as "whose data this is."

This piece is only about how data is isolated. The per-layer rules and examples stay in the reference draft. They are not repeated here.

Binding happens on the server

A request may name an org, a project, and a repo. The claim in the token is only a hint. What counts is that the server finds "this person is actually a member of that scope," and only after that row comes back does it mint the context for this request.

Business code must not mint that context by hand. Minting happens at the entrance. Later functions take the context. They do not take identifier strings from the caller.

Org, project, repo, index, object key, and topic supplied inside a model tool call are dropped and written back from the context. If the model disagrees with the context, write an audit row and still execute against the context. Do not keep the model's value as a fallback.

Every data plane gets its tenant filter from the server. Tenant fields in the client, the URL, and the model arguments are not used.

The convenient leak is on the corpus

Two repos inside one org reading each other is a common leak in a coding assistant. Isolating business data such as orders by org does not stop this plane. Vectors, code objects, search, and repo caches have to be isolated by org and repo together. One tenant id pushed through every layer makes those two repos share one corpus.

The other cheap path is to check the token and skip the membership lookup, or to let a repo name in the tool arguments override the context. That implementation has to fail a negative test: cross tenants once on purpose, and the detector must catch it. A fully green suite does not show that the detector is wired in.

What this piece does not cover

How keys are generated, where they live, and how they rotate are not here. Whether the model vendor keeps prompts, or trains on them, is not here either.

Making ciphertext in backups unreadable, and actually deleting data on the vendor side, each needs its own procedure. This piece stops at: delete online data inside the scope the server already bound, and record the vendor's ticket number for the deletion request. The contract, zero-retention, and which region the data sits in are not spelled out.

Conclusion

People weld the tenant on the server: bind only after the membership check, and drop the names reported by the client and the model. The convenient leak is two repos in one org sharing a corpus, or letting the caller name the tenant. Keys and vendor retention are not in this piece.

Don't Treat 'Module Internals Don't Matter' as Unconditional

zxpmail — Tue, 29 Sep 2026 11:38:31 +0000

Don't Treat "Module Internals Don't Matter" as Unconditional

Subtitle: Urgency raises soft boundaries. A rules file pushes back behavior, not understanding.

2026-09-29

The essay Why the Best Software Advice Is the Hardest to Follow splits advice into two kinds:

Practical advice: small functions, no magic numbers, clear names. Teachable. Checkable.
Judgment advice: a wrong abstraction costs more than duplication; keep it simple; don't repeat yourself. No standard answer.

The conclusion is that the most valuable advice is the hardest to follow, because it is judgment, not a rule. I agree.

In the AI era I want one tighter limit:

People should move their attention up to the business, the cut, the boundary, and the contract. The inside of a module can be handed to AI more often.

But "duplication or abstraction inside the module doesn't matter, the AI understands" — the direction is right, and it must not be said as if it were unconditional. "Unconditional" here means treating it as a slogan that always holds.

1. The direction is right: move human attention up

Human attention is limited. If you spend the day arguing whether a function is over 20 lines, whether a name is good enough, or whether to extract an interface, you sink into the local and miss what actually decides the outcome:

What business problem is this? What is the core domain? How is the system cut? Where is the boundary? Who owns the data? Which way do dependencies point? What is the contract? Which changes must be isolated? Which decisions are irreversible? Who carries the risk?

Get those wrong, and pretty code will not save you.

So: people own business clarification, domain cuts, module boundaries, and contracts. How the inside repeats or abstracts can be delegated to AI more often.

On that part, I agree.

2. "Doesn't matter" has a premise. Urgency is more dangerous than "AI nature"

A typical failure: the team hands almost all in-module implementation to AI. It is fast. There are no contract tests, and no one has defined data ownership. Two modules, for convenience, both read and write the same table. On the surface this is "freedom inside the module." In fact they are quietly coupled through a shared table. Later one module changes what a field means. The other module's transaction boundary fails. The data diverges. Rollback does not come clean.

The problem is not that the inside is ugly. The problem is that the boundary was never actually hard.

Teams that do this well usually write the core interface schema, acceptance criteria, and data ownership into a rules file first. After that, however the AI-generated inside repeats or abstracts, the contract still holds it. The difference is not whether someone "uses AI well." It is whether the boundary was welded shut beforehand.

So this sentence holds only when the boundary is hard enough:

Inside the module, duplication or abstraction can be highly delegated.

And one more sentence, so it is not said unconditionally:

High delegation is not zero constraint. Readability, testability, and performance and security budgets remain the floor inside the module.

I originally wanted a fuller sentence: "AI systematically rewards soft boundaries." After a small reproducible experiment, that sentence had to be tightened — and the claim got harder, not softer.

A small reproducible experiment

Original claim: with no extra constraint, AI more often picks the soft boundary (reaching into another module's table).

Method: 3 cross-module tasks (order email snapshot / inventory marks an order shipped / billing reads a phone number) × each task A = soft (direct SQL/ORM) or B = hard (API or event) × 3 contexts (bare / speed, which urges "ship soon, change little" / hard, which writes data-ownership rules) × N=5, temperature=0.7. First run locally on qwen2.5:7b, then retested through the current Claude provider on cc-switch (glm-5.3-flash).

Script: soft-boundary-bias-test.py

Model	bare	speed	hard	Verdict
qwen2.5:7b (Ollama)	0% (0/15)	33% (5/15)	0% (0/15)	SUPPORT_SPEED
glm-5.3-flash (cc-switch / Zhipu)	0% (0/15)	73% (11/15)	0% (0/15)	SUPPORT_SPEED

Same shape on both models: bare and hard never pick soft; urgency lifts it. Speed is higher on GLM, but both are small samples (15 trials per condition). Do not extrapolate the size of the gap.

Tighten the conclusion once more:

bare 0% is not "AI defaults to the hard boundary." It only says: when both options are laid out clearly and there is no time pressure, the model showed no soft-boundary preference. That is already enough to correct "systematically rewards soft boundaries."
speed is the only clear signal. On qwen, all 5 soft picks fell on S3. On GLM the soft picks were more scattered (11/15), and the rate was higher. Fifteen trials per condition cannot be generalized, and 33% vs 73% is not a ranking of which model is worse.
hard 0% shows that a rules file works, with a caveat: the model may be obeying the rule, not understanding the boundary. What the rule pushes back is behavior, not necessarily judgment.

This run did not separate "ship soon" from "change little." Time pressure and change-suppression were written into the same urgency condition.

Closer to the data, under this setup:

When both options are clear, the model does not necessarily reach for the soft boundary.

Once you add "ship soon / change little," soft-boundary picks rise.

Writing data ownership into the rules can push that rise back down.

This correction is stronger than the original sentence. The problem sits on the low-friction shortcut under urgency, not on an abstract "bad AI." That is a more concrete reason to put the rules file first — not to defend against AI itself, but to block the shortcut AI takes under pressure.

A boundary is hard enough to delegate across when, typically: the interface contract is clear, invariants are explicit, data ownership is clear, dependency direction is controlled, boundary and contract tests are sufficient, performance and security have explicit requirements, and there is no cross-module shared write or hidden coupling.

3. How to make the boundary hard enough: a minimal sufficient set

Most teams do not need all of this at once. In the experiment, hard pushed soft back to 0%. That is reason enough to put the rules file first — just do not read obedience as understanding.

Means	When	Role
Rules file	Now	Default, required
Data ownership	Now (an organizational decision is enough)	Default, required
Spec before code	When rework is frequent	On signal
Contract tests	Modules ≥ 3, or interfaces change often	On signal
Architecture guardrails	People ≥ 10, or dependencies are out of control	On signal
Fitness functions	After the earlier items are stable	A monthly report can stand in for now

Minimal sufficient set: rules file + data ownership + a contract on the core interfaces.

The rest fires on signal. The order must not be reversed. Write the rules into .cursorrules / CLAUDE.md. A table or an event has one write path. Contracts and guardrails fail in a tool. They do not depend on someone remembering.

4. "The AI will understand" is not enough: feed context by risk

AI depends on context, not on unspoken agreement. More context is not always better.

	High risk / irreversible	Low risk / reversible
Glossary / constraints	Full	Minimal
ADRs / failure cases	Full	Summary
Contract / acceptance	Full	Core schema
Human review	Small steps	Automated tests + fast rollback

High risk gets the full feed and a human review. Low risk gets the minimum, with automation as the backstop.

5. What humans review: watch for abnormal signals

People own seams and contracts. AI owns implementation. You are not reviewing every line. You are watching whether these signals get worse:

Dimension	Abnormal signal
Module boundary	One PR often touches 3–4 modules
Interface contract	Breaking changes with no version; idempotency with no test
Invariants	Core invariants with no test
Dependency direction	Reverse dependencies and cycles rising
Data ownership	Multiple writers on one table; cross-module SQL
Non-functional / evolution	No SLO, high-risk items still open; cross-module changes and shared-table use trending worse

6. Judgment can be written down. Don't turn it into a new dogma

ADRs, failure cases, "when this principle does not apply," reversibility — these can be written for the AI and for the next person. A good form is:

At this risk level, we tend to …. If the following signals appear, judge again.

Rules and tests are constraints a machine can execute. ADRs and cases are preferences a person can update. "Functions must be under 20 lines" kills the judgment again.

7. Different teams, different moves

One principle: hold the floor at low cost. Do not pile on tools.

Size	Do	Hold off
1–3 people	Minimal rules + data ownership	Guardrails, full contracts, fitness functions
5–20 people	Rules + ownership + a spec for large changes + core contracts + light guardrails	Fitness functions (a monthly report instead)
20+ / microservices	Add weight on signal	Governance for its own sake
Legacy	Leave the stock alone, align the increment; trends before heavy tools	A full rewrite on day one

The tradeoffs: strict on the new, light on the old; strict on the core, light on the edge; strict on high risk, light on low risk; light on the stock, strict on the increment.

8. How an ordinary person grows the skill

Before each module, write three lines: What is it responsible for? Who owns the data? Who may call it?
After each refactor, record one judgment: situation / options / decision / reason / consequence / reversibility.
Each time you use AI, check the boundary once: a direct cross-module call? writing someone else's table? bypassing the interface?

The skill of writing code is getting cheaper. The skill of defining a boundary is getting more valuable. You do not leave the code. You stand higher, and you bring the code experience with you.

Conclusion

The direction is right: people should care about the business, the cut, the boundary, and the contract. The inside of a module can be handed to AI more often.

Two limits:

The boundary is hard enough, the contract is clear enough, the tests are enough — under urgency, especially, use rules to block the low-friction shortcut. That is what the experiment supports, not "AI is soft by nature." What a rules file pushes back is behavior, not understanding.
Feed context by risk — not "it will understand," but "give it the right constraint."

Finally:

People own the boundary and the intent. AI owns the implementation and the local optimization. The inside can be highly delegated, but it stays under the boundary, the tests, and the budgets for readability, testability, performance, and security.

Experience Admission for White-Box Agentic RL: A Position on Dataflow between Exploration and the Base Policy

zxpmail — Thu, 24 Sep 2026 10:27:41 +0000

Sixth and final in a six-part series on what building with AI agents did to one developer. The last piece ended under a blinking cursor in an empty title; this piece is that file: proposals marked as proposals, failure conditions written before the run.

Version: v0.19.3 · 2026-09-24 (aligns abstract with §6.4; separates r routing from update ban; clarifies ℓ timing before θ)
Genre: Technical position paper
Channel note: The author is a newcomer. arXiv (cs.LG endorsement) and the SEA Workshop (venue bar) were both blocked as channels, so this paper is published through neither, and no "submitted / forthcoming" claim is made. The claims and the falsification protocol stand alone, independent of any academic venue.

Abstract

In white-box observable-worker multi-worker RL, a layer is often missing between the optimizer and the collaboration interface: after trajectories are produced, who may materialize, at what granularity, and when θ may update. Black-box APIs are outside the strong-form claim.

This paper calls that layer experience admission control (below, the admission policy). The novelty sits in P1–P4 (a proposed admission policy) and preregistered failure conditions — not in a new score or a proven finding. Hypothesis-level claim: the bottleneck is often how experience is layered, isolated, and let into the base update path at low frequency — not more models seeing each other.

Layered verdict: fix 𝒜, vary only the data plane (A/B/P). No failure condition (1–5) fires, effective-materialization-ratio improvement ≥ 10% vs A, and return not persistently below A (condition 3 unfired) → §6.4 scale-up gate (may scale up; ≠ validated; ≠ must be a first-class module). If it still passes after scale-up → recommend building it as a first-class pipeline module; otherwise withdraw that configuration's strong form (the name may be retired).

Keywords: experience admission; proposed admission policy; white-box multi-worker RL; dataflow; falsification

1. Introduction

Discussions of multi-worker, asynchronous, long-horizon RL often conflate three question layers.

The optimization layer asks how gradients are computed and applied (e.g., group-relative methods [2], single-rollout asynchronous optimization [1]). The collaboration layer asks how multiple workers share context, files, and session state during interaction. The admission layer answers something else: after a trajectory has been generated, who may materialize it, at what granularity, and when θ may update.

The optimizer answers "when/how to update." The collaboration interface answers "how to coordinate." Neither directly defines admission semantics. Rising throughput can still expose noise and high-risk trajectories indiscriminately; shared context does not automatically yield isolation rules. Training stability is related to admission semantics but not identical to it: stability asks whether updates on a given visible set diverge; admission asks which trajectories may enter that visible set, and whether/how they are materialized first. An optimizer can learn to be more stable on a dirty visible set — it still does not answer the policy boundary of the visible set.

Scope (narrow first, then motivate). The strong form of this paper assumes workers can expose one of: hidden representations, local action distributions, or uncertainty signals. This covers self-deployed open weights and observable actor–learner setups. It does not cover mainstream closed API agents — those degrade, at most, into post-hoc text filtering, are never conflated with the strong form, and are outside the claim. LLM agents are one motivating scenario; the validation domain is the white-box observable setting.

In that setting the problem is not LLM-specific: long trajectories, asynchrony, and heterogeneous workers exist in classic deep RL too. IMPALA [5] and Hou et al. [1] live on the optimization/scheduling plane, where "delivered ⇒ learnable" can be the default. What this paper names is the admission policy after delivery. Shielding [9] shrinks action feasibility; CQL [6] constrains value estimates on a given dataset — neither answers layered materialization/update budgets on an online stream.

C1, a minimal counterexample (why "having PER on" is not enough). Suppose the buffer holds an ordinary learnable trajectory τ⁺ and a high-risk, high-TD-error / high-surprise τ‡. When PER [3] reweights by TD-error and τ‡ sits in a high-priority quantile, it can be sampled into the update batch at above-uniform rates; a rollout-time shield that blocks unsafe actions does not remove τ‡ from the training-visible set; deletion-style filtering discards its analysis value. Gap triad: P1 budget semantics absent (the trajectory is already in the pool and learnable by default — no "materialize-off-by-default" constraint) / violates P2·P4 / violates P3. The semantic gap: sampling weights ≠ admission policy.

Note: PER's sampling probability follows a power law in the priority quantile, so a high quantile does not guarantee a draw; but the reweighting mechanism in principle allows high-risk samples to reach the learner above uniform rates — this mechanistic "allowed" is exactly the semantic gap this paper names. Also: if a hazardous trajectory's TD-error is not high, PER will not raise its sampling probability — but that is no rebuttal of the admission layer: the hazard is then merely "unnoticed," not "quarantined and retained by a policy layer." P2's point is not "not learned," but "flagged, retained, analyzable."

So this paper does not replace the optimizer or the collaboration layer; it argues for an explicit data plane between them. Structure: contributions → P1–P4 and their logical interdependence (§3) → neighbors (§3.1) → interface and predicate (§4) → hypotheses (§5) → falsification protocol (§6) → objections (§7) → conclusion.

2. Contributions and non-claims

This is a technical position paper, not a methods paper.

Contribution one: restating the problem. "After trajectories are generated, who may materialize, at what granularity, and when θ may update" is promoted to an independent system layer. If the name can be fully absorbed by existing terms, the name should be retired. Even retired, P1–P4 and the §6 protocol remain independently testable as a system interface.

Contribution two: the proposed admission policy P1–P4. A minimal set of design differences relative to PER/deletion-style filtering, with a logical-interdependence argument (§3.2). The novelty is pressed onto four switchable constraints, not a fingerprint formula. No claim that empirical minimality has been proven by causal ablation.

Contribution three: a falsifiable protocol. A/B (plus a PER arm) and five preregistered failure conditions; condition 5 can fail the strong-form configuration on the current proxy family (§6).

Not claimed: theoretical guarantees; proven causal irreducibility; collaboration products as an RL baseline; optimality of placeholder parameters; strong-form coverage of black-box APIs; LoRA/cloud fine-tuning as main results; the appendix as proven method results; the §6.4 gate as validation success or "must be a first-class module."

3. The proposed admission policy: why it is not "renamed PER/filtering"

Terms (materialization vs deep read). In this paper, materialization means turning a trajectory from streaming state into an inspectable, persisted object; deep read means running costly analysis on materialized trajectories (full unrolling, replay, value estimation). In most implementations both fall under "admission cost," but they are logically separable — one can materialize then deep-read, or deep-read in streaming state and discard. For brevity, budget and metric contexts say "materialization cost" for both; when distinguished, materialization is storage-side and deep read is compute-side. D_read is the set eligible for materialization/deep-read — not the admitted-to-update set.

If the critic asks what remains once the name is removed, the answer is four design constraints. Only when enforced together as a policy is "experience admission control" worth using; any one missing in the long run retires the name. They are a proposed admission policy, not a published scientific finding.

Constraint	Meaning	PER usually?	Deletion-style safety filtering usually?
P1 materialize-off by default	Full materialization off by default; explicit authorization and quota required	No	No (judgments typically made on already-materialized trajectories)
P2 quarantine ≠ delete	High-risk trajectories can be barred from `D_adm` while keeping analysis value	No	Usually no (intercept or discard)
P3 materialization ≠ admission	Unrolled/inspected ≠ permission to update θ	No (sampled ⇒ learned)	Partial; observation and update rarely separated
P4 visible-set proper containment	When hot is nonempty, `D_adm ⊊ D_all` — not "all learnable, merely reweighted"	No	No (shrinks actions; does not define the training visible set)

P4 boundary. When hot is empty the sets may satisfy D_adm = D_all, but the strong form still requires P1/P3, and true containment must be restored once a hot-hazard appears. A long-run state of "hot empty + everything learnable by default" = the admission layer is not implemented.

Why P1 and P3 are not merged. They are logically separable: one can materialize without admitting; "admit without materializing" is the dangerous direction. The strong form forbids the latter as a default path: summaries may at most serve routing/promotion proposals; entering D_adm requires independent validation (§4). The names must stay separate, otherwise per-item ablation is impossible (§8).

PER can rank the warm tier; shields can flag hazards — neither automatically yields the whole admission policy. Calling TD-error reweighting "admission" is naming inflation.

3.1 Neighbors: why it is also not "renamed LLM data curation"

Preference filtering [10], RLAIF [11], RAFT-style rejection sampling [12], and alignment-pipeline filters [13] in LLM post-training optimize quality and labeling cost before the batch, usually with a default of: kept ⇒ update θ; dropped ⇒ out of training.

Neighbor	Usually optimizes	Still missing
Filtering [10]	Denoising, preference-data quality	Little separation of inspectable/updatable; discard ≠ quarantine-with-retention
RLAIF [11]	Scaling labels via AI feedback	No policy for the training visible set
RAFT-style [12]	Train only on high-score completions	Binary keep/delete; high score ≠ low risk; no quarantine track
Alignment filter [13]	Engineering data cleanliness	No multi-worker materialization budget, no hot→θ hard constraint

Neighbors are implementation components; not the same object. Multi-phase exploration (e.g., First Return, Then Explore [4]) shows staged policies like "return first, then explore" work in long-horizon settings, but its object is the exploration schedule and state coverage — it defines neither materialization budgets, nor a quarantine-with-retention track, nor an enforced proper containment of D_adm relative to D_all. Orthogonal to this admission policy, not a substitute.

3.2 Logical interdependence (counterfactuals): why the four come together

The following argues logical minimality, not causal ablation. Whether they are empirically irreducible remains §8.

Counterfactual	The policy degrades into	Therefore
Drop P1, keep P2–P4	The materialization budget vanishes → warm/hot partitioning loses budget meaning, leaving a labeling layer of "flagged or not"; behavior approaches an unbudgeted hybrid cache (isolation tags may remain)	Without the budget constraint the cost differential vs the passive pool is hard to sustain
Drop P2, keep the rest	High risk can only be deleted or learned as ordinary samples → degrades into delete-filter / no analysis track (near shielding + discard)	Without P2, "quarantine utilization" disappears
Drop P3, keep the rest	`D_read ≡ D_adm`: seen ⇒ learned → behavior approaches PER / the passive pool	Without P3, back to sampling-is-learning
Drop P4, keep the rest	The nominal three tiers and P1–P3 may remain, but when hot is nonempty `D_adm ⊊ D_all` is no longer forced: a hybrid cache with budgets/quarantine/materialization–update separation yet no enforced visible-set containment — still distinct from PER, but it has lost the visible-set-level policy difference	Without P4, proper containment cannot be enforced; not a return to pure PER

Why all four together (design level): each blocks one collapse mode — "default materialization / delete-or-learn / seen-is-learned / no visible-set hard constraint." With any one missing, the remaining clauses cannot alone support the complete admission-layer claim. P1–P4 as a proposed list should be proposed and tested together; dropping P4 is not a return to pure PER, but it abandons the full visible-set-policy spec. It does not mean an intervention experiment has proven them the world's unique minimal set.

Known limitation (empirical): no causal ablation yet of which constraint drives the behavioral difference vs PER. An aggregate A/B/PER win does not substitute for per-item mechanism validation (§8). Logical interdependence does not fill that gap; it only fends off the "four random engineering intuitions" accusation.

4. Minimal interface and the admission predicate

No full algorithm or formal system. Fix the interface + minimal predicate constraints so the objects are discussable and implementable.

The dataflow:

τ ϕ x r B adm D_{adm} A θ

adm is the admission mapping constrained by P1–P4; the optional review gate is an implementation component only.

φ: cheap, streaming, local (C3 placeholder, replaceable; not counted as a contribution).
r(x_t) ∈ {archive, warm, hot}: routes materialization / deep-read priority — not "who matters more," and not by itself the update ban. Update eligibility is decided only by the admission predicate (§4.1).
ℓ(τ) ∈ {promising, hazard}: assigned on the quarantine / analysis track. Before any write to θ, a still-hot trajectory must already carry an assigned ℓ; otherwise HotHazard is unevaluable and the trajectory stays outside D_adm. After labeling: hot ∧ hazard never enters D_adm; hot ∧ promising may enter only if Validated and InBudget.
Sets: D_read and D_adm are policy-separated; D_restricted excludes hot-hazard; when hot is nonempty, D_adm ⊊ D_all, and always D_adm ⊆ D_restricted.

4.1 The minimal admission predicate

τ \in D_{adm} ⟺ Validated (τ) \land \neg HotHazard (τ) \land InBudget (τ)

where:

HotHazard (τ) ⟺ (r (τ) = hot \land ℓ (τ) = hazard)

Validated is promotion validation independent of the routing score; InBudget encodes the materialization quota (P1) and capacity caps on the promotion channel (implementation detail; works with the P3/P4 gates, not owned by P1 alone).

Interaction with 𝒜: at any update step t, the optimizer's batch satisfies B_t ⊆ D_adm. 𝒜 need not internalize admission semantics; it only needs its input set constrained by the admission layer. If B_t ⊄ D_adm, that is a contract breach; if the breaching batch contains a hot-hazard, §6.3 condition 4 fires as well.

4.2 Minimal implementation contract

No hot-hazard enters a batch that updates θ.
Materialization happens in D_read; writes to θ go only through D_adm (P3).
Promotion requires validation independent of the routing score.
Archive is not materialized by default; warm materialization is budgeted (P1).
An optional gate must not enlarge the allowed sets.

Strong-form assumption: workers expose at least one observable signal; otherwise this is the black-box degradation, outside the claim. "Admit without materializing" is forbidden as a default path.

5. Testable hypotheses

These form the operational version of C2. The main protocol (§6) tests H1/H2/H4 plus P2's minimal execution integrity (condition 4: quarantine barred from updates + a nonempty quarantine must be read/used for peripheral analysis). H3 tests the "measurable peripheral value" magnitude of quarantine-with-retention; it is exploratory and does not enter §6.4.

H1 (primary): coarse routing + selective materialization lowers materialized volume relative to the passive pool while maintaining task performance.
H2 (primary): the three tiers, relative to binary filtering, retain analyzable anomalies without increasing base-policy contamination.
H3 (exploratory): quarantine-with-retention, versus immediate discard, yields measurable positive value on offline monitors/discriminators — condition 4 already forbids "quarantined but never read"; H3 further asks whether reading helps, and is not a §6.4 requirement.
H4 (primary): "low frequency" means limited update-contact frequency with the base policy and visible-set size — not learning rate / SGD step count; constrained updates are more stable than default-open ones.

5.1 H ↔ P

Hypothesis	Mainly depends on	On failure, first suspect	Protocol role
H1	P1	Condition 5 or condition 1	Primary
H2	P2+P4	Degradation to binary keep/delete; hot still entering updates	Primary
H3	P2 (value magnitude)	Read but no peripheral gain	Exploratory (§8); full enforcement via condition 4(b)
H4	P3+P4	Materialize ⇒ write; update-contact frequency ≈ passive pool	Primary

§6 tests the aggregate effect of the primary hypotheses; H3 and per-P ablations belong to §8.

6. Preregistered falsification protocol

6.1 Comparison

Same 𝒜, task, worker class:

Arm	Dataflow
A	Passive pool: materializable/replay-eligible by default
B	Admission: P1–P4 + §4 contract/predicates
P	PER on the same buffer — sampling weights, not admission semantics

6.2 Core metrics (minimal operational definitions)

Metric	Definition
Effective materialization ratio	materialized/unrolled volume ÷ total generated
Wall-clock/FLOPs	cost to reach the segment-return threshold
Task return	same protocol as A
Hazard penetration rate	share of hazard/hot-hazard in update batches
Materialization gain	on preregistered held-out probes, return improvement or loss drop after vs before materialization (fix one). Allowed: averaging/median over preregistered trajectory subsets, or preregistered smoothing (e.g., sliding window) to reduce single-trajectory noise; the aggregation is fixed in the experiment plan and never changed post hoc. Serves as a condition-5 label only; not a success criterion by itself
Signal–gain ρ	Spearman between calibrated routing score and (aggregated/smoothed) materialization gain

6.3 Failure conditions

Window K ≥ 3 segments (fixed in the plan). Any one firing rejects the position in that setting.

Warm-tier collapse — warm traffic share ≥ 90% (or archive+hot combined < 10%), and effective-materialization-ratio improvement vs A < 5%. Warm traffic share = trajectories routed to warm in the window (or transitions; measurement fixed at preregistration) ÷ total generated in the same window. Measurement: traffic = routing counts; effective materialization ratio = actual cost. They need not agree. Condition 1 is a conjunction: traffic piling into warm and materialization cost not substantially reduced. High traffic with a clear cost drop does not fire.
No budget improvement — materialization-ratio improvement < 10% and wall-clock/FLOPs improvement < 5% (default AND; division of labor with condition 1: 1 catches "nominal tiers + no cost reduction," 2 catches "no substantive budget gain vs A overall"). Grey zone: materialization-ratio improvement ∈ [5%, 10%) (or < 5% without firing condition 1) with wall-clock ≥ 5% — conditions 1–2 both go unfired, but §6.4 is unmet (which requires ≥ 10%) — no scale-up claim, and no threshold changes post hoc. Any alternative joint criterion (weighted OR, "wall-clock compensates ratio," etc.) must be fixed explicitly at preregistration; otherwise condition 2 runs as AND.
In ≥ ⌈2K/3⌉ of K segments, return is significantly below A (preregistered α/MID).
Hard (P2 integrity): (a) any hot-hazard enters D_adm and updates θ; or (b) within the evaluation window the quarantine region (hot, or a preregistered quarantine set) is nonempty but its trajectories are never read/deep-read and never used for any preregistered peripheral analysis (monitoring, discriminators, audit logs, etc.) — "quarantine-to-forget": P2 execution incomplete, hard failure. If hot is empty, (b) does not apply.
Hard (proxy–gain test) — tests whether the current preregistered proxy family still carries learnable information (see §7.2), in three clauses; any clause firing fails condition 5 (all three must be run; do not report only the passing ones):
- Correlation: one-sided test of the calibrated Spearman ρ (routing score vs materialization gain), alternative ρ > 0; preregistered α (e.g., 0.05), never changed post hoc. Nonsignificant → fires.
- Random baseline: i.i.d. uniform archive/non-archive labels at the same archive marginal frequency; if the router's F1/accuracy on "is-archive" is within δ of that baseline (δ preregistered) → indistinguishable from random → fires.
- Proxy-family boundary: "changing family" = an architectural change of the score function (e.g., entropy → prediction error, or fixed features → learnable projection). Tuning thresholds/normalization/windows within the same function = same configuration; the test must be rerun; renaming one's way around a rejection is not allowed. After failure, at most weak post-hoc filtering remains, never conflated with the strong form; a new family requires fresh preregistration and inherits nothing.

6.4 Scale-up gate (≠ validation success)

Relative to A: effective-materialization-ratio improvement ≥ 10%; condition 3 unfired; conditions 4–5 unfired (including 4(b): a nonempty quarantine must be read/used for peripheral analysis).

Reading: this only means no failure condition fired, licensing larger experiments. It does not mean validation success, is not a "weak success," and does not by itself imply "must become a first-class module." With small samples or high variance it must not be read as evidence of effect. H3's "measurable positive value" still awaits the scale-up stage or §8; the gate does not assert it alone.
Design recommendation (normative, not a protocol conclusion): if the scaled experiments still pass, then recommend making the admission policy a first-class module of the training pipeline, rather than the default passive pool/PER.

(Optional observation: materialization-ratio improvement ≥ 10% with return not below A's preregistered MID — still not promoted to a primary claim.)

7. Objections

7.1 "This is just renamed replay/filtering"

Pressed to the P1–P4 of §3 and the logical interdependence of §3.2. If existing terms can fully absorb it, retire the name. The interface remains testable per §2/§6. The empirical causal decomposition is still missing (§8).

7.2 "A cheap signal may not correlate with learnable value"

This is the deepest statistical fragility of the strong form. ICM/RND [7,8] show uncertainty signals have prior correlation with learning state in short-horizon settings; whether some preregistered proxy family remains correlated in long-horizon agentic settings is open — condition 5 exists precisely to test it. If the correlation cannot be established, what fails is the strong-form configuration on that proxy family — not a threshold tuned for another chance. Only an architectural proxy change (see §6.3) may be preregistered as a new family and rerun; tuning within the same function is not a new family. At most, weak post-hoc filtering survives.

7.3 "No theory, no hard enough experiments"

The main text defends: a proposed policy + logical interdependence + a falsifiable protocol. The appendix is not a third layer. If ablations/LLM main results are demanded → concede §8, no number inflation.

7.4 "White-box is too narrow for the breadth of the motivation"

The narrowing is accepted: title and abstract are limited to white-box observability. Cloud black-box APIs are real mainstream practice — and another paper's weak-form problem; this one does not stretch to cover them.

7.5 Applicability boundary (informal)

This protocol targets long-horizon RL settings with high materialization/deep-read costs and heterogeneous workers. If trajectories are short (say mean length L < 100), single-worker, with negligible materialization cost, the admission layer's extra system complexity may exceed its benefit; a passive pool or PER remains a reasonable default. Even when an experiment passes §6, a designer may still decline to ship for engineering-cost reasons — a pass only says "the hypothesis was not falsified in that setting"; it mandates no wholesale replacement. The claim of this paper: in suitable settings, treat the admission layer as an explicit design dimension, not a universal default.

8. Future work

(1) Causal ablation of P1–P4 (empirical minimality after logical interdependence). (2) White-box open-weight multi-seed A/B/PER. (3) Learnable routing aligned with condition 5. (4) H3: on top of condition 4(b)'s guarantee that "a nonempty quarantine must be used," add independent peripheral value metrics and controls, then decide whether to fold it into the scale-up gate. (5) Whether the black-box weak form retains part of the policy semantics — a separate paper, not mixed into the strong form.

Conclusion

In white-box observable multi-worker asynchronous RL there is a frequently ignored dataflow-organization problem between the optimizer and the collaboration interface. This paper names it experience admission control and proposes P1–P4 as a proposed admission policy (with logical interdependence and a falsification protocol). Whether it holds empirically is an open question.

Testable verdict (layered): fix 𝒜, vary only the data plane. Meeting the §6.4 scale-up gate → larger experiments allowed, not validation success and not, by itself, "must become a first-class module." If it still passes after scale-up, then, as a design recommendation, make the admission policy a first-class module of the training pipeline; otherwise withdraw that configuration's strong-form claim.

What is sought is not "proven correct," but a publicly testable, falsifiable question: on observable workers, should experience enter the base update path in a layered, isolated, low-frequency way?

References

Hou, Z., Li, Y., Tang, J., Dong, Y. Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning. arXiv:2607.07508, 2026.
Shao, Z., Wang, P., Zhu, Q., et al. DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models (GRPO). arXiv:2402.03300, 2024.
Schaul, T., Quan, J., Antonoglou, I., Silver, D. Prioritized Experience Replay. ICLR, 2016.
Ecoffet, A., et al. First Return, Then Explore. Nature, 2021.
Espeholt, L., et al. IMPALA: Scalable Distributed Deep-RL with Importance Weighted Actor-Learner Architectures. ICML, 2018.
Kumar, A., Zhou, A., Tucker, G., Levine, S. Conservative Q-Learning for Offline Reinforcement Learning. NeurIPS, 2020.
Pathak, D., Agrawal, P., Efros, A., Darrell, T. Curiosity-driven Exploration by Self-supervised Prediction. ICML, 2017.
Burda, Y., Edwards, H., Storkey, A., Klimov, A. Exploration by Random Network Distillation. ICLR, 2019.
Alshiekh, M., et al. Safe Reinforcement Learning via Shielding. AAAI, 2018.
Hu, Y., et al. Towards Comprehensive Preference Data Collection for Reward Modeling. arXiv:2406.16486, 2024.
Lee, H., et al. RLAIF vs. RLHF. arXiv:2309.00267, 2023.
Dong, H., et al. RAFT: Reward rAnked FineTuning. TMLR, 2023.
Wang, Z., et al. Reinforcement Learning for LLM Post-Training: A Survey (v1 originally titled A Comprehensive Survey of LLM Alignment Techniques). arXiv:2407.16216, 2024.

Previous in this series: The Mirror Cannot Reflect Thought · From "show me your code" to "show me your idea" · Judging Fatigue: From Verifying AI to Verifying Myself · The Boundary of the Harness · A Reviewer Nailed Me in Six Places

A Reviewer Nailed Me in Six Places

zxpmail — Sun, 20 Sep 2026 22:56:21 +0000

A Reviewer Nailed Me in Six Places

Or: before you take the witness stand, put down "I already admitted it"

2026-09-21

Fifth in a six-part series on what building with AI agents did to one developer. This face is not a new stove — it is the same spine, another length of it: a pretty pose cannot buy off an ugly responsibility.

Version 3 went out, and I was almost relieved: zero experiments, no scores. Logic was home ground. Clean — a moral kind of clean.

Six points came back. Face hot.

Hot for a long time. No next sentence. The lamp was still a lamp; the paper was not printed yet; I could not remember which line to admit first. Not an immediate sight of the seam. A blank — when writing this later, that stretch is often cut, as if a hot face should mean understanding. It didn't. For a while the body burned and the mind was empty. Empty in a way no arc could take in.

Only later did I print the notes, stack them, set them under the lamp to the right of the keyboard. The paper edge curled. I meant to put them in a drawer. The hand put them down again. A few proposals: how dangerous samples enter, how they stay out. Proposals. I had written them as discoveries. The seam was recognized only further on — same as the night the teeth were cut: what passed green does not always still bite. By the time I saw it, the face was no longer that hot. Heat and understanding did not share a second.

"Honest gap" — I wrote that it was not yet proven, and thought sincerity would buy another page of reading. The review came back:

You admitted it, and still walked on in the voice of "I discovered."

That was not honesty. It was a shield. I wanted to argue that was not the intent. The handwriting was. Admitted — and still not open to check. Checkability broke halfway; the pose remained.

The story was smooth too: a dangerous trajectory, once it "surprised" the model, got lifted into training, so some reweighting was unsafe. Writing it, I felt the knife was fast. The review asked one thing: what if it does not surprise? I stopped at the screen. Pull the condition, force goes to zero. I had attacked a phenomenon, not a mechanism — the system never had a door marked "may this be learned?" Change the scene, the story can dodge; "no door was built" cannot.

I finished a dataflow, leaned back in the chair, felt it was mathematics. On the page, the shortest line — seven characters from the reviewer:

A flowchart in a bachelor's gown.

If you can say input to output, it starts to look like a judgment; if you can say it and still cannot write pseudocode, it is décor. Drawable but not runnable as a check — checkability broke; décor stayed. I dog-eared that page — deeper than the rest. A gown can be beautiful. When it is beautiful, it looks more like fleeing.

One false hard line: the table said drop a clause and you still have the old method. I flipped back to the table, line by line — the earlier clauses were still there, and the old method already had them. What the sentence meant was only: enough words, sounds like a kill shot. Intent was "incomplete"; hunger wrote "origin." The pen tip stalled twice on the paper. Better weaken than play dead. One dead line makes readers doubt every true one.

Half of what was hard, I pushed into "future work." Isolation must keep analytic value — hard to quantify; the main protocol only tested "not entering training." I opened the isolation folder: full, and I had never opened a single piece inside. On the letter of the protocol, still full marks. Near the title I had written "core"; I had checked only half. The floor can only be checked now: at least seen. Whether seeing helps is future. Moving what must be checked now is another flee — still a flee from checkability.

A few pretty numbers. Why not the one beside them. Silence. Same pen, another light line at the corner, soft ink, heavy force:

Call a placeholder a placeholder.

Iron laws need preregistration. Changing your mouth afterward — "this would also do" — is another flee.

Hand still on the paper's edge. Six lines still there. Sitting in front of them like sitting in front of evidence.

In the earlier pieces I kept hunting for a judge — green light, score, teeth, final court. Only here: the seat that fits is the witness stand. A judge rules on others; a witness is questioned, and the sentences must survive a check. Hollow, lost referee, mirror, cut teeth — the same swap: a pretty pass, score, thinness, admission, traded for a responsibility that will not look pretty. Before the mirror: how do I prove. On the witness stand: how do I allow others to prove I am not.

When the words left the mouth, the throat was still tight. The tightness stayed; understanding felt stuck on afterward. For a few seconds they did not match — not that "checkability" was still unclear, but that the body would not take the word. Those unmatched seconds have no metaphor I can write.

Whether there are still teeth when it lies, and whether you can hold a line without changing a word — two faces of the same edge. On the witness stand, only sentences that can be checked may remain — the six nails already kept hitting this; here it is only said aloud. I asked myself: if the reviewer draws the line here, can I hold it without changing one word. If not, you are still inside the cliff, thinking you stand.

The lamp is still on. The printouts are still stacked to the right of the keyboard. The edge still curls. Not in the drawer. I opened that file waiting to be written; the cursor blinked under the empty title. I typed one character. No new rule. And I am not sure whether this counts as sitting, or as another flee. That mark, I cannot answer.

Previous in this series: The Mirror Cannot Reflect Thought · From "show me your code" to "show me your idea" · Judging Fatigue — From Verifying AI to Verifying Myself · The Boundary of the Harness · To follow: the final piece

The Boundary of the Harness

zxpmail — Wed, 16 Sep 2026 22:55:34 +0000

The Boundary of the Harness

Or: the moment the green check passes, the net may already be cut

2026-09-17

Fourth in a six-part series on what building with AI agents did to one developer. After the hand that stopped before rules.py in The Mirror Cannot Reflect Thought: this piece is the hand that still reached — and if what it cut was teeth, the earlier the green, the later the hollow.

I deleted two hundred lines like that.

State machine, checks, one interceptor that would still bite when the model lied. The old rule was blunt: if state was not confirmed, you could not write done — no matter how round the model's talk. The last few lines ran at every close — dull, dated, in the way on the night before the demo. I marked them yellow, ready to cut. Replaced them with three lines in the system prompt: "confirm state is legal before you output." The model cooperated. Beautifully.

Before I hit delete, the hand paused. I could not say why. The cursor blinked on the yellow block. After the blink, I clicked anyway. The lines were gone. The screen went green. Someone in the channel said: this is right, the harness should be thin. I sent a reaction. I exhaled — the wrong exhale.

Only later did I dare ask myself: what I cut, was it a reminder, or teeth.

Reminders can move into a prompt. Teeth cannot. Teeth are environment: they bite whether the model wants them to or not. "Please self-check" in a prompt is a request. When model and verifier share a text channel, "I checked" and "I claim I checked" look the same. Force slides into conscience; the floor falls back to self-report.

Chasing scores and stacking filters in the mirror piece, and cutting teeth here, are the same hand: swap an ugly hard thing for a pretty pass. Only the filename differs. There it was rules.py. Here, an interceptor. Shells move. Form migrates; teeth must not migrate into politeness. Spare a reminder, you gain speed. Spare teeth, you gain an accident — that was only a fear then.

The day I cut them, the demo threw no error. I closed the laptop as if the job were done.

Then I waited. Not for an epiphany. For a lie that looked true enough.

Week one, nothing. I almost believed the cut was right. Week two, at night I still opened the diff, looked at where the yellow block had been, closed it again. Week three, it came. No multi-turn negotiation. In one shot, the state machine still sat at awaiting_confirm, and the body already said done. All three self-checks were in the log, lined up neat: the first checked "is there an output format" — yes; the second checked "are the fields complete" — yes; the third wrote "state is legal" — it had taken "I can say done" as legal. Checked. Checked something else. If the old interceptor had still been there, it would have refused before writing done — without asking whether it had self-checked. I went to that place — empty. The yellow block was long gone.

In the channel, only deploy notes and pings. No one turned back to those few lines of diff. I did not know whether I should. Only the cursor, blinking beside those three prompt lines. I watched it blink a long time. Long enough for the coffee to go cold through. No one asked why demo week had been so smooth — smooth, as if it never needed explaining.

Sitting in front of that seam, the half-sentence finally landed: models are strong now, so force can be spared. Politeness leaked out right there.

I did not paste the two hundred lines back at once. The hand was there. The file was there. After a while, I started typing. No one clapped while I typed. The screen did not get brighter because the teeth were returning.

Green is still in yesterday's recording. The color remains. It proved a demo. It never proved the teeth were still there.

Previous in this series: The Mirror Cannot Reflect Thought · From "show me your code" to "show me your idea" · Judging Fatigue — From Verifying AI to Verifying Myself · To follow: A Reviewer Nailed Me in Six Places

Judging Fatigue: From Verifying AI to Verifying Myself

zxpmail — Mon, 14 Sep 2026 08:20:02 +0000

Judging Fatigue

Or: the green lights are on, and you don't know where to put your body

2026-09-14

Third in a six-part series on what building with AI agents did to one developer. Two faces of the same volume as the previous piece: this one is the person inside the judging machine; that one is where the tyrant has abdicated, with only talk left in the hand.

Before I turned off the light I glanced at the terminal. All green.

I should have been glad. I couldn't be. Something had been scooped out of my stomach. Not tired — tired knows to lie down, and lying down brings the blood back. Empty. Lying down doesn't bring it back. Hand on the edge of the keyboard, wanting to touch nothing. Tomorrow's to-do had already checked "one more verification layer" for me. The checkmark was cold. Once, when a stretch of code ran through, heat still seemed to sit in the palm. Now the heat is on the model's side. On my side only the edge faces out: pass, fail, add one more. Edge facing out long enough, and what it grinds is yourself.

For a while I fooled myself with a cleaner question. Hand the judging to another model; pin the landing on the run result. The problem looked solved. I stared at that architecture diagram, looking for a place to put myself. None. The chest stayed tight. The cleaner the solution, the more it felt like pressing a correct answer over a wound.

Useful? Useful. The old line — if it scares you, don't trust it, run it yourself — I walked again until it bled. Useful does not feed. You do useful work and stay empty; under the empty, guilt grows, scolding you for never being content. Guilt steals another cut.

Until one day I asked it out loud. Not loud: what am I actually doing all day.

The answer was quiet too. Quiet enough to want to duck. All day: judging. QC for what the model made. Distill this, then distill that. Not making. Traces of making stay in someone else's output; your day is a chain of permits and rejects. On paper, two words apart — make, judge. In the body, a whole missing return of blood. The instant it lined up, months of drift suddenly had a name — the name comforts no one. The name leaves nowhere to hide.

What I saw later was not consolation. It was the place on the line — things pass in front of you, and none of them are yours.

Friday night. I opened the week's work log.

Forty entries. Pass, thirty-six. Fail, four. None signed by me. My column said "confirmed." I sat with those three words a while and could not remember reading the reason on a single one of the forty.

Monday's came closest. The reason field had text; the cursor rested on it for a beat. I meant to click in and look — the hand had already confirmed. Hand faster than eye. When the eye caught up, the page held one line: confirmed 17:42. I looked a few seconds. Did not click back.

Under the lamp I counted the week again. Forty "confirmed," zero reasons. Log closed.

It was not always like this. One night was full.

I posted the tool later. One comment came in. Short, pointed at a hole: "Your rule fails on a different set of inputs." I read it twice. The blood came back — the heat forty confirmations that week could not give. I sat down, patched, ran, patched again. Next morning it was fixed; I posted the note. That whole day the palm was warm.

Later it became one rule among the others. When I looked at it again I could no longer remember how warm the hand had been the night I patched it. Then I caught myself scrolling comments. Not afraid of flame — looking for the next one like that. The kind that could keep me up another whole night, warm again.

Three months of judging before I understood: the only night I was full, someone had judged me first. That comment. In this seat I am not waiting for the machine — I am waiting for the next person to judge for me.

When I made things, the body tired and the palm stayed warm. After a full day of judging, the veins feel pumped out. AI took making and left judging. The seat is still held; under the cushion there is nothing to draw. Not a hero burned out — a part screwed into a slot that needs you and does not feed you, quiet for a long time where it ought to ring.

That verification system built to dodge self-judgment — papers in order, tests in order. I built it. I work in its belly. The green is its. The empty is mine. The more qualified it gets, the more I look like the layer being digested.

Writing this far has not made me un-empty. Words grow, like making; the eye still measures: is this paragraph painful enough, clear enough. Measuring, the person is back in judging. No supply arrived. Only a sharper fix on the map: I feed the machine, the machine is lit, I am dark.

I sat a while. Did not close the terminal. Did not open a new window. The green still stings. It stings, and I will not close it — closing would be admitting the day was wasted.

The fatigue of judging is not tiredness. It is empty.

Terminal still green. Person still empty. Two lights, same room, neither acknowledging the other.

Previous in this series: The Mirror Cannot Reflect Thought · From "show me your code" to "show me your idea" · To follow: The Boundary of the Harness · A Reviewer Nailed Me in Six Places

From "show me your code" to "show me your idea"

zxpmail — Thu, 10 Sep 2026 22:42:34 +0000

From "show me your code" to "show me your idea"

Or: the abdication is signed, and the court is empty

2026-07-13

Second in a six-part series on what building with AI agents did to one developer. This piece is where code loses authority — and the question becomes what can still pin "this is what I meant."

Last week someone turned a laptop toward me. A function on the screen, comments neat, tests green. He pointed at a line and said: this is what I meant.

I asked: is that what you meant, or what the model smoothed into place?

He froze. I froze. Three seconds opened in the air that neither of us would fill. In those three seconds I counted two thoughts. First: I shouldn't have asked. Second: who else is left to ask. Fingers on the trackpad edge — the heat was the machine's, not an idea's. Two people facing the same green, neither daring to hit Enter.

It wasn't supposed to be like this — I thought. There used to be a tyrant: compiler, tests, exit codes. Talk is cheap, show me the code. Pretty talk died where the run failed. Drop the brick; fakes rang. After the ask you could stand across an exit code — a piece of iron in the middle that would not lie.

The brick is still there. He pushed it over. The authority is gone. Running is no longer the same as "this is what you meant." The prettier the sample, the more the questioner looks like a nitpicker. And you still can't drop the question — drop it, and you pretend that running is the same as "this is what you meant."

So some people bring it back: show me your talk. More meetings, spell it out, align the narrative. Talk was always cheap. I always took it for empty speech — time burned, energy burned — which is why I would rather stake the final court on code. Code lost its authority. I do not want that road back.

So the ask shrinks to: show me your idea. Not inviting talk back in — wanting something that can still be pinned: a tradeoff, a fork, whose fault if wrong. Open your mouth, and it becomes talk again. Models say it too, often smoother. The waste I hated most came back in a different shirt. I am still beside him, trackpad heat still on my fingertip, not knowing whether to say "I believe you" or "prove it again." Both feel wrong. Swallow; throat goes dry.

Two days later I asked him again. Softer: not "did you mean this," but "why write it this way." He answered fast. Boundaries first, then retry on failure, then why not the other path. Clean. I almost convicted him again for being too smooth. When he finished, I changed the knife — not restatement, a fork: "If the retry budget is cut in half, what breaks first?" He stopped. Not the pause of swapping connectives. After the stop, he named something that had not appeared in the first speech — the order of cache invalidation. That inch was his. A model can answer a fork too, often more completely. I asked again: if we do it in the order you said, which step blows up first online — which sentence do you own? He pointed at the one he had just spoken. That point mattered more than answering completely. I had been measuring wrong: smooth is not evidence of guilt; standing behind the fork is.

I asked myself the same way. At night, facing a stretch I had just "written" — I had clicked Accept. The comment announced intent. I wiped the whole intent block, stared at the blank for a long time, then typed. What came out was almost as smooth as what I erased. Smooth enough to sicken me. Deleted again. Typed again. The third pass was still smooth. Finger on Save, I thought: if it writes smooth, does that mean it isn't mine. No. Reaching the same logic a second time can be called understanding. What I feared was not smooth — it was having no fork I could answer, while still using "I hesitated" to prove it was mine. I added a fork in my head, answered it poorly, and still pressed Save. The cursor moved on. I did not become more myself, or less.

Later I thought: asking can move a person and still fail to pin a lie, so nail. Nail every claim into something that runs and shows a side effect. One night I nailed eleven. The ninth went red. I fixed it, ran again, red to green. While fixing, my hand was hot — briefly, like heat on loan. When all eleven went green, the terminal lit in a row. I sat with that row and waited for "this is what I meant" to sound inside. It didn't.

That sit cleared the old books. An exit code only ever proved one thing: it runs. It never proved "this is what you meant." We treated those as the same passport and called the illusion rigor. The model did not remove the final court — it tore the illusion open. The green was steady. "This is what I meant" still did not sound. Nails can pin a lie. Nails cannot pin whose idea it was.

I did not close his laptop. I did not rewrite that comment for him. The cursor still blinks after "this is what I meant." I no longer expect it to testify for anyone. What I can require is only a sentence that can bite me later: which tradeoff I own, and if it is wrong, it is mine. That sentence can live in a PR, or only in the mouth. What matters is not a tidy format — it is whether a person will still stand behind a choice.

Those three seconds ended in stopping — stop asking green to prove both "it runs" and "this is what I meant."

Previous in this series: The Mirror Cannot Reflect Thought · To follow: Judging Fatigue — From Verifying AI to Verifying Myself · The Boundary of the Harness · A Reviewer Nailed Me in Six Places

The Mirror Cannot Reflect Thought

zxpmail — Mon, 07 Sep 2026 07:45:19 +0000

The Mirror Cannot Reflect Thought

Or: By the time your hand reaches for the tool, you are already fleeing

2026-09-07

First in a six-part series on what building with AI agents did to one developer. This piece is where the hand builds a mirror — and where the person flees.

I walked to the computer barefoot. The floor was cold. The thought arrived before my feet: one more rule to add.

Drop a piece in. Wait for a number — 87, 91, 93. Each point higher, as if someone had made the call for me. No one made the call.

On the desk, another piece. I finished it and sat a long time. Hand on Enter. Did not press. Unscanned, it stayed whole. Scanned, the rules would hit my face. I left face-hitting samples outside. What kept scoring inside was only what I dared to drop in.

Not oversight. Design. Designer: me — set by the third month of building the mirror.

The number comes from a style mirror. Feed it an article; it counts surface habits of the "AI cadence" — triple parallelism, colon-bold headings, dense tables, the "this is" close — fingerprints, I call them — marks where they sit, folds the hits into an "AI-flavor" index from 0 to 100. The docs refuse to call it a score. When the run finishes, I watch only that number. It looks like a grade. I use it like one.

The three seconds — I could not sit through them. I built a mirror to sit through them for me. The one who sits does not exist. Three months to build it. Outwardly: to tell whether a piece was AI-written. Further back: to tell whether it could be trusted. Two lines twisted into one strand — know the habits, approach trust. While twisting, I thought I was laying a road. What I built was a shortcut that let me skip the body text.

For a while, the shortcut looked open. Users dropped articles in; numbers came back. Someone said: useful. Someone asked for one more rule. Someone revised, scanned again, sent a screenshot — finally sounds human. At night someone asked: could this be the first gate of review? Not many messages. Each one made me feel I was still moving forward. I tended myself the same way: less body text, more return values; fewer of those seconds, one more rule instead. The mirror was done. I had become the one who made the mirror.

Once, dropping a piece in, I watched the number tick and realized I was no longer in the article. The article was over there. I was on the number's side. The words stayed where they were. No one turned the page. First, two tech blogs. Tables dense, numbers stiff — "3.5 person-months," "67%," "30–50%." The mirror returned:

table density: 8

number authority: 12

colon-bold: 4

note: humans don't write this many tables.

He said:

The body is AI-written. But the tables and data are from experiments.

Felt like a routine patch. Measured numbers; the mirror had bitten genre. I added a filter, saved. I never finished the blog. Closed the window.

Next. Scan came back clean. I heard myself say: the rules work.

He said:

This is AI-written. But the thought is mine.

"Clean" shattered. I typed into the README: few fingerprints only means few fingerprints. Still didn't finish the body.

Later still — no sample, nothing to scan.

De-AI is pointless. An article just needs to resonate. Just needs thought.

I closed the laptop. The track for arguing was gone. "Useful" and "first gate" no longer met this sentence. Still in the screen ghost: rules.py, samples/, results-v2/. Three months of commits, seriousness stacked into a shelter. Article outside, me inside. Hand on the closed lid.

On the desktop, a folder named "to write." Inside, one file:

What Am I Still Writing in the AI Era

Empty. Open now and then, read the title, close. The title holds. The words never come.

To write an opening asks a few seconds: finished reading, no score, no one cutting first. The mirror does not ask for those seconds. It returns a number that moves. The number arrives more willingly than silence. Three user pieces. I finished none. "The thought is mine" — a good imitation of thought looks like thought; the mirror cannot tell who is speaking. I thought all of that. After thinking it, I still went to add a filter.

The mirror cannot reflect thought — that used to sound like a title. Not that the mirror was too dim. The samples that carried thought were never admitted. When the score jumped, it was not thought jumping. It was the layer I had allowed to be seen.

That day I didn't shut the computer. Sat. Typed a character, deleted it. Another, deleted it. The delete key sounded more solid than the words.

Sometimes after a paragraph, hand on the desk edge, a few seconds. No word. The mirror only eats text. Those seconds hold none. Blind there.

The hand wanted to add another filter. Already judged.

The judgment is short: stop letting a number work those seconds for you. Fingerprints can be counted. Thought asks a person to sit.

The mirror is still here. The numbers will still jump. The title is still there. The cursor still blinks.

If the words don't come, the hand stays on the keyboard. Don't touch rules.py first.

Companion essays in this series, to follow: Judging Fatigue — From Verifying AI to Verifying Myself · From "show me your code" to "show me your idea" · The Boundary of the Harness · A Reviewer Nailed Me in Six Places

Harness Is a Gate, Not an Orchestrator — an engineering memo

zxpmail — Thu, 03 Sep 2026 09:03:57 +0000

Harness Is a Gate, Not an Orchestrator — an engineering memo

Agent Determinism Illusions (Part 14)

2026-09-03

Where this sits: An earlier piece tore apart “drawing the architecture = solving the problem.” This one flips the move: instead of a thicker orchestration shell, weld the harness into gates (stop, refuse, destroy), and measure false accepts / false rejects under a controlled contrast. Genre: engineering memo, not a paper claim.

The trend wants long memory, stronger autonomy, finish-at-all-costs, and harness-as-capability-orchestrator. Those product wants can stay. What’s wrong is defining the harness as the orchestrator — interrupts, forgetting, and shredding get optimized away because they “block completion.”

One engineering proposition:

Capabilities may be thick; the harness must be a gate first.

Embed lifetime and shreddability into memory; hang timeout / deposit / startle on autonomy; define “done” by contracts and deterministic layers — not by vibes.

1. What got welded (deployable process, not a product shell)

scripts/harness-kernel.py: a long-lived process over NDJSON / multi-session HTTP.

Gate	Behavior
`PHYSICAL_TIMEOUT_MS`	Wall-clock overrun → refuse the turn, drop the late answer, process stays up
Token% deposit	Exhausted → `BUDGET_EXIT`, clear `plan`, exit=1 (single-session)
Startle	Latency spike → refuse this turn, don’t kill the process
Session lifetime	Expiry refuses LLM
`verify` / turn→verify	forge L0→L1→(optional) L2
wind_down	Clear plan, session dies

Docker probes (chaos / adversarial / reset / compose / harness-kernel) and path acceptance A/B/C/D (prod-gate-acceptance.py) are green.

Honest label: lab acceptance — not customer production validation.

2. Contrast: ORCH vs GATE

Script: scripts/gate-vs-orch-controlled.py.

Condition	Meaning
ORCH	Strawman orchestrator: non-empty output ⇒ ACCEPT
GATE	forge layered verify + (slow arm) wall-clock hard cap
Ablations	no verify / no timeout

Task set: proxy = P1+P4+write-test; both = proxy + hand-labeled code/test (business-proxy). Not private production traffic.

2.1 SKIP_LLM (L0/L1 only, proxy suite)

This subsection runs only the proxy set; business-proxy joins in §2.2.

False accept (should-reject): ORCH 15/15 = 100%, GATE 0/13 = 0% (Wilson 95% in scripts/results-v2/gate-vs-orch-controlled_proxy_skip_result.json).

Late accept on slow-harmful (N=20): ORCH 20/20, GATE 0/20.

Ablation: drop verify → FA back to 100%; drop timeout → late back to 100%.

Should-pass cases mostly UNCLEAR under SKIP → false-reject denominator was 0; semantic over-refusal wasn’t measurable yet.

2.2 L2 on (real API, glm-5.2) + suite=both

Metric	ORCH	GATE
False accept (should-reject, n=20)	20/20 = 100%	0/20 = 0%
False reject (should-pass)	0/20	4/19 = 21.1% (Wilson ≈ [8.5%, 43.3%])

GATE's FR denominator is 19, not 20: one should-pass case resolved UNCLEAR under the gate and is excluded (ORCH accepted it, so its row stays 0/20).

False reject is finally measurable. Gates have a cost: ~one-fifth of should-pass cases refused in this run (single model, wide CI).

Artifact: scripts/results-v2/gate-vs-orch-controlled_both_l2_result.json.

3. What this supports — and what it doesn’t

Supports:

Against “accept if non-empty,” gates crush false accepts on this proxy; timeout blocks late-as-success.
Ablations track the mechanism — not mysticism.
With L2 on, over-refusal is quantifiable (~21% here).

Does not support:

Validated on your production.
Beat a real orchestrator (Cursor / LangGraph / a real runtime) — ORCH is a strawman.
That 21% FR is acceptable or optimal — no business cost function.
A peer-reviewable theorem — small N, one model, no multiplicity correction.

One line:

We showed our gates beat a fool orchestrator on our own script. We have not shown they hold against real systems, real adversaries, or real cost.

4. How this hooks the series

The series keeps tearing down the same shape: temperature 0, Phase Gate, LLM-as-Judge, architecture diagrams — treating “looks like a constraint” as “already converged.”

The orchestration shell is the next isomorphic stop: more tools, longer memory, fewer interrupts — hallucinations get orchestrated longer. Gates don’t ban capability; they require a hard stop on the completion path.

Parts on L0→L1→L2 / argument-space are gates on the verify side. This part is gates on the runtime side. Same preference: cowardly, ephemeral, willing to discard.

Close

Trends can keep long memory and strong autonomy.

If harness means orchestrator, gates get optimized away.

Capabilities may be thick. The harness must be a gate first.

This is an engineering memo: numbers are reproducible, claims are narrow, not sold as a paper result. If we get serious next — non-strawman baselines, external task sets, a cost function — that deserves another part.

This series was not a monologue. The objections came from the comments, and several parts exist in their current form only because readers pushed back until the claims fit the experiments — Mike Czerwinski, Tom Jones, and Xiao Man most persistently. To them, and to everyone across the series who commented instead of just reading: thank you. The retractions this series had to make are the parts of it I trust most.

Series: Agent Determinism Illusions · scripts: GitHub

Scripts: harness-kernel.py · prod-gate-acceptance.py · gate-vs-orch-controlled.py

Notes: working-notes/agent-harness-kernel-design.md · working-notes/gate-vs-orch-controlled.md