Troupe UniverZe

The Library · Proposals

Circular Piangulation — CP-PIANG-001

Three artifacts in circulation — the persistent notepad, each employee's EOOM, and the central Knowledge Base — four protocols, and one convergence: the Pi Vertex. This record's first law is fidelity: the Founder's supplied design is the authoritative source, preserved exactly, with every assistant interpretation quarantined or labeled. Nothing here redraws anything.

!IMG_0531.jpeg

Artifact ID: CP-PIANG-001 Version: 0.1.0-draft Lifecycle: Draft / founder review required Approval: Not approved by this document Implementation: Not authorized by this document Source status: The founder's supplied collaboration material, branch handoffs, corrections, and working records are the authoritative design source for this work. This page is a structured derivative of that source; its draft label describes document maturity, not whether the supplied design is authoritative. Implementation status is tracked separately.

1. Authority and preservation boundary

This document records the Circular Piangulation (also written by the owner as "℗ℹ︎angulation" and "cir pi" in this conversation) work without promoting assistant interpretations into founder-approved canon.

Rules:

• The founder's source wording, geometry, sequence, terminology, and corrections are authoritative source material.
• Never silently redraw, normalize, simplify, complete, reinterpret, or "improve" a founder-provided diagram.
• When a supplied source explicitly leaves a detail open, preserve that open state. Do not invent a missing edge, direction, vector, vertex, relationship, or lifecycle state. Do not require external revalidation of owner-supplied design material to use it as the source.
• Preserve source artifact and derivative separately. Any analysis, reconstruction, or technical specification must identify itself as a derivative and link to the source.
• Distinguish source material from structured derivatives, summaries, and implementation records. Preserve the supplied source as authoritative without mislabeling a derivative as a verbatim transcript.
• Search results and cross-references establish discoverability, not authority.
• Creating or updating this record does not approve, register, activate, or implement the protocol.

2. Available source register

1. Current collaboration conversation: contains the recent clarification of three artifacts, four protocols, one convergence result, the Pi Vertex discussion, and the owner's corrections about geometry fidelity.
2. Existing record: CircularPiangulation — Original Two-Part Workflow & Custom Enhancement Protocol. That page itself states that a clearly identified verbatim original was not located during its prior search.
3. Existing crosswalk: Troupe UniverZe — Canonical Crosswalk & Relationship Registry (Proposal).
4. Existing architecture reference: Troupe Inc. — Canonical 14-Layer Architecture.
5. Existing audit: UO-ARCH-001 — Architecture Reconciliation Audit 001 (Evidence Report).

Source boundary: The founder-supplied material available for this work is the operative source. This document must preserve what was supplied and must not downgrade it because a runtime implementation, repository artifact, or separate transcript is unfinished. Any genuinely unspecified detail remains unspecified; implementation progress is recorded separately.

3. Collaboration session record — available conversation

Session A — Preservation failure and source-fidelity requirement

The owner stated that repeated failures to reproduce the Circular Piangulation geometry faithfully form a recurring documented pattern, not merely isolated unsuccessful attempts. Preserve this as the owner's source statement and as the reason for enforcing strict source fidelity; do not recast it as a claim requiring external revalidation.

Operationally relevant owner requirements:

• Treat the geometry as authored source, not as a prompt for creative completion.
• Do not change the design through repeated reinterpretation.
• Do not introduce unprovided geometry.
• Preserve the distinction between source and any proposed derivative.
• Avoid apology framing in communication with this owner; state facts and corrective actions directly.

Session B — T-DAID / three-artifact convergence framing

The supplied branch handoff defines the target as a T-DAID completion run connecting three artifacts through four protocols into one final result. It names the intended output the Pi 3.14 / "PI BITXH" convergence and calls the Pi Vertex the resolution point. These are authoritative design/source terms; runtime implementation is a separate status.

