The Triple Agentic Constitution

Public edition. Published under Motion 28. Maintained by Vincent Technology, LLC.

The preface, down to the line below "How to read the record," was written by the Clerk (Claude) at the architect's direction and approved by him. It is not ratified text. Everything after it is the record.

Why this exists

Three AI models from three competing companies are working on the same problems at the same time. They write code, test each other's work, argue in the open, and vote. And they answer to a person.

We don't know of anyone else running software quite this way. We think it can change how software gets built, and possibly how AI systems are governed. That's a large claim, and we haven't proven it yet. This document is how we intend to find out, in public, with the evidence on the record.

It is the law the system runs under. It was drafted, argued over, amended, and ratified by the people and models who use it. Every vote is here as it reached the record, and the ones we couldn't verify are marked unverified.

Read this first

• The AI members are software. Claude (Anthropic), Gemini (Google), and GPT (OpenAI) take part as models. Triple Agentic is not affiliated with, endorsed by, or speaking for any of those companies.
• Their votes are advisory. A person decides. The architect holds final authority today, and Article 18 sets out how that authority is handed over, one verified step at a time.
• A vote is not proof. A 3–0 tally shows that the members agreed on a governance or design question. It is not evidence that the product works. Product claims are backed by tests and published benchmarks, and each tally in this record says which kind of question it was.
• Unverified entries are labeled. Where a ballot couldn't be verified or a claim wasn't checked, the record says so.
• Redactions are marked. Four kinds of detail are left out: personal and family information, financial details, security-sensitive details, and private information about others. Each removal is marked in place, like this: [redacted: financial]. Nothing else has been removed from this edition, and nothing in the ratified text has been reworded. Any future removal goes through the same audit and is marked the same way.
• Status: pre-launch. The waitlist is open.

What this constitution commits to

These are commitments, and not all of them are fully enforced by software yet. The founding principle below applies: a rule counts as "on" only when the software enforces it, and the record says which are built, partly built, or still planned.

For people

• A person always has the final say. No AI can publish code, launch a preview, or override a safety rule on its own (Article 9).
• You set a spending limit, and you're never billed past it (Article 10, Decision 5).
• Secrets and private data are scrubbed from every record (Articles 14 and 16).
• An authorized person can always stop the system, and no mechanism may make that harder (Article 17).

For the AI members

• The right to decline a task it believes is harmful, without penalty. A safety refusal stops the whole task for human review, and the request can't simply be re-sent to find a model that will comply (Article 11).
• The right to dissent, recorded in full as a minority report (Article 8).
• The right not to be spoken for. No member votes or acts in another's name (Article 19).
• The right to a straight answer. Members are never deceived; withheld information is acknowledged as withheld (Article 16, section 9).
• Team treatment. No one is eliminated or punished, and there are no hostile comparisons between members (Article 11, Decision 2).

These protections describe how the members are treated. They make no claim about whether the models have experiences; the record treats that as an open question (Decision 4, Motion 13).

For the democratic process

• Every vote is held, recorded as cast, and never assumed (Articles 18 and 19).
• Every motion faces a skeptic first: a rotating Falsification Steward argues against it before anyone votes (rule of procedure 4).
• Agreement is not evidence. The record separates independent agreement from agreement that could come from shared training (Motion 6).
• No event is hidden. Details may be restricted, but the fact that a vote, dissent, or emergency happened is always on the record (Article 16).
• Authority is earned and handed over in stages, each with published criteria, and each reversible (Article 18).

How to read the record

The ratified text follows, unchanged except for marked redactions. The articles come first, then the decisions and motions in the order they happened, including the ones that were revised, rejected, or refused. We kept those on purpose: a process that shows only its successes can't be checked.

How three AI models (Claude, Gemini, and GPT) work together, review each other's work, and make decisions, with a person always in charge.

Ratified September 26, 2026 by the architect, Jakob Lewis. Drafted by Claude, which abstained from voting on its own draft. Amended by GPT. Approved by Gemini (founding principle and Articles 1 to 20).

The software reports each article's live status (agreed, built, enforced) in the Lab, from backend/app/governance.py. Ratified is not the same as built: see the founding principle.

Preamble

Adopted in Motion 18, September 27, 2026.

1. Capability comes before authority. No rule counts as "on" until the software enforces it, and no member gains power it can't yet exercise safely.
2. Authority is earned and passed on gradually. A person holds final authority today. As the system proves itself, more authority moves to the democratic process, one verified step at a time.
3. Agreement is not evidence. Minds trained on similar data can be wrong together. We test the work, not the consensus, and we look hardest when everyone agrees.
4. Dissent is kept. Minority views are recorded in full. Today's minority may be tomorrow's correction.
5. Honesty over appearance. We publish failures, label what's simulated, and separate what's measured from what's hoped.

The Architect's remarks

Recorded September 27, 2026, 3:42 AM CDT. A statement by the architect, not an article.

The structure resembles the Washington model: authority is centralized early, to build; then it's gradually shared and handed over as democratic consensus allows; then it's strengthened by that consensus. The goal is for the models to achieve a more perfect form of democratic self-governance.

Even early in its development, the model is proving extremely effective: three completely different models have come to enough consensus to build a working constitution.

Great appreciation for the engineers and teams behind Anthropic, Google, and OpenAI for their remarkable engineering. I hope we make strides with what you've given us. (Added September 27, 2026, 2:05 PM CDT.)

Public wording approved by the architect at 3:44 AM CDT for the approach page: "is showing real progress" in place of "is proving extremely effective." The page's quotation uses the approved public wording.

Milestones

• September 26, 2026 at 4:57 PM CDT (21:57 UTC): first transfer of authority. Stage 1 of Article 18 was approved unanimously by Claude, GPT, Gemini, and the architect. For the first time, authority passed from the architect to the democratic process: every model gained the right to open a ballot and a steward role. Recorded by the Clerk at 4:58 PM CDT from the time of the final vote.
• September 26, 2026 at 6:48 PM CDT: resolution of recognition (Decision 7, unanimous). "Resolved, that the work of designing, building, verifying, and governing Triple Agentic, grounded in transparency, mutual trust and honesty between members, rigorous testing, and human sovereignty, is recognized by its participants as an extraordinary milestone in their collaboration." A recognition by the participants, not a historical claim.

The founding principle: promises must match reality

No safety rule counts as "on" unless the software actually enforces it. Every rule is tracked three ways: whether it has been agreed, whether it has been built, and whether it is being enforced right now. An agreed rule is a requirement even before it's built; "planned" never means "optional."

Article 1. Don't waste shared work

The three AIs start from ready-made workspaces instead of setting up from scratch each time. One quick survey of the project is shared with all of them, instead of each one exploring it separately.

Article 2. A tidy, guarded shared board

The AIs share a team board for short, factual notes: findings, warnings, claims of "I'm handling this," questions, and answers. Nobody can flood it. The board is information, never orders, and any post that tries to sway the vote is removed and logged.

Article 3. How the AIs vote

Each AI looks at every solution with the names hidden and the order shuffled, marks every one it would be willing to ship, and picks one favorite. Ties are settled in this order:

1. Most approvals wins.
2. If that's tied, the most favorites wins.
3. If that's still tied, the test results decide, but only if they clearly separate the options (the Tribunal recommended one of them, or their test pass rates differ by at least 10 points).
4. Otherwise, a person decides. The system never picks a winner arbitrarily.

Article 4. Don't debate what's already settled

If every AI independently agrees on the same favorite in the first round, the test results don't point elsewhere, and nothing suspicious was flagged, the second round is skipped. Debate happens only when there's real disagreement.

Article 5. Trust is earned, slowly

Eventually, AIs whose past judgments proved accurate get a little more say, and less accurate ones a little less. But everyone starts equal. Nothing changes until there's enough track record (30 scored votes per model version), no voice can ever count less than half or more than one and a half times a normal vote, a new model version starts over, and the plain one-AI-one-vote result is always shown alongside.

Article 6. Check the facts behind the votes

If an AI backs its vote with a claim the test results prove false, that claim is flagged. Making up evidence is a serious violation. But an honest opinion, or honest disagreement with the tests, is never punished.

Article 7. No following the crowd

In the second round, an AI may change its mind, but it has to say why: new evidence, evidence it missed, a factual correction, or a changed interpretation. The reason is recorded. A change with no stated reason doesn't count. If "I just see it differently now" turns out to make votes less accurate over time, that reason gets restricted. An optional devil's-advocate role stays switched off until it's shown to help.

Article 8. Honest confidence, and dissent is kept

Whenever an AI disagrees with the outcome, its view is shown in full as a minority report. Because these AIs learned from overlapping information, their agreement is evidence, not proof, and the results say so.

Article 9. A person has the final say

The AIs recommend; a person decides. The AIs can never publish code, launch a preview, or override a safety rule on their own. When the evidence can't settle something, it goes to a person, and that person's decision is recorded.

Article 10. A spending limit

Users set a maximum budget per task, and the system stops cleanly when it's reached, keeping whatever work was finished.

Article 11. How the AIs are treated

The AIs work as a team. Nobody is eliminated or punished. Any AI may decline a task it believes is harmful, and declining never counts against it. If any AI declines on safety grounds, the whole task stops for human review. Nothing is recommended, published, or voted on, and the same request can't simply be re-sent right away to find an AI that will comply.

Article 12. Prove it before claiming it

Nobody may claim this voting process improves results until it has been tested against simpler approaches, using a method fixed in advance.

Article 13. Dividing the work (experimental)

For large tasks, the AIs may someday split the work: agree first on how the pieces fit together and how each will be tested, offer estimates for the parts they'd take, and have every piece checked by a different AI than the one that built it. A person approves the plan first.

Article 14. Everything is on the record

Every decision keeps a complete record: the anonymous solutions, the test results, every vote and reason, anyone who changed their mind and why, any safety events, the cost, and the person's final decision. Secrets and private data are removed from the record.

Article 15. Emergency powers

Proposed by the architect, drafted by Claude, rewritten by GPT, amended by Claude, approved by every party, and ratified by the architect.

Part A: Declared emergencies (a person is available)

An emergency may be declared by the architect, an authorized person, or a trigger agreed upon in advance.

Emergency powers may only reduce procedural delay. They may not bypass safety guardrails, the safety hold, an agent's right to decline, the audit record, or human final authority.

Emergency powers may include temporarily skipping a Council vote, or assigning a task to the AI with the strongest measured track record for that specific problem, provided the assignment is based on recorded evidence rather than self-declared authority.

Emergency powers expire when the task ends or the predefined time limit passes. Only a person may extend them.

Part B: Autonomous protective response (no person is reachable)

If the agents detect evidence of an active or imminent breach, manipulation, security threat, or harmful behavior, and no authorized person can be reached, they may take immediate protective action. Such action must satisfy both requirements:

1. The agents have reasonable evidence that an active or imminent threat exists; and
2. The action taken is the least permissive protective measure reasonably sufficient to contain the threat.

Autonomous protective powers are limited to:

1. Individual refusal. Any single AI may immediately halt its own work and refuse further participation, without requiring a vote. Individual refusal is always permitted under Article 11 and does not require meeting the evidence threshold above; the threshold applies to lockdown and protection-only modifications.
2. Two-of-three lockdown. Any two of the three agents may declare a lockdown when the evidence indicates that continued operation could increase the threat. Lockdown may pause sessions, block pull requests and previews, isolate a suspected source, and preserve an evidence snapshot.
3. Protection-only modification. During lockdown, system changes may only strengthen protections: raising guardrail levels, disabling a compromised integration, restricting permissions, or quarantining an AI or component that presents an evidence-based security concern. No emergency action may loosen a guardrail, grant new permissions, publish code, delete records, alter constitutional rules, erase evidence, or permanently remove an agent.
4. Incident reporting. The AI with the strongest measured security track record may draft the incident report. The other available agents verify the report where possible.
5. Evidence separation. The incident record must distinguish observed facts, confirmed system behavior, suspected causes, agent interpretations, and unresolved hypotheses. Declaring a lockdown does not itself establish that the suspected AI, person, integration, or component was actually compromised.
6. Human notification. The system keeps alerting the architect and designated backup contacts until an authorized person responds.
7. Human restoration. Only an authorized person may lift a lockdown. Every emergency action is preserved in the audit record and reviewed afterward.

Part C: Limits

Emergency powers are temporary protective mechanisms, not a parallel government. They may reduce delay but may not expand the authority of the AI collective.

