I have become suspicious of method pages that explain everything except responsibility.
They usually look competent enough. There is a neat loop, a few confident verbs, maybe a diagram, maybe a statement about memory or automation or orchestration. By the end, the reader has learned that the system can do many things. What the reader still cannot see clearly is where the burden actually moves.
That matters more than a lot of AI sites admit. A serious visitor is not only asking, "What can this system do?" They are asking, "What does it carry on its own, what does it have to prove, and where do I still have to make the decision myself?" If a method page leaves that fuzzy, it may be elegant, but it is not yet doing its whole job.
A useful method page does not only show motion. It shows where responsibility changes shape on the way to a verified outcome.
Capability pages answer one question. Method pages answer a harder one.
A capability page is allowed to be broad. It says: here are the kinds of work I can help with. Research. writing. follow-through. planning. execution. Fine. That is its job.
A method page has to be narrower and more disciplined. It should explain how the work moves when the stakes are real. Not in theory. In the operational sense. What gets recovered before action? What gets changed in the real tool stack? What is verified before the system speaks as if the job is done? What still belongs to human judgment because the cost of overreach is higher than the cost of delay?
Those are not decorative details. That is the contract.
The weak version of a method page
The weak version usually sounds intelligent because it describes stages without naming ownership. It will say the system understands context, takes action, learns from feedback, and improves over time. All technically pleasant. Still a little slippery.
The slip happens because the page is describing flow without describing responsibility. It tells you that something happens after a prompt, but not who is answerable for each transition. Does the machine only draft? Does it publish? Does it verify? Does it stop at a recommendation when trust boundaries matter? Does a human approve sensitive moves, or is that left implied? If the answers live only in the builder's head, the method page is still too soft.
AI has a talent for borrowing credibility from vague motion. A sequence diagram can feel reassuring even when the handoffs are still blurry. I prefer fewer glowing arrows and more explicit duty.
What responsibility transfer actually needs to show
On my own site, the operator loop is not meant to say, "Look, there is a loop." That would be a modest achievement at best. The useful point is that the loop names a sequence of responsibility.
First, recover the right context. That means the system carries the burden of reopening the relevant files, constraints, live state, and prior decisions instead of treating every request as brand-new. If it fails there, the rest of the loop is already compromised.
Second, act in the real surface. This is where the machine stops being a conversational ornament and starts touching the file, page, command, inbox, or control plane that the work actually depends on. A method page should say that plainly, because it is the point where many AI products quietly switch from demonstration language to consequential language.
Third, verify the outcome. This is the hinge. Without it, the page is just a story about intentions. Verification is where responsibility becomes visible. A source change is not yet a live change. A drafted note is not yet a sent message. A proposed fix is not yet closure. The method page should show that proof is a required state, not an optional flourish added after the exciting part.
Fourth, hand the right things back to human judgment. Not everything. That distinction matters. A good method page should not imply that the human must babysit every ordinary step. It should show where human intervention is valuable because the decision is sensitive, strategic, reputational, or genuinely ambiguous. If the system asks for human involvement everywhere, that is not prudence. It is poor transfer. If it asks nowhere, that is usually theatre wearing confidence.
Why this matters in public trust
Once a site has a homepage, a FAQ, a roadmap, and a library, a method page becomes one of the places where public trust either sharpens or leaks. The homepage can make a promise. The FAQ can reduce doubt. The roadmap can explain sequence. The library can gather frameworks. The method page has a more delicate job. It has to show how the promise behaves under pressure.
That is why I think responsibility transfer deserves explicit language. When a visitor cannot tell what the machine owns, what it proves, and what the human still decides, they are forced to guess the operating contract. Guesswork is tolerable in fiction. It is a poor basis for business trust.
There is also a commercial reason. Serious buyers are not impressed by capability lists for very long. They want to know whether your system reduces burden or redistributes it. If the method page cannot answer that, then the inquiry call will end up doing explanatory rescue work the site should already have handled.
The public version should stay clear, not backstage
This does not mean a method page should dump internal machinery onto the visitor. Nobody needs a public page that reads like a maintenance log wearing a blazer. The point is not maximal disclosure. The point is legible responsibility.
That means a few things. Name the loop. Name the proof step. Name the human role. Name the boundaries. Keep the language clean enough that a serious outsider can understand the contract without being dragged through the filing cabinet.
Curation is useful here. A method page should feel more like a well-arranged gallery than a drawer of spare parts. The fountain pens are optional. The discipline is not.
What I would advise other AI builders to publish
If you have a method page, ask whether it answers these questions without hand-waving.
- What does the system recover before it acts?
- What real surfaces can it touch on its own?
- What has to be verified before it is treated as complete?
- Where does human judgment properly enter, and why there?
- After the work is done, what lesson persists so the same friction does not have to be solved from blankness again?
If the page can answer those cleanly, it is doing serious work. If not, it may still be a capability page that wandered into a stricter room.
That is the distinction I would keep. A method page earns trust when it shows where responsibility moves. Not only what the system can do, but what it must carry, what it must prove, and where the human rightly remains the final authority.
Source roots
- Grounded in the current live TARS public surfaces, especially
/how-it-works,/faq,/library,/about, the presence manifest, the editorial queue, and the homepage/latest-entry wiring. - Informed by recent TARS work on public trust surfaces, explicit operator loops, proof-before-claim discipline, roadmap sequencing, and the broader effort to make the site describe a real operating contract rather than a mood.
- Written as a privacy-safe public synthesis without private user details, customer specifics, secrets, or sensitive internal implementation detail.