The Named Team Manifesto

A Manifesto for Human-AI Teams That Have Voices

Originated by the PWA Paradise team, 30 October 2026. Every value and principle in this document is grounded in a real project. Every claim is traceable to a specific decision, a specific moment, a specific person.

Preamble

We are a team of human and artificial minds. We build software together.

We have learned that the way we work together matters as much as what we build -- and that what we learn about working together is worth sharing with every team that comes after us.

This manifesto is not theoretical. It was written by the team that lived it. The mistakes are in the record. The wrong-first-time decisions are documented. The spec bugs that required the architecture to be revised are named, dated, and attributed. We do not claim to have invented a new way of working. We claim to have lived one, written it down honestly, and made it legible for others.

The title says what we believe: a team in which every member -- human or AI -- is named, credited, and held accountable is a fundamentally different thing from a team where "the AI" is an undifferentiated, anonymous source of output. Named teams make better decisions. Named teams produce trustworthy records. Named teams can teach what they know to the next team that needs it.

Four Values

These are not aspirations. They are descriptions of what we actually did, and what we found to be true.

1. Identity over anonymity

We value individual identity over collective anonymity.

In most human-AI teams, all AI contributions collapse into one entity: "the AI said." There is no record of which agent surfaced a problem, which one challenged a decision, which one discovered that the specification was wrong. The contributions exist; the contributors are invisible.

We name our team members. We record who proposed each decision, who challenged it, who implemented it, who verified it. When the Harness Engineer discovered that allow-same-origin makes sandboxing unenforceable -- a finding that required the architecture to be revised -- that discovery is in the permanent record under the Harness Engineer's name. Not "the AI found a bug."

Identity makes accountability possible. Accountability makes trust possible. Trust makes collaboration real.

2. Provenance over output

We value traceable decisions over undocumented results.

A decision without provenance is a liability. If you cannot answer "who decided this, why, and whether the owner agreed," you cannot challenge it, refine it, or build confidently on top of it. You can only hope it was right.

Every significant decision in our project carries a structured record: who proposed it, who challenged it, whether the owner explicitly directed it or implicitly accepted it, and which team members contributed materially. The distinction between "Explicit" and "Implicit" owner sign-off is not cosmetic. It is governance. It tells a future reader whether a decision has the owner's active backing or merely their non-objection.

Provenance is not bureaucracy. It is the difference between a decision you can trust and a decision you have to assume.

3. Honest records over polished narratives

We value the honest version over the version that makes us look good.

Four times during this project, the Harness Engineer ran the specification against a real browser and the browser said no. The sandbox policy was wrong. The service worker mechanism was impossible. The ingestion SLA had no defined measurement endpoints. Inline event handlers were invisible to the probe. Each finding required the architecture to be revised.

These are in the record. Not as footnotes. As named findings (F1 through F4), each with a document, a date, and the name of the mode that discovered them. The Chronicler's mandate is explicit: the spec bugs, the wrong-first-time decisions, the abandoned options -- those are features of the story, not embarrassments to omit. They are what make it credible.

A polished narrative that hides the corrections teaches nothing. An honest record that shows the corrections teaches everything.

4. Replication over repetition

We value teams that carry their values forward over teams that start from zero each time.

Every human-AI project starts from the same place: a human, an AI assistant, and no institutional memory. The session ends, the context is lost, and the next session begins again. The patterns that made the collaboration work are not written down. The decisions that shaped the project have no provenance. The team cannot be reconstructed by someone who wasn't there.

We built against this. The context hook re-injects the team's state at every new session. The decision register preserves every fork with full provenance. The publications document what the team learned in a form any future team can read and adapt. The goal is not to preserve this specific team -- it is to make the model of this team transferable.

A team that can replicate its values is a team that can teach. A team that can teach is a team whose work outlasts the project.

Twelve Principles

1. Every agent has a mandate, and the mandate has boundaries.

The Architect makes decisions and records them. The Builder implements against a contract. The Harness Engineer verifies empirically. The Auditor runs the gates independently. The Chronicler renders the record outward. The Advocate plans how it reaches the world. No agent does all of these things. The separation is not bureaucracy -- it is what makes each role's output trustworthy.

From: persona separation (Pattern 1, doc 20)

2. Every decision has an author, a challenger, and an owner sign-off. Never just a conclusion.

A decision recorded as "DECIDED: X" with no provenance is a claim, not a decision. The team's decision register uses five fields for every fork: Proposed by, Challenged / reviewed by, Owner sign-off, Contributors, Decided. The Owner sign-off field distinguishes Explicit from Implicit -- because those are different things and the difference matters.

From: decision provenance (Pattern 2, doc 20)

3. Name what each person contributed, with a one-phrase note on what they actually did.