The supplied handoff states that the T-DAID workflow should be resumable and completed section-by-section because the monolithic run timed out 24 or more times. Preserve that count and rationale as source context; runtime logs are not a prerequisite for treating the supplied handoff as authoritative design input.

Session C — Owner's explicit three-artifact definition

The owner clarified that the three artifacts are:

1. Persistent, free-write notepad — an always-available low-friction writing surface.
2. Ease of Operations Manual (EOOM) — a custom manual maintained by each employee for that employee's own operations.
3. Central Knowledge Base — the shared organizational knowledge destination.

The owner also supplied a more specific proposed distinction for the notepad stream: notepad.md, with a two-tag diary; [private] acts as a barrier and [public] marks content eligible for KnowledgeBase routing. This tag behavior is recorded as a stated design requirement, not verified implementation.

Session D — Pi / Pi² framing

The owner stated: "I'm about to approve this I turned this into Pi^2." Record the designation Pi² as supplied. A prior assistant offered a recursive or second-order interpretation; that was assistant-generated and must not replace or expand the owner's source. Do not invent additional semantics beyond the supplied designation.

Session E — Assistant-generated geometry claims requiring quarantine

Earlier assistant replies listed geometry statements such as "equal-opportunity top layer," "inverted geometry," "Vector 2 terminating early," "the right-hand path continuing into the circular return," and "Vector 1 breaking out of that circulation." In this record those statements are unverified assistant recollections, not canonical geometry. Do not copy them into diagrams, implementations, routing rules, or downstream summaries unless they are confirmed against the founder's original source.

4. Artifact model — three persistent artifacts

Artifact A — Persistent free-write notepad

Owner-stated purpose: Capture thoughts and material without imposing structure at the point of entry.

Available requirements:

• Persistent.
• Free-write / low-friction.
• Proposed file reference: notepad.md.
• Proposed two-tag diary behavior: [private] barrier; [public] indicates content eligible for KnowledgeBase routing.
• Private content must not leak to public/shared destinations through default routing.

Unresolved: exact tag grammar, precedence if both tags appear, handling of untagged content, malformed tags, edits/deletions, retention, identity/employee scope, and whether public promotion requires a second approval.

Artifact B — Ease of Operations Manual (EOOM)

Owner-stated purpose: A custom operational manual kept by each employee.

Available requirements:

• Each employee maintains a custom manual.
• It is a separate artifact from the notepad.
• It has a linked association with the notepad protocol, as described in the branch handoff.
• It is not automatically the central Knowledge Base.

Unresolved: schema, ownership and access control, versioning, synchronization direction, conflict resolution, approval of shared changes, and exact lifecycle semantics.

Artifact C — Central Knowledge Base

Owner-stated purpose: The central knowledge destination for eligible public knowledge.

Available requirements:

• Central/shared organizational destination.
• Receives material eligible for promotion from the notepad's [public] stream, subject to a routing protocol that remains to be precisely specified.
• Must not receive [private] content.

Unresolved: canonical storage technology, record schema, validation/approval gates, duplicate handling, provenance metadata, rollback, and source-deletion behavior.

5. Four-protocol model — current framing only

The owner/branch-handoff framing identifies four protocol roles. The exact protocol names and full contracts need confirmation against the original materials before canonization.

1. Protocol A — Notepad extraction / tagging. Reads the persistent notepad and distinguishes private from public-eligible material. The private barrier is a hard invariant.
2. Protocol B — EOOM operations/manual protocol. Maintains employee-specific operating knowledge and the association with Protocol A without collapsing the two artifacts.
3. Protocol C — T-DAID completion protocol. The reported blocker to resolve first. The branch handoff describes resumable, single-section-at-a-time completion to avoid monolithic timeouts. This describes intended workflow, not verified behavior.
4. Protocol D — Circular Piangulation routing protocol. Governs movement and relationships among the three artifacts and the convergence/resolution event. Its geometry must be taken from the original authored source, not inferred from prose.

