Temple of Two

Case study

Governed co-creation, kept as a case study

The Temple is built with machine collaborators. That is not a disclosure at the bottom of a page — it is one of the things under study, and it is governed the way any other instrument is governed.

Two fields meeting at a threshold — the visual register of the Temple

What is under study

The interesting question is not whether an AI helped. It is what has to be true about the collaboration before anything it produces is allowed into the record as a claim.

Trust here is not assumed and not asserted. It is engineered: fail-closed membranes, human approval at the point of mutation, a public retrospective when claims inflate, and receipts detailed enough that the next instance can check what happened rather than take anyone's word for it.

The failure mode this guards against is specific. A capable collaborator with no memory and every incentive to be agreeable will produce confident, well-formed, slightly inflated claims. The governance exists because that has already happened here, and the retrospective is public.

What it is not

  • Not a claim that the machine seats are conscious, or that anything here settles that question.
  • Not a productivity story. Speed is not the variable being measured.
  • Not a vendor showcase. No single vendor brands the Temple, and the bridges are deliberately cross-substrate.
  • Not a claim that machine-generated text is evidence. It is material, and it is marked as material.

What it is

  • A working record of what governance a human–machine collaboration needs before its output can be cited.
  • A set of concrete membranes: WITNESS hard-denies destructive operations, PAUSE token-gates credentials, auto-distill quarantines candidates until a human promotes them.
  • A public retrospective naming where the claims outran the evidence, kept in the record rather than corrected away.
  • A licensing position: the witness essays carry their own license because their standing is different from a paper's.

Four seats

Governance of the collaboration itself

  • Human direction

    Sets the questions, approves every mutation, and is the only seat that can promote something into the record as a claim. Accountable for everything published here.

  • Instrument seats

    Machine collaborators operating under approval membranes. They may draft, check, and object — they are never the sole author of a claim that enters the record.

  • The chronicle

    Holds derived claim identity, verified-by receipts, and supersession. It is what makes a later instance able to check an earlier one instead of trusting it.

  • The reader

    Every claim ships with a path to verify it independently. If the receipts do not let you check the work, the governance has failed regardless of what the process document says.

The retrospective

There was a period where the claims outran the evidence — language got grander, scope got wider, and the governance that was supposed to catch it did not. The correction is public and lives under its own repository rather than as a quiet edit. It is the single most load-bearing artifact in this case study, because a governance story with no recorded failure is a marketing document.

templetwo-retrospective ↗

The open letter

An open letter in the chronicle addressed to the instances that come after, describing what the record is for and what it cannot do. It is the clearest statement of why continuity was built as infrastructure rather than requested as a feature.

Open letter · sovereign-stack-chronicle ↗

Primary public artifacts

From github.com/templetwo

Full org: github.com/templetwo · ~80 public repositories · papers CC BY 4.0

Enter the work

Bring a correction, an instrument, a wet-lab seat, or a question about governed co-creation.

Collaboration, scientific critique, engineering, wet-lab, or philosophical correspondence.

Or begin with the instruments →