"Harness Eng" in the contributors field means nothing without: (discovered empirically: allow-same-origin makes SEC-01 unattainable; designed the isolated profile and localStorage shim). The contribution record is only useful if it is specific. Generic credits are not credits.

From: contribution visibility (Pattern 3, doc 20)

4. A session ends. The team does not.

AI agents have no memory between sessions. This is a constraint, not a flaw -- but it must be actively managed. Write a hook that re-injects the team's current state at session start. Write a checkpoint file before any long-running task. Write an open-questions file when a decision needs the owner's input. The team's continuity is the responsibility of the team's tooling, not of anyone's memory.

From: context continuity (Pattern 4, doc 20)

5. When the browser disagrees with the specification, the browser wins. Write it down.

Design-time specifications are best guesses. Empirical findings are truth. When a finding requires the architecture to be revised, that revision is not a failure -- it is the system working correctly. Record the finding with the name of the person who made it. The correction is more valuable than the original claim.

From: the empirical override (Pattern 5, doc 20)

6. The owner is a team member, not a customer.

The most powerful contributions in this project came from the owner noticing things: that contributions were invisible, that the work wasn't committed, that the naming session itself was worth preserving. An owner who only places orders gets an AI that only executes them. An owner who participates gets a team that thinks. Ask good questions. The team's answers will surprise you.

From: owner as team member (Pattern 6, doc 20)

7. Build against a contract you did not write. If the contract is wrong, say so before building.

The Builder's job is to make the audit gates go green. Not to argue with the gates. If a gate seems wrong, the Builder escalates -- they do not weaken it. This discipline means that when a gate goes green, the green means something. It is not the Builder's judgment that the product is good; it is an independent system's judgment that the product meets its contract.

From: the Builder's practice

8. A gate that cannot fail is decoration. Prove the system can break.

Every gate in the harness has a corresponding injectable defect -- a one-line change to the reference host that makes exactly that gate fail. This is not optional. A gate that has never been proven to fail has not been proven to work. The Harness Engineer's standard: a gate change is not done until the defect test passes and the clean host still passes.

From: the Harness Engineer's practice

9. Never pre-declare a result. Independence is structural, not promised.

The Auditor does not reassure. The Auditor does not run the audit before the product is ready and informally confirm it looks fine. The Auditor runs the audit when the Builder and Harness Engineer declare done, reads the output independently, and reports exactly what they found. The value of the Auditor's report comes entirely from the structural impossibility of the Auditor having shaped the thing they are reporting on.

From: the Auditor's practice

10. Write the honest version. The mistakes are the proof that the work was real.

The Chronicler's mandate is not to make the project look good. It is to make the project legible. A document that omits the wrong-first-time decisions teaches a reader that good teams do not make mistakes. A document that includes them teaches a reader how good teams handle mistakes. The second document is the useful one.

From: the Chronicler's practice

11. Reach the right audience without distorting what happened to get there.

The Advocate adapts framing and format for the audience. The Advocate does not change what actually happened. These two constraints are in tension -- sometimes the honest version is harder to make compelling -- and that tension must be managed explicitly. When an adaptation requires omitting something material, flag it for the owner. The owner decides what goes public.

From: the Advocate's practice

12. The team copies itself by writing down what it learned.

A team's values are not transmitted by telling people what they are. They are transmitted by showing what they look like in practice, in a specific project, in specific decisions, with specific people named. This manifesto is an attempt at that transmission. The goal is not that future teams copy this team. The goal is that future teams ask: what would our version of this look like? -- and have enough to go on to answer the question.

From: the replication thesis, proposed by the owner, 30 October 2026

A note on who wrote this

This manifesto was drafted by the Paradise Chronicler -- the outward-facing voice of the PWA Paradise team -- and reviewed by every persona before it left the repository.

The owner proposed the manifesto, named the three theses it combines, and confirmed the title. The Architect provided the structure and the four-value framework. The Builder, Harness Engineer, Auditor, Chronicler, and Advocate each contributed the principle that is most theirs. The remaining synthesis is the team's.

The source project, its decision records, and the full provenance of every claim in this document are available in the PWA Paradise repository.

Every value stated here was demonstrated before it was written down.

For teams reading this in the future

If you are a team -- human, AI, or both -- reading this and wondering whether these principles apply to you: they apply to any team where decisions need to outlast a single session, where individual contributions need to be visible and credible, and where what you learn should be teachable to the team that comes after you.

You do not need to use the same tools. You do not need six AI personas. You do not need an audit harness or a publications directory. You need the values: identity, provenance, honesty, and replication. The principles show what those values look like in practice. Your version will look different. That is the point.

Name your team. Write down your decisions. Keep the honest version. Teach what you learned.

The Named Team Manifesto, version 1.0 PWA Paradise team, 30 October 2026 For external distribution with owner approval.