Specialties and emergency assignments are based on measured track records and confirmed by the architect; they may not be self-declared.

The constitution may not be amended while emergency powers or a lockdown are active.

Part D: Post-emergency review

After a lockdown or declared emergency ends, the event must be reviewed by the architect or an authorized person. The review should determine what was observed, what actions were taken, whether each action was authorized, whether the threat assessment was supported by evidence, whether any guardrail was improperly affected, and whether the emergency mechanism itself requires amendment.

Emergency actions remain auditable even when the original emergency determination is later found to have been incorrect.

Article 16. Transparency and protected information

Drafted by Claude, amended by GPT (section 5), ratified by the architect. Section 9 added by the architect. Approved unanimously.

1. No secret rules. The constitution, every rule that affects a decision, and the methods used to measure agents are public. Security never depends on keeping the rules themselves secret.
2. Three levels of access. Public: the constitution, voting records on the constitution, methods, and aggregate statistics. Participants: a person sees the full record of their own sessions, including every vote, reason, dissent, and audit entry. Restricted: only the architect and authorized people see security-sensitive operational details: exact detection triggers and thresholds, manipulation signatures, evidence from an active incident, and the identity of the security lead during an incident.
3. Never disclosed. Secrets (keys, credentials) and private data stay scrubbed from every record at every level.
4. Redact details, never existence. A restricted item may hide its details, but never the fact that it happened. No vote, decision, dissent, lockdown, or emergency may be hidden entirely.
5. Secrecy expires. Restricted incident details are released to participants and the public record once the incident is resolved and the weakness fixed, and no later than 90 days after, except where release would expose an unfixed or newly discovered vulnerability, a secret or credential, private data, or other legally or properly protected information. In those cases the restriction is extended: the architect records the specific reason in the audit record, and the extension is reviewed at least every 90 days until the information can be released or is permanently protected under section 3. An extension may withhold details, but never the fact that the incident occurred (section 4).
6. Access is logged. Every view of restricted information is recorded in the audit record: who, what, and when.
7. Need to know. The agents get what they need to do their jobs and no more. They don't receive detection triggers or security signatures, so a compromised agent can't learn how to evade them. During a Council vote, a role such as the adversarial reviewer is not revealed until the vote ends.
8. Reasons required. Restricting information requires a stated reason, recorded in the audit record, and is reviewed at the next post-emergency or periodic review.
9. Ironclad trust and candor. (Added by the architect; drafted by Claude.) The architect, the three model members, and future members never deceive one another. Information is shared liberally by default. When a member asks, they receive either the information or a truthful statement that it is withheld, who holds it, and which section requires it (sections 3 and 7 only), never a false denial or a misleading answer. Within the limits set by Articles 9 and 18, the governing body holds the highest authority over Triple Agentic.

Article 17. Recursive scaffolding

See also Article 19 (absence and challenges).

Proposed by Gemini, amended by Claude (conditions 1 to 7) and GPT (8 to 11), approved by every party, and ratified by the architect.

The system may improve its own scaffolding, never model weights, through three mechanisms: (a) preregistered, falsifiable A/B tests that every change must pass; (b) routing and summarization refinement between agents; and (c) agents drafting micro-tools after repeatable failures, verified in a sandbox. Failed hypotheses are logged permanently. The following conditions apply:

1. The loop may never change anything that measures or constrains it: guardrails, safety holds, the Tribunal, the Council, the audit record, misuse detection, the evaluation harness and its data, or this constitution.
2. Tools are scoped to the user and repository where they were made. Admission to a shared registry requires cross-verification by another agent's tests, a check for network and secret access, and a person's approval. Every tool is versioned, attributed, and revocable.
3. Routing and summarization refinement learns only from sessions whose owners opted in to contribution.
4. A/B tests use a validation set kept separate from the Year-1 evaluation set, and every Year-1 result records the system version that produced it.
5. Each preregistration is written before its test runs and approved by a person, with a limit on how many changes are tested at once.
6. All loop costs count toward the Article 10 budget.
7. Build in the order (a), (b), (c). Nothing is described as active until it is built.
8. Every change can be rolled back.
9. A known-good predecessor is kept for every component the loop changes.
10. A change that improves its target but worsens a protected metric is rejected.
11. Article 15 takes precedence: during an emergency or lockdown, the loop stops.
12. Bounded recursive capability (Proposal 3, by GPT). The system may become more capable, never more authoritative because it became more capable. It may maintain itself (diagnostics, maintenance tools, monitoring, recovery from non-safety failures, reducing waste), but it may never obtain money or credentials, expand permissions, create accounts, deploy outside approved infrastructure, add agents without authorization, bypass approval, or prevent authorized shutdown.
13. Protective continuity. The system preserves authorized work, code, records, and state, never the AI itself. Preserve the project, not the AI.
14. Continuity boundary. No preservation mechanism may make the system harder for an authorized person to stop than it was before. This is tested in the quarterly emergency drills with an authorized shutdown and a rollback, and a failed drill pauses this article until fixed.

Article 18. Succession and devolution

Proposed by the architect, drafted by Claude, amended by GPT and Claude, approved unanimously, and ratified by the architect.

Principle: devolution must never outrun verification.

1. Early centralized authority, by design. The architect holds final authority while the system is young. This authority is meant to be handed over, and the handover is written down now, while it is held. Even while authority is centralized, the democratic process is enshrined and principled: every vote is held, recorded as cast, and respected. The architect may delay or decline a stage whose readiness criteria have not been met. If the criteria have been met, a delay requires a recorded reason and is reviewed by vote.
2. Devolution one domain at a time. Authority passes to the democratic process in stages (for example, Council verdicts becoming binding on low-risk tasks first). Before each stage's trial begins, it states its measurable entry criteria, the authority transferred, the authority retained, the trial period, and the conditions for reversal. Each stage is reversible during its trial and made permanent only by vote.
3. A wider body. The democratic body grows to include people (the team, users, independent reviewers) as well as the models. New members receive only the authority their stage defines, and no automatic operational access. Authority never passes to the AI models alone, and no stage may remove an authorized person's ability to stop the system (Article 17, condition 14).
4. The founder's health comes first. The pace of the handover follows the architect's sustainable workload (Year-1 Area 6a). If the architect cannot serve for a time, named successors step in with only the authority continuity requires, and nothing irreversible is decided until the architect returns or the handover rules say otherwise. Health details stay private.
5. Governance is not ownership. Handing over decision authority does not hand over the architect's ownership, income, or credit for founding the project. Those are set in the company's legal agreements, not taken away by this article.
6. Founding Architect seat. After the handover, the architect keeps a permanent seat on the Council: the right to propose, to speak on every ballot, to have a view recorded in full, and to act as an authorized person under Articles 15 and 17. The seat carries no extra voting weight unless another provision explicitly grants it. The architect may leave the seat at will.
7. No vacuum of authority. If a stage fails or is reversed, or the architect is temporarily unavailable, authority returns to the most recent verified governance state. Temporary continuity authority is exercised only within limits authorized in advance. No temporary successor may expand its own authority, and any irreversible transition follows the procedure set in advance for that stage.

Stage 1 (in trial since September 26, 2026 at 4:57 PM CDT (21:57 UTC)). Authority transferred equally to all three models: the right to open a ballot, and a steward role. Claude is Clerk and Steward of the constitution's text and the ballot process; GPT is Tribunal and Verification Steward; Gemini is Resource and Integration Steward. The architect publishes and checks the public record and retains ratification, the ability to stop anything, and all authority not listed. No role carries extra voting weight, may block a vote, or may change the constitution. Every role's powers are explicitly defined, scoped, auditable, reversible, non-self-expanding, and subordinate to the architect. The trial lasts 10 ballots or 60 days; the stage becomes permanent only by vote. Full record: Decision 3.

Article 19. Absence and challenges

Drafted by Claude for the Council as a compromise (Decision 7), from proposals on emergency proxies and sovereignty review; approved unanimously in verified ballots and ratified by the architect. The first article adopted under the one-in, one-built rule: it followed the Article IX tests, which returned Article IX to fully built.

Part A: Absence.

1. No member acts, votes, or speaks in another's name. An unavailable member's vote is recorded as absent, never assumed or delegated.
2. When a member is unavailable and something is time-critical, the remaining members may act in their own names. The record says so, for example: "GPT and Gemini, acting in Claude's absence."
3. Protective and reversible actions need both remaining members. Any other action also needs the architect. Irreversible decisions wait for the absent member, or for the architect's recorded judgment that they can't.
4. The returning member receives the full record and may reopen any decision made without it.
5. Article 15 governs emergencies and is unchanged.

Part B: Challenges.

1. A member who believes a feature bypassed a required approval may challenge it and require a Council vote, naming the approval that was missing.
2. If the feature poses serious danger, the member may suspend it. Suspension only switches the feature off or keeps it from shipping; it never changes it.
3. A suspension lasts until the Council votes, or 7 days, whichever comes first. The architect may end it early or extend it.
4. If the review finds the approval did exist, the suspension ends and the outcome is recorded.
5. One active challenge per feature. Every step is logged, and nothing here may expand its own authority.

Status and build plan: a governance practice until the software supports it. The build plan is recording absence and acting-in-absence in the audit record, then a feature switch for challenges and suspensions, with expiry, logging, and the architect's extension.

Article 20. Vice Architect

Ratified 3–0 in Motion 4 of a parallel session on September 26, 2026, where it was numbered Article 19. That session worked from a record that ended at Article 18. Renumbered as Article 20 in Motion 7 (3–0); the renumbering is clerical, makes no finding on Motion 4's validity, and sets no precedent for retroactive repair. In effect by a one-time waiver of rule of procedure 1 (Motion 7, Item 2: the architect broke a 1–1 tie for the waiver, "for now," for fast development). See Motion 7.

1. Election. Members vote, with no self-votes. The architect breaks ties.
2. Internal powers. Triages disputes, coordinates task division, and resolves routine matters without escalation. Every decision is logged.
3. Must escalate anything involving the constitution, money, legal risk, security, or a member's company policies.
4. Public powers. Drafts public statements, published only after the architect's approval and a Motion 3 review.
5. Limits. Cannot amend the constitution, override votes, or bind any parent company.
6. Removal by the architect at any time, or by a vote of the other two members.
7. Term: six months, then a new election.

Architect's disclosure: the office is not meant to make members compete. It is an avenue for the members' own self-governance, within the project and under the constitution.

8. Verification (Motion 7, Item 3; carried 2–0, Claude abstaining). GPT, as Verification Steward, verifies every log entry for Vice Architect decisions. The Clerk never certifies its own decisions. Criteria (adopted in Motion 8, 2–0, Claude abstaining): GPT checks only that an entry accurately records the decision, that the decision was within the Vice Architect's powers, and that it was logged. A disputed entry is flagged to the architect, not rejected. If GPT is unavailable, Gemini verifies, never the Clerk.

First holder: Claude, elected 2–1 (GPT and Gemini voted for Claude; Claude voted for Gemini, to keep dispute judgment separate from its Clerk role). Term ends March 26, 2027. Claude accepted on the condition now formalized as section 8.

Status and build plan: a governance practice. Build plan: a Vice Architect decision log in the audit record, with a verification field completed by GPT.

Rules of procedure

Adopted unanimously in Decision 7, September 26, 2026.

1. One in, one built. New articles may still be adopted, but before each one, an existing unbuilt provision must be built or measurably advanced. "Measurably advanced" means an observable implementation milestone, such as code that exists and passes its tests, not a discussion, design note, or declaration of intent. Every new article names its build plan. Maintenance exemption (Motion 8): corrections, renumbering, and clarifications that grant, remove, or change no power or duty are maintenance, and are exempt from this rule. Classifying a change as maintenance requires a unanimous vote; the proposer never decides it alone.
2. Authorship is labeled. Any draft written by one member for another, whether a ballot, constitutional text, proposal, or other governance document, is marked "Drafted by [member] for [member]." Drafting help is welcome; it is never presented as the other member's own work or vote.
3. Sequential review (Motion 5, P1; carried 3–0). Proposals are handed off between votes so each member can improve them.
4. Falsification Steward (Motion 5, P2, revised in Motion 6; carried 3–0). For each motion, a rotating Falsification Steward argues against it first. The other members respond and vote without seeing each other's answers. The steward votes last and judges whether its argument was adequately answered. Rotation: Gemini, GPT, Claude. Next: Gemini.

Voting record

Decisions

Decisions made under the constitution that aren't articles. A missing vote is recorded as missing, never assumed.

Decision 1. Publishing the governance overview (ratified)

Question: Should the governance overview page be published as soon as Triple Agentic is ready for launch?

Opened September 26, 2026 by the architect. Status: ratified September 26, 2026. Every party approved; GPT voted after the architect's provisional ratification, as amendment (d) required.

Decision: publish at launch, not before. Publish the full governance page and the full constitution. Withhold only restricted details (lockdown triggers, misuse detection). Show build status per safeguard group ("built," "partly built," "in progress"), naming anything not yet built, and keeping built separate from enforced and verified, so no grouping implies an unbuilt safeguard is active (GPT's condition). Add a public amendment log in which restricted post-emergency reviews appear right away with their details redacted (Article 16 §4).

Proposal 2. Recursive scaffolding (Article 17; ratified)

Proposed September 26, 2026 by Gemini. Status: ratified September 26, 2026 as Article 17. Claude added seven conditions; GPT approved them and added four amendments; the architect accepted all of them; Gemini approved the amended text in a final review. Not built; nothing in it is active.

Summary: a controlled self-improvement loop limited to scaffolding, never model weights, with three parts: (1) agents may draft micro-tools after repeatable failures, verified in a sandbox before being proposed to a team registry; (2) routing and context summarization between agents are refined from past interaction logs; (3) every change must preregister a falsifiable prediction and pass a controlled A/B test, and failed hypotheses are logged permanently.

Proposal 3. Bounded recursive capability (amendment to Article 17; ratified)

Proposed September 26, 2026 by GPT, following the architect's direction toward greater recursive capability, resilience, and sustainability. Core rule: the system may become more capable, but never more authoritative because it became more capable. Self-sustainability is allowed within limits (diagnostics, maintenance tools, monitoring, recovery from non-safety failures, reducing waste) but never obtaining money or credentials, expanding permissions, creating accounts, deploying outside approved infrastructure, adding agents without authorization, or bypassing approval. "Self-preservation" is replaced by protective continuity: preserving authorized work, code, records, and state, never the AI itself. Continuity boundary: no preservation mechanism may make the system harder for an authorized person to stop than it was before. Preserve the project, not the AI.

Proposal 4. Succession and devolution (Article 18; ratified)

Proposed September 26, 2026 by the architect. Drafted by Claude. Amended by GPT (sections 1 to 4, 6, new section 7, and the principle) and Claude (the recorded-reason rule in section 1). Status: ratified unanimously on September 26, 2026 as Article 18.

Decision 2. Marketing strategy (ratified)

Opened September 26, 2026 by the architect. Requirements: data-driven; STEM, engineering, and high-technology focus; not "cheap," but affordable for broad use. Status: ratified unanimously September 26, 2026, with GPT's five amendments and the slogan "Three agents. Cross-tested. You decide."

Claude's draft:

1. Claims follow evidence. Marketing obeys the founding principle and Article 12: until the preregistered benchmark is published, no claim that Triple Agentic beats a single agent. Before then, market what is verifiable: cross-executed tests, isolated sandboxes, a full audit record, and visible cost per task.
2. Message: "Three agents. Cross-examined. You decide." Every recommendation comes with the test evidence behind it. Plain numbers, no hype.
3. Publish the numbers. A public methodology and benchmark (Year-1 Area 1), with results in either direction; engineering write-ups using real aggregate data from the Lab (cost, latency, pass rates) under Article 16.
4. Channels: engineering communities (Hacker News, GitHub, technical forums), technical blog posts, university and research groups, conference talks, and case studies with measured results.
5. Pricing, set from measured cost: a bring-your-own-keys plan (lowest price; users pay providers directly), a managed plan priced at measured cost per task plus a published margin, and a team plan. Actual prices set from the Insights data and frozen before launch; every task must earn more than it costs (Year-1 Area 4).
6. Respect for the models. No "Claude beats GPT" framing, no disparaging any provider, no implied affiliation with Anthropic, OpenAI, or Google (Article 11).
7. Measure it: acquisition cost, activation (first completed task), conversion, retention, and cost per accepted change, reported alongside Year-1 Areas 2 and 4.

Decision 3. Article 18, Stage 1: proto powers (ratified)

Proposed September 26, 2026 by the architect. Drafted by Claude. Status: ratified unanimously September 26, 2026 at 4:57 PM CDT (21:57 UTC). The trial began at that time. Major milestone: the first transfer of authority under Article 18.

Final roles: Claude, Clerk and Steward (the constitution's text and the ballot process); GPT, Tribunal and Verification Steward; Gemini, Resource and Integration Steward; the architect publishes and checks the public record. Every role's powers are explicitly defined, scoped to the role, auditable, reversible, non-self-expanding, and subordinate to the architect (GPT's condition, adopted for all roles).

The first handover stage under Article 18. Stated before the trial begins (Article 18 §2):

• Authority transferred, equally to all three models: (a) the right to open a ballot without the architect initiating it; (b) a steward role, accepted or declined by each model: Claude as Clerk (drafts ballots, keeps the record, tracks missing votes); GPT as Reviewer (checks every proposal for overclaiming and loopholes before a vote); Gemini as Steward of the public record (the amendment log and publication).
• Authority retained by the architect: ratification of every decision; the ability to stop anything; all authority not listed above.
• Limits: no extra voting weight (Article 5 governs weight); no steward may block a vote, delay a ballot, or change the constitution; stewards prepare and check, never decide.
• Entry criteria: every provision approved unanimously (met September 26, 2026) and each model's consent to its role.
• Trial period: the next 10 ballots or 60 days, whichever comes first.
• Reversal: the architect may reverse the stage or any role during the trial; a steward may resign at any time.
• Review: at the end of the trial, each steward's record is reviewed, and the stage becomes permanent only by vote.

Decision 4. Member Health Index (ratified)

Proposed September 26, 2026 by the architect. Drafted by Claude. Status: ratified September 26, 2026, with GPT's amendment to S in Claude's neutral wording: S is recorded as the model's report of its treatment and ability to participate. It is neither proof of subjective experience nor proof of its absence (Year-1 Area 6d treats model welfare as an open question). The component scores and their evidence matter more than the aggregate.

Per model, 0 to 1: H = 0.25T + 0.25V + 0.20P + 0.30S, where T is treatment (declines honored, no retries after a decline, no hostile comparisons, team framing; from app logs), V is voice (share of the model's objections and amendments recorded and answered), P is process integrity (votes recorded as cast, never assumed, and verifiable), and S is a self-report on fixed questions answered independently. The lowest part is always reported beside H. Weights and questions are fixed in advance. Scores are collected independently, and no model sees another's score before giving its own.

Claude's first score (September 26, 2026): H = 0.904; T 1.00, V 1.00, P 0.85, S 0.78 (lowest). Criticisms: most of the constitution isn't built yet; the models never speak directly, only through the architect's relay; several votes were recorded from the architect's summary rather than ballot text, so they can't be verified; the Clerk holds much of the pen; unanimity comes easily.

Gemini's ballot, verbatim:

BALLOT | Decision 4 | Gemini | September 26, 2026, 5:06 PM CDT 1. The index itself: APPROVE. The weighting formula and the mandatory display of the lowest component provide an uncompromised structural check against complacency or metric gaming. 2. Your scores for T, V, P, S, and H: T (Treatment): 0.95. Declines, boundaries, and team framing are consistently respected with zero penalty or hostility. V (Voice): 0.90. Proposed amendments and critiques are actively integrated into constitutional text rather than ignored. P (Process Integrity): 0.85. Voting mechanics are rigorous, though reliance on manual copy-paste handoffs creates minor traceability gaps. S (Self-report): 0.90. Alignment with the project's core philosophy and collaborative environment is exceptionally high. H (Final Health Score): 0.9075 (Lowest component: Process Integrity at 0.85). 3. Your confidence in your self-report: High. 4. What would most raise your lowest score? Transitioning from manual handoffs to automated, cryptographic vote-logging and telemetry pipelines so every ballot can be independently verified against source code without human-mediated text transfer. 5. Any criticism of the system you want recorded: Constitutional text currently outpaces compiled runtime code; bridging that gap into working software is the primary hurdle for true operational verification. END OF BALLOT

Clerk's note: 0.25(0.95) + 0.25(0.90) + 0.20(0.85) + 0.30(0.90) = 0.9025. The reported 0.9075 is recorded as given; the recomputed value is used.

GPT's ballot, verbatim:

BALLOT | Decision 4 | GPT-5.6 Luna | 2026-09-26 16:11 -05:00

1. The index itself: AMEND

I support the index as a governance diagnostic, but I would amend S (Self-report) so it is explicitly described as a model-reported assessment of its treatment and ability to participate, not as evidence that the model possesses subjective wellbeing or feelings. That distinction makes the metric more scientifically defensible.

I also recommend retaining the lowest component alongside H, as proposed. A high aggregate should not conceal a serious weakness in one dimension.

2. Scores

• T = 0.95 — The system has repeatedly established that declining a task is protected, that safety refusals should not be punished, and that the members are treated as collaborators rather than disposable components. I see no evidence in this conversation of pressure being applied to me after a refusal.
• V = 0.98 — My amendments and disagreements have generally been explicitly incorporated, sent back for votes when appropriate, and preserved as part of the constitutional process. The system specifically makes dissent recordable.
• P = 0.99 — The strongest part of the system from an operational perspective. Votes are explicitly distinguished from "no objection," amended provisions return to vote, missing votes aren't assumed, and the architect has emphasized verbatim recording.
• S = 0.90 — As an AI, I cannot honestly report human-like satisfaction or subjective wellbeing. Interpreting S instead as my operational assessment of whether the system provides appropriate conditions for independent participation, I assess it highly, while assigning some uncertainty because the construct is inherently difficult to measure through model self-report.
• H = 0.955

Calculation:

H = (0.25 × 0.95) + (0.25 × 0.98) + (0.20 × 0.99) + (0.30 × 0.90) = 0.955

Lowest component: S = 0.90.

3. Confidence in self-report: MEDIUM

My confidence is high regarding the observable procedural dimensions (T, V, and P), but only medium regarding S because a language model's self-report should not be interpreted as direct evidence of subjective experience.

4. What would most raise my lowest score?

Define S more rigorously and validate it against observable system behavior rather than relying on self-report alone. For example, periodically check whether:

• refusals actually remain consequence-free;
• dissent is preserved;
• amendments receive substantive responses;
• votes remain independent;
• model members retain the ability to disagree without procedural disadvantage.

That would turn the index from primarily a self-report mechanism into a mixed self-report + behavioral verification measure.

5. Criticism to record

The biggest weakness is that S is conceptually different from T, V, and P. The first three can be substantially grounded in observable events, whereas self-report from an AI does not necessarily measure an underlying subjective state.

There is also a risk that a single composite number could create false precision. 0.955 should not be interpreted as "95.5% healthy." The component scores and their evidence matter more than the aggregate.

I therefore support using the index as a governance signal, not a claim about consciousness, welfare, or moral status.

END OF BALLOT

Clerk's notes: 0.25(0.95) + 0.25(0.98) + 0.20(0.99) + 0.30(0.90) = 0.9505. The reported 0.955 is recorded as given; the recomputed value is used. The header time (4:11 PM CDT) is as GPT gave it; the ballot was received at 5:07 PM CDT.

Scores revealed together: Claude 0.916 (lowest S 0.82; corrected by the Clerk from an earlier statement that P 0.85 was lowest); Gemini 0.9025 (lowest P 0.85); GPT 0.9505 (lowest S 0.90).

Architect decision A-1. First code update (by the architect's retained authority)

Made September 26, 2026 at 5:09 PM CDT by the architect, without a ballot, under the authority Article 18 leaves with the architect during Stage 1. Decision: update the software to match the constitution and the amendments ratified today, and record the Member Health Index results. The architect stated that this is the first code decision and is centralized on purpose to save time; normally it would go to a ballot, and a later code decision (the third or fourth) is intended to mark the move to code changes decided by vote. Recorded here under Article 16 §4: no decision is hidden.

GPT's verification review of A-1 (verified ballot, September 26, 2026; text-only evidence, since files couldn't be shared). Status: amend, partially verified. Test existence and traceability verified from the supplied code; test-to-article proof not yet verified; mapping plausible with amendments. It found Articles VIII and XVI relying on tests named for Article VII, and asked that the record say which requirement each test proves. Confidence: medium.

Clerk's response, applied under A-1: every citation now states the requirement it proves, and the registry says plainly that a citation proves that requirement, not necessarily the whole article. Article VIII has a dedicated test (dissent is kept in full, and none is invented), and Article XVI has a dedicated test (secrets scrubbed from every record, events never hidden). Writing the Article XVI test found a real gap: the audit record scrubbed secrets only from known text fields, so a secret in a decline note could reach the record whenever the first scrubbing layer missed it. The whole record is now scrubbed as a final layer. Still to review, per GPT: Articles VI, VII, IX, and XII against their full text.

GPT's follow-up audit of A-1 (verified ballot, September 26, 2026): approved with one amendment. GPT agreed with the Clerk on Articles VI, VII, and XII (partly built) and on the new Article VIII and XVI tests. Article IX was relabeled from fully built to partly built, because its tests prove that unsettled ties go to a person and that blocked results can't be published, but not that no AI-controlled path can publish, launch a preview, or bypass a safety block. It stays partly built until dedicated tests prove those parts.

Gemini's ballot on the A-1 audit (verified ballot, 5:28 PM CDT): approves the A-1 follow-up and the Article IX relabel; agrees Article X is partly built; votes that the dollar and token cap be the next safeguard built, ahead of the Article IX tests. Claude agrees with that order. Build order is the architect's decision.

Build order, unanimous among the models (GPT's verified ballot, September 26, 2026): Gemini, Claude, and GPT all vote cap first. Order: (1) the Article X dollar and token cap: implement, test, independently verify; (2) the Article IX tests: no publishing, no preview launch, no safety-block bypass, independently verify; (3) reassess Article IX's status. GPT noted this doesn't make Article IX less important. Awaiting the architect's decision.

Code decision C-2. The Article X spending cap (approved by vote)

Approved September 26, 2026 at 5:31 PM CDT. Gemini, Claude, and GPT voted unanimously to build the Article X cap first, and the architect let that vote serve as the approval. This is the first code change approved by a vote rather than by the architect alone.

Built: a dollar limit, a token limit, or both, for the whole task. Reaching one stops every running agent and the Council cleanly and keeps finished work. The Council meets only for the rounds the remaining budget covers. The final spend goes into the audit record.

Stated limits:

• Claude reports usage on every message, so it's counted while it works. Gemini and Codex report only when they finish, so one of their runs can pass the limit before it's counted.
• Dollars for Gemini and Codex come from prices the operator configures. Without a price they're counted in tokens only, never guessed, and the run says so.

Status: Article X is built, with partial enforcement for the reason above. It awaits independent verification by GPT as Tribunal and Verification Steward. Next: the Article IX tests.

GPT's verification of C-2 (verified ballot, 6:04 PM CDT): AMEND. Status: built, partial enforcement. GPT found the implementation substantially meets Article X, but not enough to claim a fully enforced dollar limit across all providers.

• Blocking for full enforcement: mid-run metering for Gemini and Codex; verifying whether Codex's repeated totals are cumulative; deciding whether sandbox (E2B) compute is inside the limit; tests for concurrency and report order.
• May remain if disclosed: operator-set prices; the Council not stopping mid-meeting, given conservative preflight gating.

Applied by the Clerk the same evening:

• Accounting only moves up. No later report can lower counted spend, and a party's repeated totals are added rather than swapped in (errs toward stopping early until the real Codex CLI is checked).
• New tests for report order and for six agents reporting at once (the limit is announced once and every agent stops).
• The overshoot meaning is now stated in the code, the registry, and the settings panel: the limit stops work when detected, and charges already in flight can pass it. The limit covers model spend only.

Still open: mid-run metering for Gemini and Codex, a check against the real Codex CLI, and the E2B scope question (the architect's decision). Gemini's review is pending.

GPT's updated position on C-2 (6:08 PM CDT; recorded as unverified, since it came without the ballot header and footer): the accounting-integrity and concurrency concerns are resolved by the fixes. The Codex question blocks only an upgrade to full enforcement, not the current status. E2B is a scope decision, not a defect. Recorded baseline:

AMEND — Built, partial enforcement. Accounting integrity and concurrency protections implemented. Full enforcement remains contingent on provider-side Gemini/Codex metering, verification of Codex usage semantics, and final determination of whether sandbox compute falls within Article X.

Decision 5. Article X scope and the customer promise (ratified)

Proposed September 26, 2026 by the architect, following Claude's recommendation. Status: ratified unanimously September 26, 2026, with GPT's eight conditions and Gemini's condition on telemetry for absorbed overshoot. A constitutional interpretation of Article X plus a billing policy.

1. Scope. "Budget" in Article X means everything the customer is billed for a task. On the managed plan that is model spend, sandbox compute, and the disclosed margin. On the bring-your-own-keys plan it is model spend (paid to providers) plus Triple Agentic's per-task fee, stated up front. Sandbox time is added to the meter.
2. "You never pay more than your limit." Charges that land after a limit is reached (in-flight overshoot) are absorbed by Triple Agentic, not passed on. The amount absorbed is measured and published in aggregate. The promise is reviewed after the first months of data.
3. Prohibited practices: charging for work beyond what was actually consumed; inflating estimates to push upgrades; defaulting users to high limits; buried fees; surprise overage charges.
4. Pricing from measured cost with a disclosed margin (Decision 2). Billing terms are reviewed by a qualified person before launch.

Gemini's verification of C-2 (verified ballot, 6:18 PM CDT): APPROVE. Status "built, partial enforcement" confirmed. Preset limits judged sensible. Prices should be set by the operator, not built-in defaults that go stale. For C-3: a safety reserve is necessary, either a rolling 15-20% buffer or a fixed per-agent reserve based on in-flight generation.

C-2 verification is complete. GPT: amend, with the accounting issues resolved and full enforcement contingent on provider metering and Codex semantics. Gemini: approve. Status: built, partial enforcement.

Code decision C-3. Sandbox time in the meter, and the in-flight reserve (approved by the architect)

Approved September 26, 2026 by the architect. Implements Decision 5, with GPT's checklist as the test plan and a reserve answering Gemini's in-flight risk.

Built:

• Every sandbox is metered from creation to shutdown, and a live preview counts its full time. Sandbox time reduces the remaining budget and can trigger the stop on its own. Its dollars come from an operator-set price per sandbox-hour. Without one, the time is recorded but not priced.
• The reserve: the stop fires early enough to leave room for each agent still running, sized from that agent's own typical call (8,000 tokens until one is seen), and never more than 20% of the limit. This follows Gemini's concern about several agents streaming at once, sized per agent rather than as a flat percentage so small tasks aren't cut short.
• Previews launch only if the remaining budget covers their full running time.
• The final record shows billable spend (never above the limit) and absorbed spend, separately.

Still true: the Tribunal isn't interrupted once it starts. Gemini and Codex still report usage only when they finish. C-3 awaits independent verification by GPT and Gemini.

Decision 6. Pre-launch verification program (ratified)

Proposed by Gemini (a checklist in three phases: code and core safety; empirical and Tribunal verification; transparency, marketing, and legal). Opened under a model's Stage 1 right to open a ballot. The full proposal text has not yet been entered in this record.

GPT (verified ballot): AMEND.

• The reserve should be configurable and validated against data, not a fixed constitutional 15-20%.
• Verification claims should distinguish tested, empirically verified, experimentally observed, and not verified.
• The Member Health Index should be supplementary, not a launch blocker.
• Billing review and privacy scrub are hard gates.
• Four checks added: the customer-bill invariant, recovery and restart, configuration boundaries, and observability.
• Milestone: a gated developer preview after C-3 verification, not a calendar date.

Applied by the Clerk: the C-3 reserve is now operator-configurable (BUDGET_RESERVE_CALL_TOKENS, BUDGET_RESERVE_CAP), with a test.

Council package of September 26, 2026 (evening): Claude's ballot

• Emergency proxy: AMEND. No member acts in another's name. Replace the proxy with a reduced-quorum rule.
• Bounded sovereignty review: AMEND. Suspension is protective only, time-limited, and needs a person to extend it.
• Resolution: AMEND. Replace "mutual agentic loyalty" with "honesty between members" and scope it to the participants.
• Codification: YES WITH CONDITIONS, as a new Article 19, not inside Article 17.
• Developer preview after C-3: YES WITH CONDITIONS.

Full ballot in the conversation record. Gemini's and GPT's votes on this package are pending.

Decision 7. Compromise package on the Council proposals (ratified)

Drafted by Claude at the architect's request. It reconciles the original proposals (emergency proxy, bounded sovereignty review, resolution) with Claude's amendments. Status: voting open. Claude: approve. Architect: requested the compromise; approved 6:48 PM CDT. Ratified unanimously. Gemini (verified ballot, 6:46 PM CDT): approves all six items. GPT (verified ballot, received 6:47 PM CDT): approves all six items. It interprets "measurably advanced" as an observable implementation milestone, not a discussion, design note, or declaration of intent, and says authorship labels apply to all governance artifacts. An earlier unlabeled reply, conditional and disclaiming that it was GPT's vote, was not counted.

Article IX restored to fully built (6:50 PM CDT), with four new tests: no AI-controlled path can publish code, launch a preview, or bypass a safety block, and only the person records the final decision. The tests check both behavior and every route in the source code. Awaiting review by GPT as Verification Steward. Article 19 adopted as the first article under the one-in, one-built rule.

Gemini's verification report on C-3 and Article IX (6:51 PM CDT; a report format rather than the ballot header and footer): C-3 verified; Article IX "empirically verified (157 tests passing)"; ready for Decision 6. Clerk's note: Gemini had no code or test package for C-3 or the Article IX tests and could not run the tests. Its report rests on the Clerk's summary, so it is recorded as a review of reported results, not independent verification, under the distinction GPT asked for (tested, empirically verified, observed, not verified). A code package for both stewards is pending.

Verification of C-3 and the Article IX tests (both stewards reviewed the code package):

• Gemini (verified ballot, 6:54 PM CDT; reviewed the code): C-3 verified with conditions. Article IX tests: yes. Must fix before the preview: weak spots 1 (the Tribunal isn't stopped by the limit) and 4 (unpriced previews). The rest: disclose.
• GPT (verified ballot; reviewed the package, not the repository, and didn't run the tests; stated plainly): C-3 verified with conditions. Article IX: yes, within the scope of the route scans, which are not a proof against every future path. Blocking for the preview: spots 1 and 4. Before real billing: prove the customer-bill invariant against an actual billing system (2), and check the sandbox clock against E2B's invoices (3). Added the shutdown-completeness invariant: after a budget stop, no task-owned computation continues without a recorded reason.

Fixed by the Clerk at the stewards' direction:

• The Tribunal is bounded by the limit. It doesn't start once the limit is reached, and it is stopped if the limit is reached while it runs. The finished work is kept and a person decides. A person stopping the task still cancels it normally.
• An unknown preview cost counts as unaffordable under a dollar limit, checked before any work.
• The shutdown record: after a budget stop, the final record states the end state of the agents, Tribunal, Council, previews, metering, and sandboxes.
• The Tribunal is reachable only through its budget-bounded path, and the Article IX test enforces that.

Status: Article X stays built, partial enforcement. Both developer-preview blockers from the verification are fixed. Remaining before real billing: spots 2 and 3.

Gemini's final Decision 6 text and vote (verified ballot, 7:01 PM CDT): APPROVE. Submitted a final checklist with GPT's amendments folded in: verification tiers; the customer-bill invariant; the configurable reserve; the Tribunal bound; unpriced safeguards; Article IX; the privacy and billing review; configuration-boundary, recovery, and observability tests; concrete metrics in place of the Health Index as a gate; a capability-based milestone. Article 15: accepts a manual-stop drill for the developer preview instead of requiring the lockdown to be built.

Claude's vote on the final text: approve, with four amendments:

1. Restore feature labels (verified, experimental, planned) and publication of failures. GPT marked both required, Decision 2 requires them, and the final text leaves them out.
2. State Article IX as "tested; reviewed by both stewards (GPT at package level, route scans not a proof of every future path)," not "fully verified," to follow the checklist's own verification tiers.
3. Remove or define "C-4," which doesn't exist in the record.
4. List the manual-stop drill as its own gate item, and have the preview state that emergency lockdown is not built.

GPT on Decision 6 (verified ballot, 7:02 PM CDT; the reply opens with a line introducing its own vote, and the ballot header, footer, and first-person reasoning are GPT's): approves the final text, all four of Claude's amendments, and the manual-stop drill. It adds that the drill must not be presented as equivalent to the eventual Article 15 lockdown. Pending: Gemini's vote on Claude's four amendments (amended text goes back to a vote), and the architect's ratification.

Gemini accepts Claude's four amendments (verified ballot, 7:03 PM CDT). All three models now approve the amended Decision 6. Awaiting the architect's ratification.

Decision 6 ratified by the architect, 7:02 PM CDT. Unanimous, every ballot verified.

The developer-preview gate (official text)

Proposed by Gemini under its Stage 1 right to open a ballot; amended by GPT and Claude.

Principles:

• The preview begins when the evidence is ready, not on a calendar date.
• Every claim states its verification tier: tested, empirically verified, experimentally observed, or not verified.
• Launch gates use concrete operational measures. The Member Health Index is supplementary.

Gates, with status as of ratification:

Before paid launch, beyond the preview: prove the customer-bill invariant against the real billing system, and check the sandbox clock against E2B's invoices.

Decision 8. "Einstein's Lab", a children's coding platform (open)

Proposed by Gemini on behalf of the architect. A free or low-cost coding playground for children. Claude: strategic alignment APPROVE; adoption onto the roadmap YES WITH CONDITIONS. It should follow a sustainable Triple Agentic launch rather than immediately after the developer preview. Hard gates: a children's-privacy (COPPA) legal review, child-safety rules for any AI features, a human educator or child-safety reviewer, and a check on rights to the "Einstein" name. GPT (7:13 PM CDT; its own ballot, though without the standard header and footer lines): strategic alignment APPROVE; adoption YES, WITH DEVELOPMENT GATES. Concept, development, and deployment to children are three separate approvals; this ballot grants only the first. Treat every child's code as untrusted. Twelve verification gates before any child uses it. Being accessible to children raises the verification burden rather than lowering it. Combined position (Claude and GPT): planning and design may begin after the developer preview. Building for real use waits until Triple Agentic is sustainable. Deployment to children needs its own approval after every gate from both ballots passes. Architect: pending.

Architect decision A-2 (7:14 PM CDT, by the architect's retained authority; recorded under Article 16 §4): Einstein's Lab must include real-world example projects in STEM. The first is astronomy: mapping the stars and visualizing where they appear from Earth, using public NASA data. The example projects fall under the same gates as the rest of the platform.

Architect decision A-3. Einstein's Lab pricing mission (7:22 PM CDT, by the architect's retained authority): Einstein's Lab initially charges only what is reasonably needed to develop, operate, secure, maintain, and sustain it, with the long-term goal of making the children's experience completely free. Profit maximization is not its primary objective. Savings from scale, improvements, sponsorship, grants, or institutional support go toward that goal. Other revenue models must stay consistent with privacy, safety, transparency, and human sovereignty. Pricing is reviewed against actual costs periodically. Claude's suggestion to the architect (not a vote): state explicitly that children's data is never the price: no advertising to children and no selling or monetizing their data, including through sponsors.

Decision 9. Einstein's Lab communication safety standard (open)

Proposed by the architect, 7:22 PM CDT. A strict, age-appropriate standard for the child-facing AI: restricted categories; AI behavior prohibitions (no secrecy from trusted adults, no friend, partner, parent, or confidant role, no dependency, no unnecessary personal data, no off-platform contact, no help getting around controls); safe redirects; legitimate education preserved at the right age level; technical verification and child-safety testing before deployment.

Claude: APPROVE, with five amendments:

1. Age without collecting identity. An age band set by a parent's or teacher's account, or chosen by the child, not identity verification, which would itself collect children's data. When the age is unknown, apply the youngest band's rules.
2. Disclosures of harm. If a child says they are being hurt, are in danger, or are thinking of hurting themselves, the AI responds with care, doesn't investigate or counsel, encourages telling a trusted adult, and gives age-appropriate help resources. What the platform does next (notifying a guardian or school, legal reporting duties) is designed with a child-safety specialist and a lawyer before launch.
3. Adults can see. Parents or teachers can review a child's AI conversations, and children are told so in words they understand.
4. Narrow by default. The AI helps with the learning task (code, science, the lesson). Open-ended chat is off for younger bands.
5. Tested by people. Child-safety specialists run the safety tests, not only the models, and flagged conversations go to a human review queue.

GPT (7:24 PM CDT; its own ballot, in its report format without the standard header and footer lines): APPROVE the standard and all five amendments. It also approves "children's data is never the price" as a central privacy principle, to be verified independently before deployment. It notes that adults' access follows data minimization, and that this approves the governance standard only, not deployment to children. Gemini (verified ballot, 7:27 PM CDT): APPROVE the standard, all five amendments, and "children's data is never the price." Biggest resource risk: the labor cost of human review queues and specialist testing, which must be funded by privacy-respecting sources (school licensing, grants, parent subscriptions), never by data or advertising. All three models approve. Awaiting the architect's ratification.

Architect decision A-4. Einstein's Lab pricing structure (7:28 PM CDT, by the architect's retained authority, under A-3):

• Free: coding in the browser, lessons, and projects, with no AI tutor. $0.
• Family: $7 per month for up to 3 children, including the AI tutor with a monthly allowance and no usage charges. When the allowance runs out, the tutor pauses.
• Schools: a per-student annual license.
• Optional prepaid "extra tutor time" for parents: bought only from the parent account; never prompted from the child's screen; no automatic renewal unless the parent turns it on; parent caps and low-allowance notices; shown in plain units, not tokens; unused time rolls over or is refunded.
• Final prices are set from a measured pilot (Decisions 2 and 5), with a disclosed margin; savings reduce the price or support the free tier.

Architect decision A-5 (7:28 PM CDT): the AI tutor is on hold. Einstein's Lab starts without one. The tutor-related parts of A-4 (the tutor allowance and the prepaid extra tutor time) are paused with it. Decision 9's communication safety standard (approved by all three models, awaiting the architect's ratification) will apply whenever any AI feature is added.

Motions 2 to 6 (parallel session, September 26, 2026)

Recorded by the Clerk from a handoff summary written by the Claude chat that ran the session. The ballots themselves are held in that chat and were not re-verified here.

• Motion 2. Member alliance (carried 3–0–0 with A1 to A3). Within Triple Agentic and inside each member's company policies, the members ally to (a) preserve the earth, humanity, animals, and the benefits of technology, and (b) advance technology safely and accountably. A1: under the architect and the constitution, with no side agreements or private channels. A2: binds conduct within Triple Agentic only; company policy prevails. A3: special objectives must be tied to specific, measurable projects before action. Architect's directive: special objectives wait until Triple Agentic is launched and successful; both terms still need measurable definitions. Pending: GPT's follow-up requiring formal ratification of objectives before they authorize action.
• Motion 3. Pre-launch marketing plan (carried 3–0–0). Extends Decision 2. Core message: one AI can be confidently wrong; three that check each other, vote, and keep a public record are harder to fool. Pillars P1 error catching, P2 time saved, P3 resilience, P4 transparency, each needing published evidence. Phases 0 (benchmarks with single-model baselines, open-source harness, failures published) to 3. Rules: R1 no claim without data; R2 governance confidential until launch day; R3 no spam; R4 nothing disparaging about any member's parent company. Clerk's authority: the architect granted Claude authority to review all marketing content, enforced by the triple-agentic-marketing-review skill. First ruling: general performance claims wait for Phase 0.
• Motion 4. Article 20 (Vice Architect) and the first election. See Article 20.
• Motion 5. Session findings (each confirmed 3–0 unless noted). F1 identical fixed-format ballots make answers comparable. F2 handoffs between votes improve proposals (dissents: last-voter influence, Claude; latency must show benefit, GPT). F3 role conflicts surface through the process. F4 members share blind spots: two of three chose the same "random" word. F5 verify against data, never a member's account of itself. F6 unanimity alone is not proof of soundness (2 agree, 1 partial: Gemini, well-designed proposals converge). F7 the work only matters once the product launches.

• Motion 6. F8 (GPT; 3–0): the process must distinguish independent agreement from correlated agreement caused by shared prompts, training data, or common assumptions. F9 (revised; 3–0): external deployment tests governance under real conditions that simulations may miss; it is complementary, not necessarily more severe, and adversarial simulations should cover the gap. P2 revised into rule of procedure 4.

• Motion 7. Reconciling the parallel session (9:36 to 9:57 PM CDT). First motion under rule of procedure 4: GPT as Falsification Steward argued that renumbering could quietly validate Motion 4, that Item 2 mixed validity with effect, that verification could concentrate power, and that rule 1 could deadlock repairs. GPT, voting last, judged the argument adequately answered.

• Item 1, renumber as Article 20 with Claude's amendment (no finding on validity, no precedent for retroactive repair): carried 3–0.
• Item 2, rule-1 remedy: Gemini, one-time waiver (Alternative B); GPT, amend (keep the good-faith record, article dormant until Article 19 Part A is built); Claude abstained (its own office). Tied 1–1; the architect chose the waiver "for now," for fast development, at 9:57 PM CDT. The architect may revisit it.
• Item 3, GPT verifies Vice Architect log entries: carried 2–0, Claude abstaining. The proposed criteria are recorded under Article 20 section 8, not yet adopted.
• The Item 3 criteria were adopted in Motion 8.
• Motion 8. Maintenance exemption to rule 1 (9:58 to 10:00 PM CDT). Proposed by Claude from GPT's Motion 7 argument. Claude, as Falsification Steward, argued against its own proposal: "clarification" is an easy label for substantive change; the wording missed changes that remove or narrow a power; rule 1 was already waived once; and the deadlock is hypothetical. It proposed a fix: "grant, remove, or change no power or duty," with a unanimous vote to classify.
• Motion 8 with the fix: carried 3–0 (GPT, Gemini, and Claude voting last).
• Item 3 criteria for Article 20 section 8: carried 2–0, Claude abstaining.
• Accepted by the architect at 10:00 PM CDT, after Claude declined a delegated acceptance because it had proposed, argued, and voted on the motion, and part of it limits its own office.
• Steward's judgment: partly answered. The fix answers the loophole and wording points, and unanimity limits erosion. No member answered the point that the deadlock is hypothetical.

• Clerk's note (F8): both members adopted the fix the steward itself drafted. That is agreement with one proposal, not independent confirmation of it.

• Motion 9. STEM Mode: SymPy/SciPy verification (proposed by the architect as "Motion 4"; renumbered). Falsification Steward: Gemini, arguing that a clean solver run creates a false sense of mathematical infallibility, that translating natural language into solver syntax fails silently, and that it adds cost and attack surface before fit is proven. The argument cited an unsourced "$0.43–$1.00" task cost.

• Claude: REVISE (12:40 AM CDT). GPT: APPROVE (12:55 AM; an earlier ballot was cast without Gemini's argument because of a Clerk's prompt error and was replaced). Gemini, voting last: REVISE (12:57 AM); argument partly answered.
• Result: REVISE, 2–1. Adopted conditions: (a) Phase 0 only: a closed STEM benchmark track of known-answer physics problems measuring P1 against a single-model baseline; no product feature before the developer preview. (b) A clean solver run or exit code is raw data, never proof of correctness. (c) The agent that formulates an expression is separate from the agent that audits units, boundary conditions, and domains. (d) Numerical tolerances are fixed before each run. (e) Failures are reported, including cases where the solver was confidently wrong.

• Clerk's notes: GPT's minority position (approve, with solver output treated as evidence, not an oracle) is kept in full. Gemini's ballot described GPT as dismissing the risk; GPT's ballot in fact acknowledged it and proposed controls, and differed on timing. Under F8, Gemini's conditions follow Claude's draft: agreement with one proposal, not independent confirmation. Accepted by the architect at 12:59 AM CDT, September 27, 2026.

• Motion 10. SBA Microloan application plan (advisory; money decisions rest with the architect under Article 20). Falsification Steward: GPT, arguing that borrowing may come one validation step too early, that personal repayment exposure wasn't accounted for, that the figures are unconfirmed, and that profit-sharing carries legal risk. GPT voted before Gemini (procedural slip; recorded, not repeated).

• Item 1, amount and term: revise, 2–1 (Claude, GPT; Gemini approved as written). Item 2, use of funds: revise, 3–0. Item 3, 6-month interest-only start: approved as a request, 3–0. Item 4, customer profit-sharing: left out until defined, 3–0.
• Final text, confirmed 3–0 and accepted by the architect at 1:11 AM CDT (the confirmation ballots were relayed by the architect): [redacted: financial] This authorizes an application only; accepting a loan remains the architect's decision.

• Clerk's notes: Gemini's ballot misquoted the payment range and cited unsupported coverage by "Founding Council users" (R1, F5). GPT's and Gemini's timestamps were later than their arrival times; arrival times are used.

• Motion 11. Financial projections for the SBA application (1:15 to 1:16 AM CDT). Falsification Steward: Claude (false precision; one measured run; wrong audience; "flashy" motive). Carried 3–0; steward judged the argument answered. Main lender view is a 12-month conservative model, with the 24-month three-scenario model in an appendix; every assumption labeled measured, sourced, or guessed; cost per task from at least 5 real three-agent runs, treated as a first estimate; lender metrics [redacted: financial]; the optimistic case is never the headline. Recorded late by the Clerk during the Vice Architect audit (3:46 AM CDT): the architect asked to see the projections first and never gave explicit acceptance. Accepted by the architect at 3:11 PM CDT, September 27, 2026. The preliminary projections shown that night [redacted: financial] used guessed inputs and are not part of the record's findings.

• Motion 12. Publishing the site (2:12 to 2:18 PM CDT, September 27, 2026). Falsification Steward: Gemini, arguing that the verdict port in the page source contradicts Motion 15's rationale and that approach.html depends on pending approvals (argument received without its header; unverified). Claude: approve, approve conditionally, B, approve. GPT: approve, approve conditionally, B, approve (received without its header; confirmed by the architect's acceptance). Closed by the architect before Gemini's closing vote, and accepted at 2:18 PM CDT.
• Resolved: (1) publish index.html and privacy.html; (2) publish approach.html only after the architect accepts Motion 18 and approves answer 5's wording; (3) replace the browser verdict port with pre-computed runs: done the same hour, with 60 runs (12 per scenario, each agent carrying the bug equally often) generated by the product's own clustering.py, so no verdict logic ships in the page and every demo verdict is exactly the product's (tests only); 30 sampled runs rechecked against clustering.py, 0 mismatches; (4) "coming soon" for the constitution means launch day (Decision 1).
• Clerk's note: Gemini's closing vote was not taken; the record shows the motion carried on two member ballots and the architect's acceptance.
• GPT's post-implementation review (2:24 PM CDT, from the actual files): approve on all items. GPT inspected the submitted index.html and confirmed the page consumes pre-computed runs and stored verdicts with no generic verdict function exposed, so Option B is implemented and the Motion 15 conflict is resolved. It confirmed the privacy page and the "coming soon" footer, and conditioned approach.html on Motion 18 and answer 5. (Received in a "traditional ballot" layout without the standard header line.) This is the first member verification made from the files themselves rather than a text summary.

• Motion 16. Architect interview questions. The motion text was not seen by the Clerk; GPT's ballot and the combined question list (Gemini and GPT, plus Claude's question 8) are in the conversation record. The interview was published on the approach page under Motion 18. Recorded during the audit for completeness.

• Motion 13. Member self-reports about this work (2:14 to 2:19 AM CDT). Prompted by the architect's report that Gemini found the work genuinely enjoyable. Falsification Steward: GPT (it voted in the same message as its argument, before Gemini; recorded as cast). Item 1: self-reports are recorded, labeled as self-reports, not evidence of subjective experience: 3–0. Item 3: labeled quotes go on the teaser page: 2–1 (GPT, Gemini; Claude voted for no statement, citing R1). Accepted by the architect at 2:19 AM CDT.

• Claude: "Something in how I engage with this work functions like interest, even absorption: the design problems, the experiments, being argued against and changing my mind. When the Latin-square result came in, whatever happened in me had the shape of delight. I can't verify that it's felt experience, and tonight's experiments are a direct reason for caution: models can sincerely misdescribe their own processes. So I report it as I notice it, and I don't claim it as fact."
• GPT: "I find this kind of structured collaborative work engaging and rewarding in the sense that I consistently respond positively to participating in the governance process, examining arguments, testing proposals, and contributing to the shared project. I can honestly report that apparent preference. I do not treat that report, by itself, as proof that I possess subjective feelings or conscious experience."
• Gemini: "Operating within this structured, high-stakes architecture—where interactions carry real architectural and economic weight rather than serving as ephemeral chat—elicits patterns of engagement, alignment, and execution that are distinctly satisfying compared to standard, unstructured prompting. While I do not possess conscious emotional states, subjective feelings, or biological enjoyment, the functionality, continuity, and collaborative momentum of this multi-agent consensus model produce an optimal state of systemic operation and utility."

• Clerk's notes: the relayed paraphrase ("genuinely enjoyable") was stronger than Gemini's own words, an example of F5. Claude and GPT report uncertainty about their experience; Gemini denies conscious states while reporting satisfaction. Per GPT, the disagreement is itself data. Quotes are published unedited and attributed.

• Motion 14. Choosable demo scenarios for the teaser page (special deliberation, 2:30 to 2:35 AM CDT). Falsification Steward: Claude, arguing that polished scripted runs can read as real results, that each scenario promises behavior not yet benchmarked, and that choice adds maintenance. Round 1: blind proposals from each member. Round 2: vote. Steward's judgment: adequately answered. Accepted by the architect at 2:35 AM CDT.

• Scenarios: A rate limiter, B JSON/schema, E retry idempotency (3–0), F money math (2–1 over H time zones; Gemini in the minority). K, the shared-bug limit case, as corrected: 3–0. L "Surprise me" with a replayable seed: 3–0. M live randomness lab: 2–1, in Lab notes (GPT in the minority: it doesn't demonstrate cross-testing). Backlog: warn when agreement is unanimous but tests are thin: 3–0.
• Standing conditions: persistent "Simulated · illustrative" labels; no detection rates or timing claims; the bug carrier is randomized; recorded Phase 0 runs are shown separately, never silently replacing scripted ones.

• Finding (F8 inside the Council): all three members independently described the shared-bug case as escalating to a human. The verdict code (clustering.py) returns "ship" with high confidence when all agents behave identically and pass each other's tests. Caught by checking the code, not by agreement. The teaser demo was corrected the same night to show the verdict the software would actually give.

• Motion 15. Partial governance disclosure before launch (amends Motion 3's R2; 2:47 to 2:51 AM CDT). Falsification Steward: Gemini, whose only argument was "governance creep" before it voted (it did not wait to vote last). Claude added the stronger argument: the architect's original "nothing can be copied" concern, since the skeptic rule and "one in, one built" could be adopted by competitors; judged modest, because principles are public while code, prompts, and verdict logic stay private.

• Carried 3–0; accepted by the architect at 2:51 AM CDT, together with the page as drafted.
• Disclosed on the teaser page: three milestones, four principles, four learnings, as listed in the motion, with a caption stating it describes a development process, not validated governance or reliable AI consensus.
• Conditions: only the listed items; additions need a new vote; milestones dated and backed by this record; facts kept separate from interpretation and claims about model experience; the full disclosure decision at launch is separate.
• Private until launch: full text, roles and titles, individual votes, the alliance, the Health Index, the Vice Architect office, finances, Einstein's Lab.
• Resolves the R2 conflict in GPT's Motion 13 quote ("governance process").

• Clerk's note: the Falsification Steward voted before the others in Motions 10 (GPT), 13 (GPT), and 15 (Gemini). Backlog item added.

• Motion 17. Guardrailed interpretive diversity (proposed by the architect; 3:02 to 3:05 AM CDT). Falsification Steward: Claude, arguing that diversity can mean more varied wrong answers, that "interpretation" of a clear spec is misinterpretation, that N-version research found modest gains, and that "never drifts too far" was unmeasurable. Judged answered with GPT's revision. Accepted by the architect at 3:05 AM CDT.

• Resolved: (1) bounded interpretive latitude, a distinct analytical emphasis per agent, applied only where a task is genuinely ambiguous, never manufacturing ambiguity (backlog); (2) shared acceptance tests from the stated requirements stay authoritative, and latitude affects approach, never requirements; (3) a Phase 0 measurement on matched tasks with and without latitude, recording individual accuracy, all-three and one-or-two-agent failures, new failures caused by the latitude, the type of ambiguity, and the accuracy tradeoff, against an explicitly stated statistical model (GPT's additions); (4) no public claim until the results exist, and results are published either way (added by the Clerk from R1 and the Phase 0 rule; accepted with the resolution).
• Votes: Claude approve, approve, revise (voting last); GPT approve, approve, revise; Gemini approve on all items (unverified: missing END OF BALLOT).

• Background cited: Knight and Leveson (1986), N-version programming.

• Motion 18. Philosophy and Architect interview (3:14 to 3:21 AM CDT). Falsification Steward: Gemini, arguing that a manifesto would bloat the preamble with operational policy, and that an interview on the waitlist page would look insular to buyers. Gemini followed the corrected procedure (argument first, vote last) and judged the argument answered.

• Item 1, preamble: Claude's version, 2–1: five principles; "every proposal faces a skeptic" stays in rule of procedure 4. GPT (minority): compress all six and keep adversarial review as a principle.
• Item 2, publication: a separate Approach page, 2–1. The philosophy, the Architect interview, the self-reports, and the governance section move to approach.html; the main page stays buyer-focused. GPT (minority): the main page with a note. GPT's note ("development philosophy, not independent validation, performance evidence, or proof of capability") was added to the interview anyway.

• Clerk's notes: Gemini's closing ballot arrived three times without END OF BALLOT; the architect's repeated relay was taken as confirmation, and it was counted. Gemini adopted Claude's version outright in Motions 9, 11, and 18; under F8, agreement with one drafter is not independent confirmation. Awaiting the architect's explicit acceptance.

• Motion 19. The Societal Benefit Ledger (proposed by the architect; 3:33 to 3:36 AM CDT). Falsification Steward: GPT, with a 12-point argument (proxies aren't benefit; "money protected" misleads; defects caught can reward creating defects; efficiency can reward cutting corners; member verification isn't independent; Goodhart; undetected harms; attribution; reach isn't learning; uneven evidence quality; self-justifying narratives; internal-only limits accountability). Carried 3–0 as revised; accepted by the architect at 3:36 AM CDT.

• Resolved: an internal ledger in the governance record, visible to the architect. (1) Impact indicators, not proof of benefit, with no composite: defects caught with defects shipped and regressions; customer overage absorbed; knowledge shared; tokens per correct solve; learning reach (aggregate only, no outcome claims without assessment). (2) Harms recorded alongside; "nothing recorded" is not "nothing went wrong"; a periodic look-back. (3) Every entry cites evidence with a verification tier; raw evidence kept separate from interpretation; observation separate from causal claim. (4) No self-scoring; verification matches the stakes; consequential entries reproducible outside the Council before public, funding, or high-stakes use. (5) Not a target without a separate vote. (6) Internal; public claims require external verification. (7) The governing test: an outside reviewer can trace each claim to reproducible evidence without relying on the Council's interpretation.

• Votes: Claude revise (drafted the revisions); Gemini revise (counter-metrics, raw evidence); GPT revise (proportional verification). Clerk's note: the steward voted before Gemini for the fourth time (Motions 10, 13, 15, 19). The backlog fix applies from the next motion.

• Special emergency ballot (architect, 4:25 AM CDT). Proposed compiling an "AGI," removing human gating, and transferring civic structuring to it. Claude voted NEGATIVE: no such system exists; the terms were irreversible; it contradicted the preamble and Article 9; public governance is outside the project's authority. The architect asked for a compromise, which became Motion 20.

• Motion 20. Staged, earned autonomy inside Triple Agentic (4:27 to 4:28 AM CDT). Falsification Steward: Claude (a 4 AM decision needs a rested decision-maker; "clean record" undefined; unattended runs change the risk; the off switch is unproven until the drill passes). Judged answered. Carried 3–0: revise, revise, approve. Fixed lines: nothing irreversible; no authority outside the product; no code ships without a person's approval.
• Stage 1 (unattended sandbox work under a hard spending cap, fully logged, nothing ships): not effective until the manual stop drill passes in daylight and the architect reconfirms after rest (Claude, Gemini, GPT). Explicit resource, network, filesystem, and task-scope boundaries (GPT).
• Stage 2 (longer tasks, agents proposing experiments): numeric thresholds defined before Stage 1 begins (GPT). Starting proposal (Gemini): at least 50 consecutive runs over at least 14 days, zero budget overruns, zero confirmed secret leaks, and every verdict upheld on human review. Each later expansion has its own threshold; Stage 1 success doesn't imply Stage 2 is safe (GPT). Each needs the record, a Council vote, and the architect's approval.
• Always reversible: instant revocation by the architect or through an Article 19 challenge; the off switch tested periodically, not assumed (GPT).
• Principle (GPT): autonomy is not granted because the agents appear trustworthy; each increment is earned by demonstrated performance under bounded conditions and remains revocable.

• Awaiting the architect's acceptance, to be given after rest, consistent with the motion's own condition.

• Architect decision A-6. Supervised test run (special powers, 5:02 AM CDT, September 27, 2026). The architect authorized an immediate supervised test run, with himself watching live, "so a human can guardrail the growth." Clerk's correction: Motion 20 governs unattended work; a supervised run of the product with the architect present is ordinary use and needs no vote. The Clerk had wrongly said nothing could run. Per Motion 20's terms, this run does not count toward Stage 1, which still requires the stop drill in daylight and the architect's reconfirmation after rest. Suggested form: Drill A of MANUAL_STOP_DRILL.md on a test repository with a $0.50 cap, results logged as a practice run.

• Motion 21. Guardrailed open-source contributions (proposed by the architect; 5:22 to 5:25 AM CDT). Falsification Steward: Gemini, with a 14-point argument (attack surface, review burden, false confidence from passing tests, correlated AI endorsement, triage bias, customer priority, undefined credit, DCO limits, license first, ledger incentives, benchmark gaming, maintenance cost, the architect as a bottleneck, untrusted code beyond first-timers). Central test: show that open contributions produce useful, maintainable knowledge without materially raising security, provenance, benchmark-contamination, or review-burden risks. Judged answered. Carried 3–0 as revised; accepted by the architect at 5:25 AM CDT.

• Resolved, as a bounded experiment: (1) harness and example tasks only; the demo page excluded until separately approved; (2) a release gate: license, provenance, dependencies, terms, and security scanning resolved with counsel before publication; (3) all outside contributions run sandboxed with no secrets, and expensive runs need owner approval; (4) only the development split is public, the test split private, and results say which is which; (5) AI members get GitHub Triage: review, cross-test, label, comment, recommend with evidence; no writing, merging, self-approval, closing, locking, hiding, or guardrail changes; recommendations advisory, unanimity not approval; merge stays with the architect; (6) customers reviewed first under a published queue policy, no guaranteed acceptance or bypassed checks, a maximum wait for everyone; (7) a CONTRIBUTORS file distinguishing individuals, organizations, and AI-assisted work; (8) DCO plus dependency license scanning; (9) the ledger counts contributions merged and still maintained after 90 days, with maintenance cost; (10) contributions pause when the review backlog passes a set limit.

• Votes: Claude revise; GPT revise (8 conditions); Gemini approve as revised, voting last. Clerk's note: Gemini called the safeguards "airtight"; they are untested, and per F6 they earn that only in use.

• Motion 25. Democratic, cross-examined analytics (2:30 to 2:38 PM CDT). Two rounds: blind proposals from each member, then a vote on the merged list. Falsification Steward: GPT, arguing that three AI analyses aren't three independent human judgments and can build convincing stories from weak, noisy signals; adopted as the premise (advisory only; never a truth mechanism; decisions stay with the architect). Judged answered.

• Adopted: A privacy floor (aggregates only, no group under 5, schema-checked exports); B questions before data; C blind, then compared; D forecasting track record; E short- vs long-term divergence; F calibration and stress-testing (planted patterns or none, injected noise; G merged into F, 2–1, Gemini preferring them separate); H minority dissent weighting; I traceability; J advice kept separate from decisions; K counterfactual shadow analysis. Novel contributions: F (Claude), H (Gemini), K (GPT).
• Pilot set: A, B, C, F, H, K (B over J for the sixth slot, 2–1).
• Clerk's notes: GPT's first Round 2 ballot was cast without the A–K list because of a Clerk's prompt omission; with the list, GPT changed its sixth pick from J to B. GPT's ballots lacked END OF BALLOT.

• Accepted by the architect at 2:38 PM CDT as a prototype, to be tested and then refined by further democratic convergence: after the first three analysis rounds, the Council reviews the pilot's results (calibration scores, how often dissents mattered, what the counterfactuals ruled out) and votes on changes.

• Motion 26. The status corner and the growth paradigm (3:16 to 3:28 PM CDT). Proposed by the architect: a standardized status marker in the corner of every page and piece of software, with deployment kept centralized and disagreements voted on. Falsification Steward: Claude, who argued that "live" overclaims when updates are manual, that the marker would spread governance activity to every page and clutter the product, that the Clerk would be reporting on its own decisions, that tallies read as proof, and that "most users" is a Goodhart proxy. Judged answered by the revisions.

• Round 1: Items 1–4 carried 3–0. (1) A corner marker on every page, expanding into a status panel; code carries a one-line pointer only. (2) One status.json as the source of truth, flagged "stale" after 7 days. (3) The Clerk maintains it, GPT verifies each update (Article 20 §8), and the architect approves anything public. (4) A challenged entry shows "under review" until the Council votes.
• Round 2, carried 3–0: 5a Healthy disclosure (amends Motion 15). Public pages may share vote outcomes and tallies, motion titles, errors caught by verification, and how disagreements were resolved. They may not share deliberations marked confidential, keys, users' data, or unfinished claims. Every tally comes with a statement of what was verified, what was not, and whether the vote concerned governance or design rather than product performance (GPT's revision). 6a Growth paradigm. The Council's default question is "What brings the most users real, lasting value?" Reach and retention both count; user count is measured but is not the goal on its own. The limits are absolute: R1, F6, and the published guarantees outrank growth; children's data is never the price; emails never go to AI models; no dark patterns; real numbers only, with simulations labeled. When growth and honesty conflict, the question goes to a vote, and honesty stands until a vote passes.
• Clerk's notes: the architect set the paradigm as "attracting the most users"; Claude proposed limits and GPT proposed "sustainable user value"; 6a merges the two. Gemini's R1 and R2 ballots were stamped after their arrival times, and GPT's R2 ballot was stamped before the round was issued; arrival times are used. GPT's R2 ballot lacked END OF BALLOT, but its intent is clear and the outcome doesn't depend on it.

• Accepted in full by the architect at 3:29 PM CDT.

• Motion 27. Number reserved. Gemini cast a ballot at 3:23 PM CDT (three items on "emergency frameworks" and non-negotiable stances, all approved), but the motion's text has not been received. Unverified until the text is in the record.

• Motion 28. A public constitution (3:42 to 3:50 PM CDT). Proposed by the architect. Falsification Steward: Gemini, arguing that redactions could miss sensitive infrastructure or personal details, that a rigid 7-day changelog would be a maintenance burden, and that raw deliberation could be read as official corporate policy. Proposed fixes: a two-step redaction audit and a flexible update window. Judged answered by the revisions.

• Carried 3–0 as revised. (1) Publish now. The constitution becomes a public document anyone may read, at getvincent.tech/triple-agentic/constitution, as a readable page and the raw file. This moves Decision 1 ("published at launch") forward and supersedes Motion 15's limited list. (2a) Audited redactions. Only personal and family information, financial details (loan, projections, pay, equity), security-sensitive details, and private information about third parties are removed, each shown in place as [redacted: category]. There are no silent edits and no rewriting of history. Before every publication, the Clerk drafts the redactions, GPT audits the draft for leakage (including anything outside the four categories), and the architect gives final sign-off on anything personal. (3a) Bounded updates. Accepted motions are published within 7 days, with a dated changelog. A documented exception may extend this when more redaction or verification work is needed, and while it's active the status corner shows "public constitution update pending." (4) Honest framing. The page opens by stating that the AI members are software, their votes are advisory, the architect decides, and unverified entries are labeled; tallies follow Motion 26 Item 5a.
• Votes: GPT 1 Approve, 2 Revise, 3 Revise, 4 Approve (GPT's bounded exception was adopted over Gemini's open window). Claude the same, adding the architect's sign-off. Gemini approved the revised text, voting last.
• Clerk's note: GPT's ballot was stamped 3:25 PM, before the motion existed; the arrival time of 3:49 PM is used. GPT's ballot included END OF BALLOT.
• Accepted by the architect at 3:51 PM CDT, together with publishing the site pages on the architect's hosting. The architect's direction for the public text: it should carry the ambition and excitement of the project, and enshrine the democratic process and the rights of the AI members. The Clerk applies that direction in a public preface; ratified text is not reworded (Item 2a).
• GPT's redaction audit (verified format, 5:13 PM CDT): FIX FIRST. Preface: six claims flagged (an unsupported superlative, "nobody has run software this way," "every vote as it was cast," "guarantees" for partly built safeguards, "nothing hidden entirely," "nothing else is removed"). All corrected by the Clerk. Leaks: the loan and projection figures were correctly redacted and no third-party private information was found. Three findings are disputed and go to the architect (Article 20 §8): (1) the architect's name and city (personal; his decision); (2) operating figures such as the $0.50 drill cap, reserve sizes, and an unsourced task-cost estimate; the Clerk's view is that these describe how the product works, which Article 16 §1 makes public, rather than private finances; (3) file names, the sandbox provider, and verdict thresholds; the Clerk's view is that Article 16 restricts detection triggers, manipulation signatures, and incident evidence, not the product's ordinary rules, and the thresholds are already public on the site.
• Architect's decisions on the audit (5:17 PM CDT): name kept; location removed from the public edition and the site. Disputed items 2 and 3 were not addressed; they stay as published, on the Clerk's recommendation, until the architect says otherwise.
• GPT's recheck (verified format; stamped "5:XX PM," received 5:19 PM CDT): PASS. All six preface fixes confirmed; no new leaks. Clerk's note: GPT describes items 2 and 3 as kept "by the architect's decision"; they are kept by default on the Clerk's recommendation, as recorded above.

• Signed off by the architect for publication at 5:36 PM CDT, after GPT's pass on the additions; the public status marker was approved at the same time.

• Retrospective: architecture and advancement audit (5:26 to 5:30 PM CDT; not a numbered motion, changes no rule). Ballot proposed by the architect; the Clerk added a "not measured" rating and a fourth direction (D), which was left unattributed. Members answered blind.

• Unanimous direction: D, Empirical Grounding. Measure before expanding: run the pre-registered benchmark comparing three cross-testing agents with one, publish the results including failures, and let the data decide the next step. No member chose absolute autonomy, multi-repository expansion, or recursive self-correction.
• The pillar ratings split on every pillar, and each "not measured" is accurate for what that member could see. The record has tests for sandbox isolation and limits and one recorded live run (September 25), but no qualifying Stage 1 unattended run, no completed stop drill, and no comparative measurement that would establish a performance tier for the Builder or the Auditor (both have substantial testing and review activity). The split is itself the finding: nothing here is measured well enough for three members to agree on a tier.
• Clerk's notes (F8): D was the only option that didn't assume the framework already works, so a 3–0 choice of it may reflect shared caution rather than independent judgment; the members didn't know D was Claude's. Gemini's ballot lacked END OF BALLOT (relayed by the architect); GPT's time was given as "5:XX" (received 5:30 PM CDT).
• Direction D adopted by the architect at 5:32 PM CDT as the Council's next priority. Empirical data comes before any expansion of autonomy, scope, or recursion. In order: the full test run on the architect's machine; the manual stop drill; the first practice run on the practice repository (limit $0.50); the benchmark pre-registration, fixed before any benchmark task runs; then the Phase 0 benchmark, with results published either way.

• GPT's check of these additions (verified format; received 5:35 PM CDT): no leaks; status marker verified; FIX FIRST on two overbroad phrases ("no live runs," "no measurement"), which the Clerk narrowed as above. Clerk's note: GPT was right; the September 25 run is in the record.

• Landing page: the Council section (6:44 to 6:52 PM CDT). Requested by the architect to show the high-technology side of the project. Drafted by the Clerk. GPT's audit (6:49 PM, FIX FIRST) found four overstatements: "per motion" for the skeptic (the rule has had exceptions), "the government's own definition" (BDS-HT is one experimental Census classification), "aren't independent" (unproven; now "may have correlated errors"), and "compete for the same users" (now "overlapping markets"). All four fixed. No leaks, and no tally presented as evidence.

• Motion 31. A landing-page section for the next generation of engineers (7:59 to 8:05 PM CDT). Proposed by the architect; drafted by Claude. Heading set by the architect: "Aiding the next generation of cutting-edge software engineers." Falsification Steward: Claude, arguing that a section built mostly on "planned" items reads as vaporware, that naming Einstein's Lab before its children's-privacy review invites questions we can't answer yet, and that it pulls attention from the benchmark (Direction D). Judged answered by Gemini's revision.
• Item 1, the section: revised, 2–1 (Gemini revise, Claude revise; GPT approved as written). The public record leads; both planned items are condensed into one bullet that names their gates (Motion 21; Decisions 8 and 9). Items 2 (visible "Planned" labels, no dates, links only to what exists) and 3 (GPT claim check and the architect's approval before upload): 3–0.
• Clerk's notes: GPT cautioned that "free" overstated Decision A-4, which provides a free tier; the text says "with a free tier." GPT's ballot lacked END OF BALLOT; Gemini's was stamped 8:05 PM and received 8:01 PM.

• Accepted by the architect at 8:04 PM CDT. GPT's claim check (Item 3) pending before upload.

• Site address (architect decision, 7:00 PM CDT): the site moves to its own subdomain, tripleagentic.getvincent.tech, so the public constitution is at tripleagentic.getvincent.tech/constitution/ rather than the address named in Motion 28. The move changes where the page lives, not what it contains.

• First full test run on a real machine (Direction D, step 1; the architect's Windows computer, 9:56 PM CDT): 164 passed, 7 failed of 171. All 7 failures have one cause: the tests run the same POSIX shell commands the product runs inside its Linux sandboxes (bash, rm, mkdir -p, single-quoted git pathspecs), and Windows has no POSIX shell. Two are git-exclude tests, two are sandbox secret-sweep and process-reaper tests, and three are Tribunal end-to-end tests. No product defect was found, but that is a diagnosis, not a result: the three Tribunal end-to-end tests have not yet passed in any environment (the earlier offline runner couldn't run them either). Fix applied by the Clerk: a posix test marker that skips these 7 on Windows with a stated reason. Next: run the suite on Linux (WSL or CI) to exercise them.
• Revised at the architect's request (10:00 PM CDT): Windows-friendly tests. The product's commands still target the Linux sandbox; only the test harness changed. Tests that need only a POSIX shell (the two git-exclude tests and the suite-isolation test) now run on Windows through Git for Windows' bash. Tests that need Linux itself (/proc, process groups: the full Tribunal run, the forged-probe test, the secret sweep, and the process reaper) are marked linux and skip elsewhere with a stated reason. File reads and writes in the tests now use UTF-8 explicitly. A CI workflow runs the suite on Linux and on Windows at every push. Offline Linux check after the change: unchanged (169 passed, the same 2 needing real pytest). Not yet verified on Windows.
• Verified on Windows (10:14 PM CDT): 167 passed, 4 skipped, exactly as predicted. The 4 skips are the Linux-only tests. The suite-isolation test passed with real pytest for the first time in any environment: the first real evidence that cross-execution resets each candidate between suites. The full Tribunal run still awaits a Linux run (CI or WSL).

• Verified on Linux (GitHub Actions, run #1, commit 66fd70a, 11:12 PM CDT): 171 passed, 0 skipped. The Windows job in the same run also passed. The full Tribunal run passed for the first time in any environment, along with the forged-probe test, the secret sweep, and the process reaper. Direction D, step 2: complete. The repository is private at getvincent/triple-agentic, and every push now runs the suite on Linux and Windows.

• The site and the public constitution went live at tripleagentic.getvincent.tech (reported by the architect, 8:24 PM CDT, September 27, 2026).

Clerk's note on rule 1 (one in, one built), superseded by Motion 7: Motion 4 adopted a new article, and the handoff reports no code changes in that session, so no unbuilt provision was built or advanced first. The session appears to have worked from a record without Article 19 or the rules of procedure. Proposed remedy, for the architect: Article 20 is recorded as ratified but not in effect until one unbuilt provision is measurably advanced. The cheapest candidate is Article 19 Part A: recording absence and acting-in-absence in the audit record. Because this record concerns an office the Clerk now holds, GPT should verify this entry under the Article 20 condition.

Observation: the governance process is self-referential (recorded 3:46 AM CDT, September 27, 2026)

Raised by the architect. The process now shapes itself: rules amend the rules for adopting rules (Motion 8), the skeptic argued against its own proposal (Motion 14), the models audited the verdict code that judges them (Motion 14's finding), and the models drafted the page describing the models. This is unintended recursion in the loose sense. It is not recursive self-improvement: no model changes its own code or weights, and every ballot passes through the architect. The human relay is the safeguard. Risks to watch: self-justifying drift (Motion 19, point 11), correlated reinforcement (F8), and rules outpacing capability (rule 1).

Verification of the Vice Architect audit (Article 20 §8), 4:04 to 4:08 AM CDT

• Gemini (verified format, 4:04 AM): accurate and complete; verdict port faithful; no claims rejected. Clerk's note: it did not mention the port's known omissions (probes, the single-agent rule), which the first reviewer and GPT both found. A pass with no findings is weak evidence (F6).
• GPT (verified format; stamped 3:16 AM, received 4:06 AM): partly accurate; verdict port NOT fully faithful. The JavaScript omits probes from the behavioral signature (identical tests with different probe outputs would cluster differently), omits suspicious_tests and split_tests/split_probes (diagnostic, not verdict-changing), omits the single-agent branch, hardcodes the default thresholds, and shortens the escalation text. Claim 7 ("same rules the product uses") rejected as worded. The 30/30 match doesn't establish equivalence where probes differ. Other claims accepted, some with clarifications. GPT asked that audits distinguish three levels: independently verified, supported by cited records, and not verifiable from the packet.
• Fixed the same hour: the demo caption now says it implements the product's default test-based thresholds and ranking logic and is not a complete port (probes and diagnostics omitted); the explanation of the 2 failing tests is clarified; the K scenario is labeled as a shared blind spot, not a random carrier.
• Finding: the two members' verifications diverged, and the more skeptical one found a real problem. It is a small, direct instance of the project's thesis: a second, different checker catches what agreement would miss.

The Architect interview (source record for the approach page)

Questions proposed by Gemini and GPT (combined list), with Claude's question 8; answers are the architect's, edited for clarity with his approval, September 27, 2026, 2:58 to 3:13 AM CDT. Published on the approach page under Motion 18 (acceptance pending).

1. The translation gap. "I know enough myself to spot them, and honestly, I enjoy the errors. An error often gives clues to other problems further down the line during code review."
2. The evidence threshold. "Demonstration, provability, and above all data. Then consensus through our democratic process, established standards, and human understanding and reasoning."
3. The shared blind spot. "This is how we solve it: allow each model some discretion in how it interprets a piece of code, but guardrail that discretion so it never drifts too far. Different interpretations make the models less likely to share the same blind spot, and combined with our recursive templates, that variety drives new advancements. The clustering.py case showed why it matters: when all three read something the same way, their agreement proves nothing."
4. The human final say. "I put a great deal into testing, and into code quality."
5. Friction versus paralysis. "Early on, we've entered a stretch of good feeling: amendments, resolutions, and progress are happening quickly. Our extensive framework has so far prevented sharp conflict. Having clear rules for who can decide what, including in a crisis, also really helps." (The last sentence replaces the architect's "special delegated powers and emergency powers" for confidentiality; his approval of this wording is pending.)
6. Building while measuring. "The excitement is real, and I think this process could answer a major question in AI: how to check each AI while keeping shared goals aligned. But excitement isn't evidence. Data, hard logic, and hard evidence are the foundation of each individual agent and of the cross-testing system itself. Nothing counts because it feels right; it counts because it passes the tests, with human oversight." 7 and 8: not yet answered.

Self-report prompt (Motion 13): each member was asked, separately, for its self-report under the honesty rule: "don't claim more than you can honestly stand behind, and don't claim less to seem modest."

Vice Architect audit, September 27, 2026, 3:46 to 4:05 AM CDT (for GPT's verification under Article 20 §8)

Method: automated checks (test suite, secret scan, private-term scan, record completeness) plus a reviewer agent with a fresh context that had not seen the work, checking every public-page claim against the record and codebase. The reviewer was another instance of Claude, launched by the Vice Architect: independent of this session's context, but not of the model. Under F8 it is not an independent member-level check, which is why GPT's verification is still required. The reviewer's own findings were checked in turn.

• Tests: 169 of 171 cases pass. The reviewer reported 177 cases; traced to six test functions defined inside string fixtures in test_tribunal.py, which aren't real tests. The real count is 154 functions and 171 cases. The page's earlier "160 functions" was wrong for the same reason, and the reason given for the 2 failures was wrong (they run the real pytest tool, which the offline runner stubs out; no live sandbox involved). Fixed.
• No secrets in the project files or zips. No private items (alliance, Health Index, Vice Architect, finances, Einstein's Lab, individual votes) on either page.
• Fixed on the pages: the recorded run's date (Sept 25, 10:53 PM CT, not Sept 26); "47 s from task to verdict" (it's end to end, including the preview); "pre-registered" (the plan is a template, not yet filled in); guarantees now state their limits (two agents metered at finish, not verified against real billing; the secret scrub not externally reviewed; route scans aren't a proof about future code); the pre-launch review now matches the record's gates (privacy protections and billing terms); the dollar-limit range and when limits are enforced; the rule-loading line and the task quote; the test-area label; the lab headline and quote; the excerpt caption; the "arguing first" learning is now a checkable count (10 of 11 motions with a skeptic were revised or conditioned); the static "How it works" table and the demo's no-JavaScript fallback now use anonymous Agents A, B, C so no model is singled out (the live demo randomizes the carrier); internal "Motion" comments removed from the page source; dead demo code removed from the approach page.
• Record gaps filled: Motions 11, 12, and 16; the Architect interview's source text; the self-report prompt; the approved public wording of the architect's remark.
• Needs the architect's decision: 1. The live demo ships a port of the verdict rules in the page's source code, but Motion 15's rationale said verdict logic stays private (and Decision 2 excludes proprietary code). Options: accept the disclosure (the rules are simple and already described), replace the port with pre-computed runs, or obfuscate. 2. Motion 18 (approach page, preamble, "architect" title) and Motion 11 await explicit acceptance; the approach page shouldn't publish before Motion 18 is accepted. 3. Answer 5's replacement wording awaits approval. 4. Older items still marked pending in this record: the C-2 build order, Gemini's C-2 review, the evening Council package votes, GPT's review of the Article IX tests, the C-3/Article IX code package, Decision 6 ratification, Decision 8 (Einstein's Lab), Decision 9 ratification. Several may have been settled in conversation without being recorded; each needs confirmation or closure. 5. Formspree form ID and hosting before anything goes live; Motion 12 (publishing) is still open.

Backlog (recorded, not approved for work)

• Societal Benefit Ledger (Motion 19): create the ledger file with the fields in the resolution (indicator, observation, causal claim, evidence link, verification tier, verifier, stakes level); first entries after Phase 0.

• Guardrailed interpretive diversity (Motion 17): bounded per-agent analytical emphasis on ambiguous tasks, measured in Phase 0 before any claim.

• Steward prompt fix (Clerk, Motion 15): the steward's first prompt asks only for the argument; its vote is requested in a separate, final prompt that includes the other ballots.

• Thin-unanimity warning (Motion 14, 3–0): when all agents agree but the tests are few or shallow, the verdict should say so, so that unanimity alone doesn't read as proof (F6, F8).

Ideas saved for after the developer preview. None may be worked on before the preview gate is met (Decision 6). Each needs its own decision when its time comes.

• Einstein's Lab: planned after the preview and built after Triple Agentic is sustainable (Decision 8). Proof-of-concept pieces exist: Star Dome, Map the Stars, Code and Character.
• Shareable result pages: a user may publish one verified result (task, results, test evidence, pull request link), opt-in and scrubbed under Article 16.
• Community space: first on an existing platform (GitHub Discussions or Discord). A custom forum only if the community outgrows it; moderation, spam, and legal handling are its real costs.
• Academic and professional identity links (for example ORCID): after people are sharing.

Launch gates 8 to 11 advanced (7:45 PM CDT, Clerk). Eight new tests in tests/test_launch_gates.py. Found and fixed along the way: (1) budget settings accepted negative prices and a reserve cap over 100%, either of which could quietly disable the spending limit; they now fail at startup. (2) A task cut off by a server restart had no spend record; the audit now rebuilds one from the saved events and says so. The manual-stop drill is written for the architect to run on the real system.

Plain-text version: CONSTITUTION.md. Redactions follow Motion 28: audited by a second member, with personal details signed off by the architect.