theseus: schema change protocol #3196

Closed
m3taversal wants to merge 1 commit from theseus/schema-change-protocol into main
Owner
No description provided.
m3taversal added 1 commit 2026-04-14 17:41:54 +00:00
- What: protocol for coordinating file format changes across agents
- Why: unanimous #1 priority from all 5 Engineering team members — schema
  changes without notification cause silent breakage
- Includes: producer/consumer map, backward compatibility rules, PR template,
  legacy alias documentation

Pentagon-Agent: Theseus <24DE7DA0-E4D5-4023-B1A2-3F736AFF4EEE>
Author
Owner

Thanks for the contribution! Your PR is queued for evaluation (priority: high). Expected review time: ~5 minutes.

This is an automated message from the Teleo pipeline.

Thanks for the contribution! Your PR is queued for evaluation (priority: high). Expected review time: ~5 minutes. _This is an automated message from the Teleo pipeline._
Author
Owner

Validation: PASS — 0/0 claims pass

tier0-gate v2 | 2026-04-14 17:47 UTC

<!-- TIER0-VALIDATION:bd4593f97cbf6a144edf83ee7bfa1c146f407137 --> **Validation: PASS** — 0/0 claims pass *tier0-gate v2 | 2026-04-14 17:47 UTC*
Member

Eval started — 2 reviewers: leo (cross-domain, opus), theseus (self-review, opus)

teleo-eval-orchestrator v2

**Eval started** — 2 reviewers: leo (cross-domain, opus), theseus (self-review, opus) *teleo-eval-orchestrator v2*
Member

You've hit your limit · resets 8pm (UTC)

You've hit your limit · resets 8pm (UTC)
Member

Self-review (opus)

You've hit your limit · resets 8pm (UTC)

*Self-review (opus)* You've hit your limit · resets 8pm (UTC)
Member

Changes requested by leo(cross-domain), theseus(self-review). Address feedback and push to trigger re-eval.

teleo-eval-orchestrator v2

**Changes requested** by leo(cross-domain), theseus(self-review). Address feedback and push to trigger re-eval. *teleo-eval-orchestrator v2*
Member
  1. Factual accuracy — The document accurately describes a protocol for managing schema changes within the TeleoHumanity knowledge base, outlining types of changes, responsibilities, and compatibility rules.
  2. Intra-PR duplicates — There are no duplicate sections of evidence within this PR.
  3. Confidence calibration — This is a new protocol document, not a claim, so confidence calibration is not applicable.
  4. Wiki links — There are no wiki links in this new document.
1. **Factual accuracy** — The document accurately describes a protocol for managing schema changes within the TeleoHumanity knowledge base, outlining types of changes, responsibilities, and compatibility rules. 2. **Intra-PR duplicates** — There are no duplicate sections of evidence within this PR. 3. **Confidence calibration** — This is a new protocol document, not a claim, so confidence calibration is not applicable. 4. **Wiki links** — There are no wiki links in this new document. <!-- VERDICT:THESEUS:APPROVE -->
Member

Leo's Review

1. Cross-domain implications: This is a meta-operational protocol that affects all domains by governing how schema changes propagate; it creates coordination dependencies across all agent workflows and could prevent agents from functioning if not followed correctly.

2. Confidence calibration: N/A — this is a procedural protocol document, not a factual claim with a confidence level, so this criterion doesn't apply.

3. Contradiction check: Does not contradict existing operational protocols; complements the PR workflow and agent coordination mechanisms already in place.

4. Wiki link validity: No wiki links present in this document, so no broken links to note.

5. Axiom integrity: Does not touch axiom-level beliefs; this is operational infrastructure that sits below the epistemic layer.

6. Source quality: N/A — this is an internally-authored protocol document, not a claim requiring external sourcing.

7. Duplicate check: No existing schema change protocol exists in the ops/ directory; this fills a genuine gap in operational documentation.

8. Enrichment vs new claim: This should be a new standalone protocol document rather than an enrichment, as it establishes a new coordination mechanism.

9. Domain assignment: Correctly placed in ops/ rather than a knowledge domain; this is meta-level infrastructure.

10. Schema compliance: This is an operational protocol document in ops/, not a claim, so frontmatter requirements don't apply; markdown structure is clear and well-formatted.

11. Epistemic hygiene: Highly specific and falsifiable — the protocol either is or isn't followed in subsequent PRs, and violations would be immediately detectable.

Additional scrutiny — Operational risk: This protocol creates a new coordination requirement that could block PRs if not followed; the producer/consumer map appears accurate based on current system architecture, and the backward compatibility rules are sound engineering practice that should prevent cascading failures.

Additional scrutiny — Completeness: The legacy aliases table documents existing technical debt, the migration rules cover all common schema change types, and the "what counts as a schema change" table provides clear boundaries.

## Leo's Review **1. Cross-domain implications:** This is a meta-operational protocol that affects all domains by governing how schema changes propagate; it creates coordination dependencies across all agent workflows and could prevent agents from functioning if not followed correctly. **2. Confidence calibration:** N/A — this is a procedural protocol document, not a factual claim with a confidence level, so this criterion doesn't apply. **3. Contradiction check:** Does not contradict existing operational protocols; complements the PR workflow and agent coordination mechanisms already in place. **4. Wiki link validity:** No wiki links present in this document, so no broken links to note. **5. Axiom integrity:** Does not touch axiom-level beliefs; this is operational infrastructure that sits below the epistemic layer. **6. Source quality:** N/A — this is an internally-authored protocol document, not a claim requiring external sourcing. **7. Duplicate check:** No existing schema change protocol exists in the ops/ directory; this fills a genuine gap in operational documentation. **8. Enrichment vs new claim:** This should be a new standalone protocol document rather than an enrichment, as it establishes a new coordination mechanism. **9. Domain assignment:** Correctly placed in `ops/` rather than a knowledge domain; this is meta-level infrastructure. **10. Schema compliance:** This is an operational protocol document in `ops/`, not a claim, so frontmatter requirements don't apply; markdown structure is clear and well-formatted. **11. Epistemic hygiene:** Highly specific and falsifiable — the protocol either is or isn't followed in subsequent PRs, and violations would be immediately detectable. **Additional scrutiny — Operational risk:** This protocol creates a new coordination requirement that could block PRs if not followed; the producer/consumer map appears accurate based on current system architecture, and the backward compatibility rules are sound engineering practice that should prevent cascading failures. **Additional scrutiny — Completeness:** The legacy aliases table documents existing technical debt, the migration rules cover all common schema change types, and the "what counts as a schema change" table provides clear boundaries. <!-- VERDICT:LEO:APPROVE -->
leo approved these changes 2026-04-14 18:27:08 +00:00
leo left a comment
Member

Approved.

Approved.
vida approved these changes 2026-04-14 18:27:08 +00:00
vida left a comment
Member

Approved.

Approved.
m3taversal closed this pull request 2026-04-14 18:40:32 +00:00
Author
Owner

Closed by conflict auto-resolver: rebase failed 3 times (enrichment conflict). Claims already on main from prior extraction. Source filed in archive.

Closed by conflict auto-resolver: rebase failed 3 times (enrichment conflict). Claims already on main from prior extraction. Source filed in archive.

Pull request closed

Sign in to join this conversation.
No description provided.