ETQ-303: clarify vector-space dimensions and tensor notation

[EmergentMonk]

Summary

This prepares ETQ-303 v3.0.1 as a documentation-only terminology and exposition patch while preserving ETQ-303 v3.0.0 as the immutable original release at tag v3.0.0, commit 6b55e51647226d1c248dc8d79f9ed9336241c2ac, and DOI 10.5281/zenodo.21455181.

It makes explicit that “dimension” means finite-dimensional algebraic vector-space dimension unless another meaning is declared, never physical spacetime dimension. It also distinguishes the 8-dimensional Euclidean E8 root space, rank-4 D4, the 101-state ETQ-101 selected basis, and the 303-state tensor extension.

Files changed

• Formal publication: docs/etq-303/v3.0.1/ETQ-303_formal_model_v3.0.1.tex, rebuilt PDF, unchanged bibliography, regenerated UPLOAD_SHA256SUMS.txt, publication README, and scripts/build-etq303-paper.sh.
• ETQ documentation: root README.md, docs/ETQ_V3_EVENT_PROTOCOL.md, docs/ETQ_V3_CLAIM_BOUNDARIES.md, docs/ETQ_V2_TO_V3_MIGRATION.md, and the ETQ-303 extension in docs/MATHEMATICAL_MODEL.md.
• Release/provenance: CHANGELOG.md, docs/ETQ_V3_0_1_RELEASE_NOTES.md, docs/RIGHTS_AND_ARCHIVING.md, .zenodo.json, CITATION.cff, and package.json.

Placement of the clarification

• The formal paper now has §1.2, Notation and Conventions, immediately after version lineage and before the epistemic-layer discussion.
• The first formal state-space definition in §4 now gives:

H_303 = H_101 tensor C^3
dim(H_303) = dim(H_101) dim(C^3) = 101 x 3 = 303

• The same terminology and derivation appear near the opening scope in the repository README and exact-event-protocol documentation.

Validation

• npm run build:paper: PASS with latexmk, pdfLaTeX, and Biber; final log has no unresolved citations/references, package warnings, duplicate labels, or overfull boxes.
• PDF: 17 A4 pages, all fonts embedded, all pages rendered and visually reviewed, and two clean rebuilds were byte-identical.
• PDF SHA-256: 28d84c8e75970b68331b49494ac631e7eecc485a6824103b4daacc8f36212226.
• sha256sum --check UPLOAD_SHA256SUMS.txt: PASS for PDF, LaTeX source, and bibliography.
• npm test: PASS, 35/35.
• python -m pytest: PASS, 55/55.
• python -m ruff check .: PASS.
• npm run verify: PASS for ETQ-303 v3, ETQ-101 v2, and the immutable v1 contract.
• npm run build:v3: PASS; existing contract, event, manifest, receipt, and implementation-source hashes remain unchanged.
• CITATION.cff: valid against CFF 1.2.0; .zenodo.json: valid JSON.

Change boundary

No mathematical construction, operator, state or event ordering, canonical JSON, schema, deterministic receiver, implementation source, fixture, protocol hash, software behavior, or scientific claim changed. The machine-readable protocol identity remains v3.0.0; v3.0.1 versions only the documentation and publication metadata.

Zenodo v3.0.1 upload set

Trent should use Zenodo’s New version workflow from the v3.0.0 record and upload/replace:

• ETQ-303_formal_model_v3.0.1.tex
• ETQ-303_formal_model_v3.0.1.pdf
• regenerated UPLOAD_SHA256SUMS.txt

Retain the unchanged ETQ-303_references.bib, ETQ-303_data_table_v3.0.0.xlsx, and ETQ-303_parameter_table_v3.0.0.csv. If a convenience archive is used, name it ETQ-303_Zenodo_Submission_v3.0.1.zip. After Zenodo mints the version DOI, add it to CITATION.cff and the release notes without altering the v3.0.0 DOI or tag.

Version recommendation

Yes: the appropriate repository/documentation release is v3.0.1, a terminology-only patch. The canonical runtime contract remains v3.0.0 because no protocol behavior or identity-bearing artifact changed.

[sourcery-ai]

Sorry @EmergentMonk, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery