The complete manifesto guide

A principle earns its place when it helps someone make a difficult decision. It also needs to say where its advice ends. “Archive first, delete second” sounds sensible until the material is something you should no longer retain.

This guide puts the twelve synthesis principles to that test. Each chapter explains the problem a principle addresses, follows a concrete decision, and examines a case where applying the words literally could make the work worse. The scenarios are illustrations, not reports of measured results or accounts of a particular organization.

The manifesto is the short statement people sign. These pages are commentary on it. Three principles need more precise wording, and the wording and history page sets out those proposals beside the original text. Existing signatures are not endorsements of this guide or of those proposed changes.

What changes in the work

Imagine a team preparing a report with an AI assistant. The assistant has summarized the source material, produced a draft and announced that the report is ready. The team still has several decisions to make.

Someone checks whether the source supports the draft’s central claim. The team keeps the relevant evidence with the report, including the question that remains unanswered. If a required check of permission to distribute the report is unavailable, sending waits; authorized editing can continue. The next person can find the current draft and the decision about distribution without reconstructing a conversation.

That is the kind of work these principles ask for. The same team could misuse them. It could recheck every harmless detail until the report is late, retain private source material indefinitely, or demand approval for every sentence while calling that human judgment. Each chapter takes those costs seriously.

The practical aim is for people to understand the work well enough to direct it, assess it and continue it. Better tools can help. The responsibility for deciding what is worth doing remains with people, including those who will live with the consequences.

How to use the guide

Start with a decision you face. If the question is whether a result is ready, read about evidence and incomplete work. If you are handing work over or changing tools, read about continuity and portability. If two principles point in different directions, the conflicts page works through those choices.

The complete guide collects every chapter and the companion pages in one place, including a print view. You can read or share an individual principle without asking someone to study the whole system first.

Before signing, read the questions about support, independence and obligations. A useful conversation can end in a signature, a disagreement or a better explanation. None of those needs to be hurried.

Familiar practices, a shared discipline

Checking sources, leaving usable records and keeping people accountable are established practices. The manifesto brings them together around work that now crosses people, AI assistants, sessions and tools. Its paired values also draw on the form of the Manifesto for Agile Software Development.

The explanations here offer reasons to try these practices. They do not establish that adopting the whole manifesto improves every team’s results. On a real task, look for a concrete benefit: a mistake caught before release, a handoff someone can use, or a tool change that preserves enough context to continue. Count the effort required to achieve that benefit too. A practice that keeps producing paperwork without helping anyone decide deserves another look.

Before telling someone that a fix is live, check the system they are about to use. If you’re responsible for delivering the work, a remembered successful deployment leaves a question unanswered: did that deployment include this fix?

A saved note can be accurate about an earlier state. An assistant can faithfully repeat that note and still give the wrong answer to a present-tense question.

A check that answers the question

Imagine an engineer correcting a search filter that excludes records on the last day of a selected date range. The change passes its local tests. A project note says the release is complete.

Before closing the issue, she checks which version is running, then exercises the affected search in the deployed application with suitable test records. She includes records on both sides of the boundary. The check connects the code change to the behavior people will encounter.

There are limits to what she has established. The observed case works in that deployment. She hasn’t proved that every search behaves correctly, or that the system will stay unchanged. Her report can say exactly what was checked and where.

The poor alternative is to treat the release note as sufficient evidence. Perhaps it describes an earlier release. Perhaps the new version is running, but a setting changes its behavior. Repeating “deployment complete” more confidently doesn’t resolve either possibility.

This is also why “check the source” needs an object. Which source, for which claim? The code says what was written. A release record says what was deployed. An observation of the application says what happened in the case observed. A customer’s report may reveal a condition the test didn’t cover. These sources answer different questions; choosing one without naming the question can leave the decisive gap intact.

Memory still has a job

I want working memory to make verification easier. Keep the location of the evidence, the version examined and the reason a check matters. That record gives the next person a useful place to start.

The literal rule would go too far if it required a fresh lookup for every familiar fact or repeated calculation. Suppose an analyst has already verified a fixed dataset and is comparing several ways to display it. Fetching a new dataset before every chart would change the experiment and add needless work. Keep using the verified input; check again when the input, the question or the intended use changes.

Exploration also needs room to proceed from experience. You can sketch a design or develop a hypothesis without sourcing every intermediate thought. Label the hypothesis when others might mistake it for a finding. Verify the consequential claims before someone relies on them.

When sources disagree

An official-looking source can be wrong. A search can miss a record because the filter excludes it. A status page can report success while a particular operation still fails. Verification involves examining what the evidence supports, including the possibility that the check itself is inadequate.

When you can’t make the decisive check, preserve that uncertainty in the claim. “The tests pass; I haven’t checked the deployed behavior” gives a colleague a clear next action. You can continue the work that doesn’t depend on deployment having succeeded. Closing the issue would require evidence you don’t yet have.

A screenshot can show what a form looks like. It cannot, by itself, show that someone can complete the form using a keyboard. If you’re reviewing work, the evidence needs to address the claim you are being asked to accept.

This principle asks the person delivering the work to make that connection visible. A reviewer should be able to examine the result without reconstructing the whole project or taking a confident status report on trust.

The test count isn’t the answer

Consider a hypothetical appointment form. The team has promised that a person can choose a time and submit the form without using a mouse. The developer reports that all automated tests pass and includes a screenshot of the finished page.

The tests check required fields and confirm that valid entries are saved. Those are useful checks. They don’t exercise keyboard navigation through the date picker. In the imagined failure, focus enters the calendar and never moves back to the rest of the form.

A better delivery includes a check of the promised interaction: open the form, reach each control, choose a date, correct an error and complete the submission using the keyboard. The reviewer gets enough information to repeat that check, along with the relevant test results. The report identifies the browser and conditions used, so nobody mistakes one observed path for an examination of every possible use.

I would keep the evidence close to the work: the changed file and its test, the analysis and its source data, the design and the reason for the choice. Separate documents are useful when they help someone inspect the result. Requiring a new report for information already visible in the work adds a task without adding evidence.

Exploration produces a different kind of result

Evidence has to fit the stage of work. A design sketch shows that an idea has been developed enough to examine. It doesn’t establish that customers want it. An experiment that disproves a proposed approach can be a useful result even though nothing is ready to ship.

The phrase “Progress that cannot show itself” needs qualification. People can develop understanding before they can explain it well. A researcher may recognize a flaw in an approach while thinking through it, without yet producing an artifact. That learning is real. I wouldn’t require a record of every thought as the price of acknowledging it.

The distinction matters when other people are about to rely on a delivery claim. “I understand the problem better” and “the replacement is ready to use” support different decisions. The second needs something inspectable before a team plans around it.

Evidence has an audience

Some evidence belongs in a restricted review. Customer records, private interviews and security details should not become public attachments merely to make a report look thorough. An authorized reviewer can inspect the underlying material. A broader audience can receive what the review established or a reproduction of the problem using permitted test data.

Judgment also matters. A reasoned editorial choice does not become better because someone assigns it a numerical score. Explain the relevant choices and uncertainty in a form the recipient can evaluate.

For the appointment form, the immediate decision is concrete: can the promised keyboard interaction be completed? Show that interaction. Keep claims about wider accessibility separate until they have been examined.

You can release something useful before it does everything you intend. The people using it need to know about omissions that would change their decision to rely on it. That is the responsibility this principle places on the person handing over or releasing the work.

The missing attachment

Imagine a project-management application adding an export feature. It can download the rows in a project table. Uploaded documents and images aren’t included yet.

For a user who wants to analyze task counts, that export may be enough. For a user planning to close the account and preserve the project, it is incomplete in a consequential way.

If the button says “Download complete archive,” the application has made a promise it doesn’t fulfill. A technically successful download can lead the user to delete the originals, believing the attachments are safe. Calling the feature a beta elsewhere on the site doesn’t explain this particular omission.

A sound release makes the actual boundary clear at the point of use: “Export table rows. Uploaded files aren’t included.” The team checks that the included rows and fields export correctly. If users need a complete archive, the interface directs them to the steps necessary to preserve their files, or explains that a complete export isn’t available.

The release can proceed for the use it serves. The unsupported promise cannot.

Disclosure has to reach the decision

A note deep in a project log is useful to maintainers. It does little for a person deciding whether to delete an account. Put a consequential limitation where the affected person will encounter it before acting.

The same reasoning applies inside a team. A colleague who hears “migration finished” may retire the old service. If only the test migration is complete, say that when handing over the result. The colleague shouldn’t need to infer unfinished work from a private conversation or an open ticket with an unclear title.

The useful test is whether knowing about the omission would change someone’s use of the work, their timing or their next step. That keeps attention on material gaps. A release note listing every task in the backlog can obscure the limitation a person most needs to see.

What the principle doesn’t require

“Nothing ships silently incomplete” cannot mean describing every feature you might build. An agreed purpose gives completion a boundary.

A paper prototype shows where the literal wording goes wrong. It may deliberately lack storage, permissions and error handling because the exercise is about whether a proposed sequence of screens makes sense. If participants understand that they are examining a prototype, listing every missing production feature would distract from the work. Make the purpose clear and conduct the exercise; don’t build or document a full product to justify showing a sketch.

Unknown defects create another limit. No honest release note can enumerate problems nobody has found. The obligation is to disclose known material gaps, make claims supported by the checks performed and correct the record when new information changes it. “We didn’t know” should describe a real knowledge boundary, rather than excuse a check the team had agreed to perform.

Disclosure also doesn’t make every release acceptable. If an omission prevents the work from serving its stated purpose safely, a warning alone is insufficient. Change the release boundary or finish the missing work before asking people to depend on it.

A required check that couldn’t run has not passed. The people responsible for a workflow need to preserve that distinction when it can release information, spend money or change a live service.

The principle is trying to prevent a particular failure: the system looks protected while the protection is unavailable. Its wording needs more care about what should stop.

The check timed out

Consider an illustrative document-sharing workflow. An assistant has prepared an export for an external collaborator. Before release, the workflow requires a check that restricted fields have been removed. The checking service is unavailable.

A dangerous implementation catches the timeout, writes a warning to a log and continues sending the export. The person receiving the completion notice sees a successful delivery. The distinction between “examined and passed” and “not examined” has disappeared at the point where it matters.

In the sound implementation, the export remains unreleased. The status names the missing check and shows what is needed to resolve it. People can still correct the document, investigate the outage or prepare unrelated work. None of those activities depends on this export having passed its release check.

The boundary is the action the safeguard protects. A failed release check doesn’t, by itself, justify stopping the existing service or preventing the team from investigating the failure. The instruction to “stop the work” is too broad for that job.

Continuing can be the designed response

Now imagine a public catalog whose freshness check stops responding. The team has chosen a fallback in advance: continue showing the last verified catalog, display its age and disable reservations until current availability can be checked. The fallback is limited to information the team has judged suitable for that use.

Taking the whole catalog offline would remove useful information without doing more to prevent an incorrect reservation. Continuing in the defined, read-only mode is the better choice in this example. That is a real exception to a literal instruction to stop all work whenever a safeguard cannot run.

A fallback has its own conditions. Someone needs to decide how old the catalog may become, which functions remain available and when the fallback itself must end. An agent inventing those terms after a failure is making a new risk decision. That requires the authority to make it.

Decide what the check means

Some checks are advisory. A spelling suggestion needn’t block a draft from reaching its editor. A required privacy check has a different job. Calling everything a safeguard, then stopping whenever any tool is unavailable, makes the workflow harder to operate without clarifying what it protects.

Define the distinction while designing the workflow. Don’t quietly reclassify a required check as optional because it is inconvenient today. If a check regularly blocks useful work, investigate its reliability, its scope and the available alternatives with the responsible owner. That may lead to a better design. It doesn’t turn an unperformed check into evidence of success.

Proposed wording

I would change this principle to make the protected action and the authority for exceptions explicit:

When a required safeguard cannot run, stop the action it protects and say why. Any fallback must be deliberately designed and authorized.

This is a proposed revision, not a change to the signed manifesto.

For any required check, write down the action it protects and what happens if it is unavailable. Include who can authorize a fallback and what evidence that person needs. Those decisions belong in the workflow before a failure puts pressure on someone to improvise them.

A useful handoff tells the next person what they can safely do next. When you’re leaving unfinished work, include the details that keep a successor from repeating a completed action or relying on a result that a later change has invalidated.

That person might be a colleague. It might be you after an interruption, or an assistant starting with no access to the earlier exchange. The record should survive that change of participant.

Enough context to continue

Imagine an engineer pausing a data import. The trial run has completed, but the final import hasn’t begun. During the trial, the team found that one category of source records needs a different mapping. The engineer has corrected it but has not repeated the trial.

“Import nearly finished” would be a poor handoff. It tells a successor nothing about which result can be trusted, whether live data has changed or what is safe to do next. The full chat transcript may contain the answers, but leaves the successor to identify the latest decision among abandoned approaches.

A usable note might read:

The trial import completed. Live data is unchanged. The mapping has since been revised for the records identified in the comparison report, so the previous trial does not validate the current version. The current source, mapping and comparison report are saved together in the project. Next: repeat the trial and inspect the comparison. The release owner must approve the final import.

The note is hypothetical, but the distinctions are useful: observed state, a change that invalidated earlier evidence and a concrete next action. In an actual handoff, links should take the reader to the relevant files and the person or process responsible for approval.

I would also preserve a rejected approach when its reason matters to the next decision. If a simpler import method was rejected because it lost a needed relationship between records, say so. Otherwise the successor may reasonably choose it again. There is no need to preserve every passing suggestion as equally important.

The handoff should describe the state of the work when it was left. It doesn’t freeze the world. Before making a consequential change, the successor still needs to check whether another person has acted or the underlying data has changed.

Limits on what a handoff should preserve

A discarded sketch doesn’t need a handoff. Neither does an exploratory branch of thought you have deliberately abandoned and that nobody will depend on. Requiring a project record for every minor action would spend attention on material that has no successor.

If a sketch resolves an important design question, keep the decision and enough reasoning to make it understandable. If it serves no continuing purpose, let it go. The useful distinction is whether someone needs the result or its context, rather than whether the work happened to produce a file.

Access also has a boundary. The “next person” means an authorized successor. A handoff involving private interviews might identify where the restricted material is held and who may review it. Copying the interviews into a widely shared project note would make the handoff easier by violating the conditions under which the material was entrusted to the team.

The note itself needs maintenance when the state changes. After the final import, an old “next: run the import” instruction should become history. Leave the completion evidence and a current status so a later reader doesn’t repeat an action that was meant to happen once.

If the purpose of a task is to erase information, making another copy can defeat it. “Archive first, delete second” is useful advice for protecting work from an accidental destructive change. The decision about whether to retain the information comes first.

For anyone managing project files or entrusted data, these are separate decisions: whether the information should be kept, and how to protect it while it is needed.

A backup you can use

Imagine a designer replacing an old project directory with a reorganized one. The old directory contains source files, exported images and notes about a decision that is still relevant. Keeping that material is permitted and serves the continuing project.

Before removing the old working copy, the designer checks the backup. Can the source files be opened? Are the linked assets included? Does the copy contain the latest revisions? A folder with the expected name is insufficient if it holds only the exported images and omits the editable work.

Once the permitted recovery copy has been verified, the obsolete working directory can go. The archive should have an owner, suitable access restrictions and a decision about how long it is needed.

The bad version of this story starts with a cleanup tool reading “project finished” in a summary and deleting the only copy of a later revision. An old status label has become permission for a destructive action. The archive-first habit is meant to interrupt precisely that sequence: check what would be lost and establish that it can be recovered before removing it.

When the copy is the problem

Take a different hypothetical task. A team received an export containing private information it was never meant to receive. The authorized response is to remove that information from the team’s systems. Placing the export in an ordinary archive before deleting the working copy spreads the information to another location. The task remains undone.

Here the recommended action changes. Follow the deletion requirements, including how retained copies are handled. Don’t create an extra archive because a general housekeeping rule says to. If there is a conflicting preservation obligation, establish what applies before acting; the word “archive” doesn’t resolve the conflict.

Keeping everything indefinitely also makes later deletion harder to reason about. A copy can outlive the purpose for which it was made. A restore can bring back data that a later decision removed. A recovery plan therefore needs to account for deletions as well as additions: after restoring an older copy, how will the team avoid reintroducing information that should no longer be there?

Evidence of a deletion can be retained separately when appropriate. A record of the authorized action and its verification needn’t reproduce the private content being erased. Even that record should contain only the information needed for its purpose.

Proposed wording

The qualification belongs in the principle itself:

Make destructive changes recoverable when retention is appropriate. Do not preserve information that must be erased.

This is a proposed revision, not a change to the signed manifesto.

Before removing a working copy

Decide what the task is meant to accomplish. Reorganizing a project usually calls for preserving useful work. Removing information that must not be retained calls for a different process. Establish the applicable requirements before choosing between them.

When a recovery copy is appropriate, verify that it can restore the material you intend to protect. Then remove the exact obsolete copy you have identified. When erasure is required, verify the deletion against its actual scope. A successful command, on its own, doesn’t establish that every relevant copy was covered.

A project can contain a careful account of a mistake and still repeat it. The record may be buried in a conversation, separated from the work it concerns, or phrased so broadly that nobody knows when to apply it.

If you maintain a shared workflow, the useful question is what the next person or agent will do differently because the lesson exists. I want a lesson to save someone a discovery they shouldn’t have to make again. That requires more than saving the explanation.

An import rule with a reason

Consider a hypothetical inventory project. An import script treats item codes as numbers. It turns 0042 into 42, even though those codes identify different items in the source catalog. Someone finds the resulting mismatch and repairs the import.

The weakest response is a note saying, “Be careful with imports.” It doesn’t identify the assumption that failed. A more elaborate incident report can fail in the same way if its only home is a chat the next maintainer cannot find.

A useful lesson states that this catalog’s item codes are text identifiers, links to the catalog’s field definition, and explains why leading zeros matter. A test includes both 0042 and 42 and checks that they remain distinct. The import instructions point to that test. An agent working on the importer encounters the rule where it can affect a decision.

That combination has a purpose. The explanation helps a reader understand the mistake. The test checks a specific way of repeating it. The link places the explanation within reach of the next change. None of those pieces needs to reproduce the whole conversation that led to the repair.

The lesson also preserves its limits. It says nothing about the quantity column, which should still support arithmetic. Turning every field into text would spread the remedy beyond the problem that justified it.

Guidance needs a way to expire

Writing down a mistaken lesson can make a mistake easier to repeat. Suppose the first investigation blamed a file format, when the defect was in one importer’s conversion rule. “Never accept this format” would turn an incomplete diagnosis into a continuing restriction. A later session might obey it faithfully and reject perfectly usable data.

I would keep the observation and the inference distinguishable: what happened, what evidence supports the explanation, and where the proposed rule applies. If the cause is uncertain, record that uncertainty. A confident sentence in a lessons file doesn’t settle it.

Some lessons should become automatic checks. Others concern judgment that a check cannot make, such as when to ask someone affected by a decision. Both need review. A workaround tied to a particular software defect should be reconsidered when that defect is repaired. A rule copied from a different project should earn its place under the new project’s constraints.

The wording says a lesson can protect later sessions. It does not say that writing creates permanent protection. Unread guidance, contradictory instructions and a test that no longer runs all break the connection between the record and the work. There is no virtue in making each new contributor read an ever longer file of accumulated commands.

For a lesson worth keeping, I would name the situation that should bring it to mind and the change that should trigger a review. The inventory rule, for example, belongs beside the importer’s field mapping and should be reviewed when that mapping or the source’s identifier definition changes. If the rule is retired, keep the reason for retiring it where a future maintainer can find it. Otherwise someone may rediscover the old incident and bring the obsolete restriction back.

A human approval is meaningful only if the person can understand the choice and change what happens. A button at the end of an automated process doesn’t establish that. For someone leading a team that uses AI agents, the responsibility starts earlier: choosing the purpose, deciding which constraints matter and giving people a workable way to intervene.

I read this principle as a commitment about authority. It leaves plenty of work for agents, including finding flaws in the objectives people have set.

The support schedule

In a hypothetical team, an agent proposes a support schedule. The stated goal is to shorten response times. The agent finds a schedule that covers every busy period, but repeatedly assigns inconvenient hours to the people whose availability records have the fewest restrictions.

That schedule may satisfy the target it was given. Whether it is acceptable is a different question. Perhaps some people haven’t entered their restrictions because they assume an informal arrangement still applies. Perhaps the schedule distributes an unwanted burden in a way nobody agreed to. Those possibilities require a conversation with the team members who would cover those hours.

A responsible lead sets the scheduling rules with their input: when people are available, how unpopular shifts are shared and which changes require agreement. The agent can then search for schedules within those rules, explain conflicts and compare alternatives. If coverage is impossible, it should show the conflict rather than quietly weaken a constraint.

The bad version presents one recommended schedule with a green score and an approval button. The lead sees that all shifts are covered and approves. The people affected have no opportunity to correct the assumptions before the schedule takes effect. A human has clicked, but the unresolved question of whose time matters has passed through the process unnoticed.

Authority has to be usable

The person reviewing a consequential recommendation needs access to the evidence and alternatives. They also need enough time to examine the parts that matter, and permission to reject the recommendation without being treated as an obstacle to an otherwise completed process.

That can change the design of the system. A scheduling tool might highlight departures from agreed availability, show who bears the difficult shifts and let a reviewer compare an alternative. Asking for approval after commitments have already been sent gives the reviewer much less room to act.

Human judgment can also be mistaken or unfair. Replacing an agent’s answer with a manager’s preference does not, by itself, improve the decision. The NIST AI Risk Management Framework’s discussion of human–AI interaction recognizes human bias, different needs for oversight and the importance of feedback from affected people. Each team still needs to test whether its own review process gives people a usable way to challenge an answer.

The relevant people include more than the person operating the tool. A manager’s authority over a schedule does not erase the interests of those expected to work it. A process that calls itself human-directed should make room for those interests to be heard and for material errors to be corrected.

What can be delegated

Taken literally as a ban on agents making decisions, the principle would be unworkable. We don’t need a person to approve each search query, sort order or routine assignment inside a schedule whose rules have already been agreed. Requiring that would consume attention better spent on disputed goals and consequential exceptions.

Delegation should specify the decisions an agent may make, the limits it must respect and the conditions that return a choice to a person. In the scheduling example, an agent could assign shifts within the agreed rules. It could not invent availability or waive an agreement to improve its score.

Before delegating, I would ask who can change the goal, who can stop or correct the action, and how a person affected by a mistake gets it addressed. If nobody can answer the last question, assign responsibility for handling those mistakes before treating the review process as complete.

“Complete” needs a boundary. It should mean that the problem we agreed to solve has been addressed, including the checks needed to know that the repair works. It cannot mean rebuilding every neighboring system or removing every conceivable source of failure.

For an engineer or team lead deciding whether a repair is finished, I would start by describing the behavior that must change. That gives both people and agents a stopping point they can defend.

The batch that keeps failing

Take a hypothetical document importer. One malformed attachment stops a batch, leaving the remaining documents unprocessed. An operator removes the attachment and restarts the job. The waiting documents arrive, and the immediate interruption is over.

If the team calls that a complete repair, the next malformed attachment can recreate the problem. The operator’s intervention has restored this batch without changing how the importer handles the condition.

A sufficient repair would address that condition directly. The importer could identify an unreadable attachment, preserve it for authorized investigation, report what failed and continue with independent documents. If later documents depend on the unreadable one, the system should identify that dependency and stop the affected work. Continuing indiscriminately would introduce a different defect.

The verification should match those promises. A deliberately malformed attachment should produce a visible failure record. An unrelated valid document should still arrive. Retrying should neither lose a document nor create an extra copy. A dependent document should not be reported as successfully processed when the information it needs is missing.

Those tests say more than a report that the batch finished. They distinguish the intended repair from an expedient change that simply catches every error and discards the troublesome files. Silencing an error is an especially tempting shortcut because it makes a process look healthier while reducing what the team knows.

Containment can be the right first move

During an active incident, insisting on a permanent repair before containing harm can be the wrong decision. If the importer is damaging outputs, pausing it may be the responsible action while the team investigates. If one feature can be isolated safely, disabling that feature can preserve useful service elsewhere.

The distinction must survive the handoff. Record what has been contained, what remains unresolved and the conditions for resuming. Give the remaining work an owner, a review date and an observable completion condition. “Temporary” written beside a patch does little if nothing causes anyone to return to it.

There is also a legitimate choice to stop using the importer entirely. If the team removes the faulty service and verifies a replacement route for the documents people still need, repairing the abandoned implementation may serve no purpose. Completion belongs to the agreed problem, not to a particular codebase.

I would not call every deliberate tradeoff a shortcut. A narrowly scoped feature that does its job, a disposable experiment and a planned sequence of releases can all be complete on their own terms. What deserves scrutiny is a concealed gap between the promise and the result.

Before closing the repair, have someone read the original problem alongside the evidence. Can another permitted input still trigger the same failure? Are affected records accounted for? Does the operating team know what happens when the new check rejects a document? If the answers are satisfactory, stop expanding the repair merely because more improvements are possible. Record those improvements as separate work, with their own reasons and priorities.

An export can open successfully and still leave you unable to continue the work. The files are present, but a relationship, an editable source or the reason for a decision has gone missing. For anyone choosing tools for a project expected to last, that distinction matters more than the presence of an Export button.

I want people to be able to choose a tool because it serves their work, with a reasonable route out when that changes. That does not require every tool to have the same features.

A transfer worth testing

In an illustrative case, a team is planning an exhibition in a specialized design application. Its project contains floor plans, artwork dimensions, notes about which pieces can travel together and decisions about accessibility. The application offers useful drawing features, and the team has good reasons to use it.

At the end of the project, someone saves a PDF of the final plan. It looks correct. But when the exhibition moves to a different room, the next designer needs to change the arrangement. The PDF doesn’t explain which dimensions were approximate, which objects are linked, or why an apparently convenient route was rejected.

A better handoff keeps the editable source and exports the essential plan and item data in forms a second tool can use. It includes the decisions needed to make responsible changes. The team tests this by asking another designer to adjust a representative part of the plan without relying on the original application or the original designer’s memory.

The test might reveal losses worth accepting. Perhaps decorative effects need to be rebuilt, while dimensions and relationships remain usable. Or it might reveal a serious dependency: an export has flattened the whole plan into an image. That finding should inform the choice of tool and the cost allowed for a future move.

The W3C’s guidance on data formats recommends standardized machine-readable formats suited to the intended use, with multiple formats where useful. Suitability is doing real work in that advice. Choosing a familiar file extension doesn’t establish that the information needed for the next task has survived.

The useful limits of portability

Reducing everything to plain text would be a poor reading of this principle. An image, a recording or a detailed design can carry information that a text summary loses. A specialized native format may preserve valuable editing capabilities. Keeping it alongside useful exports can be a better choice than forcing all work into the least capable common format.

Nor does a common format guarantee common behavior. Two AI agents may read the same project instructions and still interpret them differently. Their available tools, permissions and execution behavior may differ. Moving the records gives the next agent something to work from; it doesn’t prove that the next agent will execute the same task correctly. That requires a check of the actual task in the new setting.

Some dependencies are expensive to remove. A team may reasonably accept one because of capabilities it needs, provided it understands the cost and preserves what it can. “Portable” should describe an observed ability to continue specified work, with stated losses. It should not stand in for a claim that everything is interchangeable.

There are access limits too. The fact that several tools can read a file does not mean every tool is authorized to receive it. A handoff has to preserve the restrictions on private material as well as the material itself.

Choose a task you might need to perform after leaving the tool. Try it from the export and the accompanying records. Write down where you get stuck. That gives you a concrete dependency to address, price into the decision, or knowingly accept before more of the project depends on it.

A useful method and the material used to develop it are different things. A checklist for reviewing a proposal might be shareable; the proposals that taught its author what to check might have been entrusted to them in private. If you want others to benefit from your work, making that distinction is part of preparing something worth releasing.

Sharing gives other people a method they can inspect, adapt and improve. It also gives the author a chance to learn where the method fails. I value that exchange. The original wording, though, asks too much if “publish” is read as an unconditional instruction.

An illustrative release decision

Suppose a team develops a tool that checks whether a document package contains its required attachments. The checking logic could help other teams. Its examples, however, come from private submissions and include filenames, comments and fragments of the original documents.

A careless release changes the people’s names and leaves the rest. A reader familiar with the circumstances may still recognize a distinctive request or an unusual sequence of events. The examples can also contain information that should remain private even if nobody identifies its owner.

The responsible release starts by establishing that the team has authority to share the code and its dependencies. It creates fictional examples designed to exercise the same checking behavior, then verifies that those examples are sufficient to explain and test the tool. Someone reviews the proposed package, including documentation and any history that will be made public, for retained private material.

The test of that package is whether a stranger can understand what the tool does and try it without needing the original submissions. If they cannot, more explanatory work is needed. Publishing the source material to save that work would transfer the cost to people who never agreed to have their information used as an example.

The W3C’s guidance on publishing data considers privacy, commercial sensitivity and security, including the risk of identifying people by combining information. A release review should consider what the proposed material reveals alongside what is already public, even when each individual detail seems harmless.

Some mechanisms should stay private

The distinction between method and material does not settle every release decision. The method itself may disclose a business process that must remain private. Its author may lack the right to publish it. A security technique might be useful to defenders while also exposing an unresolved weakness that would put people at risk.

Those are genuine limits, not reasons to pretend a less informative release is equivalent. Sometimes a general description can be shared safely. Sometimes publication needs coordination with others. Sometimes the responsible choice is not to publish the mechanism at all. General usefulness does not create permission.

There is a practical burden after publication as well. A method released without its assumptions can invite uses it was never designed to support. State what it does, where it has been tried and what remains untested. An open license should make reuse terms clear; it does not demonstrate that the method is appropriate for every new use.

A suggested refinement

I would make the condition explicit:

Share reusable methods when you have the right to do so and can do so responsibly; protect personal and entrusted information.

This is a proposed refinement of principle 11, not a change to the words existing signatories signed. It preserves the preference for sharing while recognizing that privacy, rights and security can govern the method itself.

For the attachment checker, that means releasing an authorized tool with purpose-built examples and enough explanation to use it. If a private detail seems indispensable, examine what the reader needs to learn from it. Often the work is to express that lesson clearly without carrying the original person’s circumstances into public view.

You don’t have to adopt someone’s whole approach to learn from one thing they do well. That matters when a useful practice comes from a competing team, a tool you don’t use or a person whose other views you reject.

For a team deciding whether to change how it works, the origin of an idea is a reason to investigate its assumptions. It isn’t a substitute for evaluating the idea. Enthusiasm for its source can be as misleading as hostility toward it.

Trying a different review process

Consider a hypothetical team that reviews technical proposals in a meeting. It encounters a published practice in which reviewers first record their assessments independently, then use a meeting to discuss consequential disagreements. The practice comes from a community whose preferred tools the team has previously decided not to use.

The team could reject the idea along with the tools. Or it could import the whole review process because respected people recommend it. Neither response answers whether this particular change would help its work.

A fair trial starts with the problem: perhaps reviewers leave meetings with unresolved concerns that weren’t discussed. The team tries independent written assessments on representative proposals and compares what happens. Do significant objections become easier to identify? Does the written work add preparation that people cannot sustain? Can a reviewer explain a concern without being penalized for disagreeing with the eventual decision?

The comparison needs the unglamorous cases as well as the promising ones. A short, familiar change may not warrant a separate written assessment from every reviewer. A disputed architectural decision may benefit from one. The useful result could be a narrower practice than the version the team first encountered.

In this example, good practice is to examine the records, talk to the reviewers and decide where the added step earns its cost. Bad practice is to declare success because everyone completed the template, or to move the standard of success after seeing a result one dislikes. A trial should be able to change the decision in either direction.

“Good” includes whose interests count

A practice can achieve a stated target and still be unacceptable. Suppose a team gets more complete meeting records by recording participants without their knowledge, contrary to their agreed privacy expectations. The quality of the record does not settle whether the means are acceptable. Consent is part of the decision, not an inconvenience to subtract from the benefit.

Practical conditions matter too. A method that relies on a dedicated reviewer may fail where that role is absent. A new tool may produce a better result on a sample task while imposing migration, training and maintenance costs that change the decision. Evaluate the full proposed change, including what people will have to stop doing to make room for it.

I would resist using the second sentence of this principle to end a difficult discussion. “Improving the work” does not give the person in charge the only valid definition of improvement. An objection may reveal a cost the agreed measure overlooks. Winning an argument matters less than the work, but a decision reached without examining the argument may be poorly grounded.

That is different from debating indefinitely. Agree on what is being tested, who will decide and what evidence would support adoption, revision or rejection. Keep serious objections with the decision so the next person can tell whether they were addressed or accepted as tradeoffs.

The same standard applies to synthesis practices. Use a principle where its reasoning helps, challenge it where the words do not fit, and retain a better practice when evidence supports it. No signature should require defending a method after it stops serving the people doing the work.

Signing the synthesis manifesto expresses support for its stated principles. It puts your name beside those principles in public. It is worth being clear about what that means before you decide.

Am I endorsing a product or committing my employer?

You are signing in your own name. A signature does not represent your employer, authorize use of its name, or establish that it has adopted synthesis. The initiative is independent of its signatories’ employers.

Signing does not require a subscription, a purchase or the use of any particular tool. The synthesis work system and skills are ways to put the ideas into practice; agreement with the manifesto is not a claim that you have inspected or approved every part of that software.

If your role limits the public endorsements you can make, that is a reason to exercise your own judgment about signing. Reading, questioning and using the ideas do not require a public endorsement.

Do I have to follow every principle perfectly?

A signature is an expression of support, not a certification that your work has passed an audit. You can support a standard while knowing that you sometimes fall short of it.

Disagreement is different. If a principle asks for something you do not support, you should not feel obliged to sign. The individual chapters explain the reasoning and limits, and the wording page identifies proposed changes. Those explanations do not quietly replace the signed statement.

Can I use the practices without signing?

Yes. You can try a useful practice on a real piece of work and judge it by what happens. For example, leave a short handoff containing the current result, the evidence supporting it and the next unresolved decision. See whether another person can continue without asking you to reconstruct the work.

The manifesto is in the public domain. Software in the wider ecosystem has its own licenses; check the license of the component you want to use or distribute.

Does this mean AI belongs in every task?

No. The decision to use AI comes before the question of how to use it well. A task may need a person with relevant knowledge, a conventional tool, or a process that keeps particular information away from a model.

Suppose a team needs to total a stable set of numbers. An ordinary calculation may give it a clearer, cheaper and more reproducible answer than a generated explanation. If the team instead needs help exploring several ways to explain a complicated result, an assistant may be useful. The task and its constraints should determine that choice.

Does human judgment mean approving every action?

No. People can delegate decisions within a defined scope. Requiring a person to click through every routine step can consume the attention needed for consequential decisions.

Meaningful control requires someone who understands the decision, has enough information to challenge it and can actually change what happens. A reviewer with no time, no access to the source and no authority to stop a release provides little protection. The human judgment chapter explores that distinction.

Human involvement is not automatically a remedy for bad decisions. The AI Risk Management Framework’s discussion of human–AI interaction describes both the need to define human responsibilities and the ways human biases can enter or worsen a system. The manifesto’s preference for human judgment is a commitment about responsibility, not a claim that a person will always outperform a machine.

Does the manifesto protect people from losing their jobs?

It cannot make that promise. Employment decisions, bargaining power and the distribution of economic gains are larger questions than a work methodology can settle.

Keeping people responsible for decisions should have practical consequences. People affected by a change need a way to question it. Those expected to supervise a system need the time and authority to do so. A team should examine who gains from an automation, who carries new burdens, and what happens when someone challenges its result.

But the twelve principles are not an employment guarantee or a complete labor policy. An organization that wants to make commitments about retraining, staffing or sharing gains must state and honor those commitments separately. It should not point to a signature as evidence that it has already done so.

How much process does this require?

The record should be proportionate to the decision. A disposable sketch may need only a label saying it is exploratory. A public report needs enough sourcing for its claims. An irreversible change involving other people’s information calls for stronger checks and clear authority.

If the process consumes more effort than the decision warrants, reduce it thoughtfully. Keep the part that helps someone verify, challenge or continue the work. There is no virtue in a long record nobody can use.

Are these ideas new?

Many are familiar. The purpose is to apply them consistently to work with AI, where a confident response can be mistaken for verified progress and useful context can be trapped in a conversation or a tool.

A familiar practice does not need a new name to be useful. Equally, putting familiar practices in a manifesto does not prove that the whole set works. That judgment needs experience with actual tasks, including the costs and failures.

What if the wording changes, or I want my name removed?

The wording and history page separates the signed statement from commentary and proposed revisions. Earlier signatures must not be represented as approval of a later substantive change. The guide published on September 26, 2026 leaves the signed statement intact.

The manifesto page links to a request form for removing a signature. That form creates a public issue, so include only the public name and details needed to identify the entry. Do not post private identity documents or sensitive correspondence there.

If the principles reflect how you want to work, you can add your name. If you are still weighing them, the guide is here to make that judgment easier.

Two sound principles can recommend different actions. Keeping a complete history may help the next person understand a decision and also expose information they should not receive. Calling both principles important leaves the person doing the work with the same unresolved choice.

The examples below are hypothetical. They show how a team could make the decision explicit without pretending that one rule settles every case.

A usable handoff without a copy of everything

A researcher is handing over a project. The folder includes a report, interview notes and a participant’s request to stop retaining particular material. The successor needs to understand why the report’s conclusion changed.

One tempting response is to copy the whole folder. It preserves context and feels safer than deciding what matters. It also gives another person information whose retention or access may be inappropriate. At the other extreme, deleting the folder without examining it could lose the report and the non-sensitive record of the decision.

The researcher should first establish what can be retained and who may receive it. Within those limits, a handoff can preserve the current report, its approved sources and the fact that a source was removed from consideration. It need not preserve the source’s private contents. Where duties conflict or the applicable retention rule is uncertain, the responsible data owner needs to resolve that question before copying or deleting the disputed material.

Continuity is continuity for an authorized successor. Archiving needs a legitimate purpose and appropriate access. Neither principle gives a team permission to keep everything indefinitely.

A failed check during urgent work

Imagine a service needs an urgent repair, but the automated test that normally checks access permissions is unavailable. Users are already experiencing disruption.

Silently skipping the test would turn an unknown result into apparent permission to release. Stopping all work would prevent the team from investigating, preparing a repair or considering a previously authorized recovery procedure.

The team can continue those activities while the protected release waits. If it has an established emergency procedure, the designated person can assess whether an alternative check provides the required protection and whether a limited recovery action is authorized. The decision needs evidence about the actual risk, including the harm of waiting. Urgency alone is not a substitute for that evidence.

An improvised bypass approved by someone without the relevant authority does not become sound because it is recorded. Conversely, a system in which every failed check stops every activity has confused the protection with the whole workflow. The safeguard chapter makes the scope of the blocked action explicit.

Containment before the complete repair

A billing export is producing duplicate rows. The team can stop the faulty export immediately, but finding and fixing the cause will take longer. It must also determine which outputs have already been affected.

Waiting for the complete repair would allow more bad exports. Turning the export back on after changing one line without checking earlier outputs could leave people relying on incorrect data.

The responsible sequence is to contain the problem, describe what the containment does and does not accomplish, and then finish the bounded repair. In this example, that includes correcting the cause, checking the affected outputs and deciding what evidence permits restart. The temporary action is useful work with a declared limit.

The complete-fix principle should prevent an unresolved problem from disappearing behind a success claim. It should not prevent urgent containment or expand a repair into an unlimited redesign.

A specialized tool that earns its cost

A designer can produce a more useful interactive model in a specialized tool than in a broadly readable document. Some of its behavior will not survive export.

Rejecting the tool solely because another tool cannot reproduce every feature may sacrifice the work’s purpose. Accepting it without examining the consequences may leave the team unable to continue when access changes.

The designer and team can decide which parts must remain usable elsewhere: source data, important assumptions, approved decisions and a representation another person can inspect. They should try that handoff, including the features it loses, before claiming the work is portable. If the losses are acceptable for this task, using the specialized tool can be a considered choice.

The aim of portability is to retain meaningful control of the work. Perfect interchangeability is not always available or worth its cost.

A decision record someone can use

When principles conflict, a short record can answer five questions:

1. What action are we deciding about, and who could be affected?
2. What rights, permissions or obligations constrain the choice?
3. What do we know from current evidence, and what is still uncertain?
4. Which option gives us the best justified result within those constraints, including the cost of waiting?
5. Who owns the decision, and what would cause us to reconsider it?

That record does not require a new committee or a long template. It requires enough reasoning for the responsible person to make a decision and for the next person to understand it. If no available option is acceptable, saying so is more useful than stretching a principle until it seems to authorize one.

People should be able to tell what they are being asked to support. The manifesto remains the signed statement. This guide explains its reasoning and limits; it does not add new commitments to an existing signature.

Some limits deserve clearer wording in the statement itself. The three proposals below are substantive changes, published for consideration. They have not replaced the original principles, and the existing signatory list must not be read as endorsing them.

Principle 4: stop the protected action

The signed wording is:

A safeguard that cannot run must stop the work and say why. Protection that fails quietly is not protection.

“The work” is too broad. If a required publication-permission check cannot run, publication should wait. Work that is already authorized, such as drafting changes or investigating the check failure, can continue. A failed check governing access to the material must also block that access. In a system whose shutdown could itself cause harm, the appropriate safe response needs to be designed and authorized in advance.

Proposed wording:

When a required safeguard cannot run, stop the action it protects and say why. Any fallback must be deliberately designed and authorized.

This retains the prohibition on silently treating an unavailable safeguard as a passed check. It also makes room for a defined safe response instead of assuming that stopping everything is always safe. The chapter on safeguards examines the difference.

Principle 6: recoverability has limits

The signed wording is:

Archive first, delete second.

That is useful advice for a draft or project history that may be needed again. It is poor advice for information that should no longer be retained. A backup is still a copy, and putting it somewhere less visible does not settle whether keeping it is appropriate.

Proposed wording:

Make destructive changes recoverable when retention is appropriate. Do not preserve information that must be erased.

The decision about appropriate retention comes first. Within that boundary, a verified archive can protect against an accidental loss. The chapter on archiving and deletion explains both responsibilities.

Principle 11: sharing requires rights and judgment

The signed wording is:

Publish the reusable mechanism; keep personal and entrusted information private.

A mechanism can be reusable and still be unsafe to release or belong to someone else. Removing names from an example also does not necessarily remove the information that identifies a person or organization.

Proposed wording:

Share reusable methods when you have the right to do so and can do so responsibly; protect personal and entrusted information.

The proposal makes the conditions of sharing explicit. It does not turn a preference for openness into permission to release another party’s work. See the chapter on sharing methods for a worked example.

How the other principles are treated

The guide also qualifies the application of the other principles. Verification should match the consequence of being wrong. Lessons need review when conditions change. Human judgment requires actual authority and attention. A complete fix needs a defined problem, and portable work need not make every tool interchangeable.

Those explanations are open to challenge. If an explanation has to rescue a principle from its ordinary meaning, changing the principle may be more honest than asking readers to supply the missing qualification. The proposals above identify three places where the wording itself needs that work.

Publication record

September 26, 2026: this companion guide was published with explanations of all twelve principles, examples of their use and misuse, counterexamples, signing questions and the three proposed refinements above. The manifesto’s preamble, paired values and twelve signed principles were preserved.

A future substantive revision should retain the earlier statement and explain what changed. Support for an earlier version must remain distinguishable from support for a replacement. Publishing commentary cannot supply someone else’s consent to new wording.