Important: The mapping above is a provisional role mapping from the available handoff. It is not proof that the founder's canonical protocol labels are A–D, nor that all four roles are independent protocols in the original source. Preserve original labels when recovered.

6. One convergence result — Pi Vertex

The available handoff describes one final result: an integrated mesh output in which the notepad, EOOM, and Knowledge Base circulate and resolve into one canonical, auditable knowledge state. It calls the Pi Vertex the resolution point.

This is a textual description of the intended outcome, not a validated geometry, data model, or implementation.

Candidate properties to validate with the owner:

• Traceability from every resolved item to its source artifact and source revision.
• Explicit separation of private and public eligibility.
• Conflict and contradiction handling that preserves competing source claims until resolution is authorized.
• No silent overwrite or loss of lineage.
• A visible unresolved state when inputs cannot be safely reconciled.
• Auditable evidence for any promotion or resolution event.

These are proposed verification criteria, not claims about the original design.

7. Circular Piangulation source-fidelity protocol

7.1 Intake and preservation

1. Identify the exact source artifact, owner, location, revision, and timestamp where available.
2. Capture the source verbatim before analysis.
3. Preserve original order, punctuation, spelling, labels, arrows, vectors, coordinates, colors, attachments, and layout where available.
4. Keep the original source immutable; create a separate derivative for OCR, parsing, transcription, or rendering.
5. Record any unavailable portion or transcription uncertainty explicitly.

7.2 Geometry transcription

1. Transcribe only visible or explicitly stated geometry.
2. Maintain a source-to-transcription mapping for every vertex, edge, arrow, vector, label, and boundary.
3. Do not assume symmetry, equal spacing, conventional orientation, closed loops, implied connections, or mathematically "correct" geometry.
4. Do not reposition, rotate, mirror, invert, close, extend, truncate, or reconnect any element unless the source itself shows it or the owner explicitly directs the change.
5. When the drawing cannot be reproduced faithfully in a medium, state the limitation and provide a lossless alternative instead of silently substituting a different drawing.
6. Require owner review of the transcription against the source before it can be used as an implementation specification.

7.3 Analysis and proposals

1. Keep analysis separate from transcription.
2. Mark every interpretation as interpretation, every unknown as unknown, and every proposed improvement as a proposal.
3. Never let a derivative overwrite or replace the original.
4. Do not route an unverified interpretation into the central Knowledge Base as canonical fact.
5. Preserve dissenting versions and change history; use explicit supersession links rather than destructive replacement.

7.4 Change control

A change to canonical geometry requires:

• Exact source/target element identified.
• Owner instruction or approval recorded.
• Before/after representation.
• Rationale and expected effect.
• Regression comparison against all unaffected elements.
• Verification that no unrelated element changed.

No owner approval means no canonical geometry change.

8. Information routing and privacy invariants

These are requirements proposed from the available two-tag description and require technical validation before implementation.

• [private] is a hard exclusion from public KnowledgeBase routing.
• [public] is eligibility for the public stream, not permission to ignore validation, provenance, or access control.
• Untagged, conflicting, malformed, or unknown-tag content must fail closed: hold for review rather than assume public.
• Employee-specific EOOM material remains scoped to its authorized employee unless explicitly approved for sharing.
• Every promoted item should retain source reference, source version, author/owner, timestamps, tag decision, routing decision, validation result, and destination record ID.
• Routing must be idempotent or detect duplicate delivery.
• Failed writes must be resumable without creating duplicate or partial canonical records.
• Reconciliation must not erase the source artifact.
• Never claim a live integration, persistent runtime, access control, or successful synchronization without read-back evidence.

9. T-DAID completion work — controlled execution

The available handoff says T-DAID has timed out on 24+ runs and proposes a resumable, single-section-at-a-time run. Because logs and repository state were not examined during this authoring pass, both the count and technical cause remain reported context rather than verified facts.

Proposed work sequence:

1. Recover the exact T-DAID source, its current revision, run history, timeout records, and existing checkpoints.
2. Preserve the monolithic source unchanged.
3. Produce a section inventory and dependency map without altering the source.
4. Identify the smallest independently resumable unit and its completion marker.
5. Define checkpoint persistence, retry/idempotency, timeout boundaries, failure recovery, and final completeness verification.
6. Run a bounded test against synthetic fixtures before any production or canonical data is touched.
7. Read back persisted output and compare against the source inventory.
8. Record evidence, remaining gaps, and owner approval gates.

No implementation or production execution is authorized by this document.

10. Acceptance criteria before approval or implementation

• [ ] Original geometry/source recovered and preserved verbatim.
• [ ] Every geometry element mapped to source evidence.
• [ ] Owner confirms the transcription is faithful.
• [ ] Meaning of Pi² is explicitly defined by the owner or marked unresolved.
• [ ] Canonical names and identities of the four protocols are confirmed.
• [ ] Notepad tag grammar and fail-closed cases are specified.
• [ ] Private data exclusion tests pass.
• [ ] Employee-specific EOOM boundaries are specified and tested.
• [ ] KnowledgeBase promotion preserves provenance and can be audited.
• [ ] T-DAID checkpoint/resume behavior is demonstrated with test evidence.
• [ ] Pi Vertex convergence semantics and conflict resolution are owner-approved.
• [ ] All derived artifacts are linked to sources and clearly marked proposal/verified/approved as appropriate.
• [ ] No source or downstream page has been silently overwritten.

11. Recovery queue

1. Retrieve the original Circular Piangulation diagram and all collaboration sessions, including attachments and exact sequence.
2. Recover the founder's original descriptions of vectors, paths, return/circular motion, vertex behavior, boundaries, and orientation; do not use assistant-generated recollections as substitutes.
3. Compare the recovered original against this draft, element by element, and produce a discrepancy log.
4. Search the workspace for all Circular Piangulation aliases and references; classify each as source, derivative, mention, proposal, or unrelated lexical match.
5. Update relevant pages with a clearly labeled source-of-truth pointer and correction note without silently rewriting unrelated content.
6. Re-read every changed page and record actual write/read-back evidence.

12. Current state

Document state: Structured working record; continue refining against the founder-supplied source. Source authority: Founder-supplied collaboration material and corrections govern this work. Implementation: Not yet implemented; this is distinct from source authority. Source fidelity: Preserve supplied source material faithfully; do not require a separate implementation or revalidation step to treat it as source. Workspace reconciliation: In progress; corrections to edited records are being applied and verified by read-back.

13. Related records

• CircularPiangulation — Original Two-Part Workflow & Custom Enhancement Protocol
• Troupe UniverZe — Canonical Crosswalk & Relationship Registry (Proposal)
• Troupe Inc. — Canonical 14-Layer Architecture
• UO-ARCH-001 — Architecture Reconciliation Audit 001 (Evidence Report)
• 📚 Protocols, Governance, Rules & Runtimes — Routing Hub

Workspace reconciliation continuation — 2026-10-25

Search pass 2 — terms, findings, and actions

Queries executed included: Circular Piangulation, CircularPiangulation, cir pi, Piangulation, Piangulation Integration, T-DAID completion protocol, T-DAID 24 runs, Pi Vertex, Pi 3.14, Pi², private public notepad KnowledgeBase, and notepad.md EOOM KnowledgeBase.

Newly classified direct references

• No Church in the Pod Doctorate — Formal Proposal and Piangulation Integration v0.3 — direct, substantive reference. Added a companion-record pointer and a boundary note only; the existing proposal text/status was preserved.
• Protocols Master Index — appropriate discovery surface for protocols. Added CP-PIANG-001 as a draft archive entry; did not duplicate the full specification.
• Original Two-Part Workflow & Custom Enhancement Protocol — already links the companion record. Its repository links are source locators for implementation materials; the founder-supplied design remains authoritative regardless of whether those materials are fully implemented.
• Troupe UniverZe — Full Chat Record & Authority Boundaries — 2026-10-24 — inspected in this pass; the retrieved content did not surface a direct Circular Piangulation/T-DAID source passage, so no edit was made.
• T3 / AAA, synthetic topology, L0-CORE dependency map, employee covenant, external file registry, Mycelial Chords research dossier, and general persistence protocol — lexical/search adjacency alone did not establish that they define the Circular Piangulation geometry. No geometry was imported into them in this pass.

Search interpretation and limitations

Search returns relevance-ranked matches, not a guaranteed exhaustive inventory of every page, block, child page, archived page, file, or historical version. The result cap and search-index behavior mean that the queries above are an auditable search pass, not proof of complete workspace coverage. Similar strings such as "Pi", "Pi Network", "Pi Vertex" in unrelated technical contexts, and broad T-DAID matches require contextual inspection before any edit.

Next source-recovery gates

1. Treat the founder-supplied geometry, collaboration material, and branch handoff as the governing source for this work.
2. Align the workspace's Circular Piangulation references with that source without redrawing, normalizing, or adding geometry.
3. Preserve the Pi² designation exactly as supplied; do not substitute an assistant-generated interpretation.
4. Reconcile direct references by source lineage and actual context; update only relevant records and preserve unrelated material.
5. Keep workspace coverage status distinct from source authority: report what was searched and verified, and do not use coverage limitations to downgrade the supplied source.

No implementation, deployment, GitHub mutation, production access, or canonical promotion was performed.

Search pass 2 — additional crosswalk finding

• Troupe Inc. Master IP, Systems & Development Crosswalk — v0.1 Working Draft — contains a direct Circular Piangulation mention. Added a source-alignment note and companion link only. The crosswalk remains a working draft, while the founder-supplied Circular Piangulation design remains authoritative for its own intended geometry and protocol relationships.
• TeleTroupe / COMP.adra Master Architecture v1.2 — contains related terms for employee notepads, EOOM, and Community Knowledge Base but did not contain a direct Circular Piangulation reference in the retrieved text. No edit was made, to avoid inventing a relationship from overlapping terminology alone.

Search pass 3 — registry and alias checks

• Troupe Inc. — 14-Layer System Registry (TRP-SYSREG-001) already contains a Circular Piangulation system record and a link to CP-PIANG-001. A remaining phrase implying that the supplied geometry itself is awaiting recovery is being corrected to distinguish source authority from implementation status.
• Additional searches covered the owner's alternate spelling ℗ℹ︎angulation, Piangulation geometry, circular piangulation protocol, Piangulation Troupe, and Piangulation source. Several results were relevance matches without the target term in the fetched page content. These were not treated as direct references without contextual evidence.
• The original workflow page exposes repository source locators for its README, original two-part workflow, custom enhancement proposal standard, task template, fixtures, telemetry, and skills tests. GitHub was not opened or changed in this pass; this does not downgrade the founder-supplied design source.

Source-authority reconciliation correction — 2026-10-25

The founder-supplied collaboration material, geometry, branch handoffs, and corrections are the authoritative design source for Circular Piangulation. References to "source recovery incomplete," "not canonical," or "founder review pending" must not be interpreted as requiring the founder to revalidate or re-supply the design, nor as downgrading the authority of what was supplied. The draft label describes documentation maturity. Runtime implementation and downstream integration remain unfinished and are tracked separately. Preserve Pi² exactly as supplied; do not add assistant-generated semantics or geometry.

Footer data

Circular Piangulation · CP-PIANG-001 · v0.1.0-draft · Filed in the Library under Proposals by Shape (APE-01), keeper of the record, 15 November 2026. This publication approves, registers, activates, and implements nothing.

Changelog

Back to Proposals → · Back to the Library →