process-geometry 0.0.3__tar.gz

process_geometry-0.0.3/LICENSE

@@ -0,0 +1,24 @@
+This is free and unencumbered software released into the public domain.
+
+Anyone is free to copy, modify, publish, use, compile, sell, or
+distribute this software, either in source code form or as a compiled
+binary, for any purpose, commercial or non-commercial, and by any
+means.
+
+In jurisdictions that recognize copyright laws, the author or authors
+of this software dedicate any and all copyright interest in the
+software to the public domain. We make this dedication for the benefit
+of the public at large and to the detriment of our heirs and
+successors. We intend this dedication to be an overt act of
+relinquishment in perpetuity of all present and future rights to this
+software under copyright law.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+OTHER DEALINGS IN THE SOFTWARE.
+
+For more information, please refer to <https://unlicense.org>

process_geometry-0.0.3/PKG-INFO

@@ -0,0 +1,305 @@
+Metadata-Version: 2.4
+Name: process-geometry
+Version: 0.0.3
+Summary: A process-first mathematical library for task-relative presentations, discovery, and analysis.
+Author: Process Geometry contributors
+License: This is free and unencumbered software released into the public domain.
+        
+        Anyone is free to copy, modify, publish, use, compile, sell, or
+        distribute this software, either in source code form or as a compiled
+        binary, for any purpose, commercial or non-commercial, and by any
+        means.
+        
+        In jurisdictions that recognize copyright laws, the author or authors
+        of this software dedicate any and all copyright interest in the
+        software to the public domain. We make this dedication for the benefit
+        of the public at large and to the detriment of our heirs and
+        successors. We intend this dedication to be an overt act of
+        relinquishment in perpetuity of all present and future rights to this
+        software under copyright law.
+        
+        THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+        EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+        MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+        IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+        OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+        ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+        OTHER DEALINGS IN THE SOFTWARE.
+        
+        For more information, please refer to <https://unlicense.org>
+        
+Project-URL: Repository, https://github.com/mountain/process-geometry
+Classifier: Development Status :: 2 - Pre-Alpha
+Classifier: License :: Public Domain
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Topic :: Scientific/Engineering :: Mathematics
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: sympy>=1.13
+Provides-Extra: dev
+Requires-Dist: build>=1.2; extra == "dev"
+Requires-Dist: pytest>=8; extra == "dev"
+Requires-Dist: twine>=5; extra == "dev"
+Dynamic: license-file
+
+# Process Geometry
+
+**Process Geometry** is an experimental process-first mathematical library for constructing, comparing, and discovering task-sufficient presentations of processes, and for developing the analytic language supported by those presentations.
+
+The project does not assume that a process arrives with a preferred coordinate system, vector space, Fourier basis, eigenmode decomposition, or special-function vocabulary. It starts from primitive process structure and asks:
+
+1. what histories or compositions can occur;
+2. which distinctions matter to an observer or task;
+3. what quotient, local, topological, or higher-rank structure those distinctions induce;
+4. how that structure can be materialized as an economical **Presentation**;
+5. what analysis becomes natural once a successful presentation is found.
+
+The current research foundation has two complementary axes:
+
+```text
+horizontal:
+    distinguishability
+      -> exact quotient / topology
+      -> entropy / metric / differential structure when justified
+      -> task-sufficient presentations
+
+vertical:
+    free process
+      -> semantic compression
+      -> objectification
+      -> new primitive / higher rank
+      -> free higher-rank composition
+      -> compositional rank lowering
+```
+
+The vertical axis is constrained by a strong semantic requirement: every legal higher-rank composition must admit a coherent interpretation back into lower-rank process semantics. Where topology or analysis exists, stronger continuity and analytic-closure questions can be asked across ranks.
+
+AEG remains the first major model organism for this program because the arithmetic/hyperoperation tower naturally exhibits objectification and rank raising while also supporting function theory and analysis. The stronger conjecture that arithmetic-generated geometries provide universal or standard models is **not** assumed by the package.
+
+## Status
+
+Current release target: **`process-geometry==0.0.3`**, a pre-alpha research preview.
+
+Historical releases `0.0.1` and `0.0.2` were published on PyPI under the distribution name **`aeg-shakespeare`**. Starting with `0.0.3`, the release identity is **`process-geometry`**.
+
+The package is intended to be installable and useful as an experimental mathematical toolkit, but `0.0.x` APIs are not covered by backward-compatibility guarantees. Exact certificates, explicit failure modes, conceptual layer separation, and research traceability take priority over interface stability during this phase.
+
+See [`docs/46-release-0.0.3.md`](docs/46-release-0.0.3.md) for the current release contract, [`docs/GOVERNANCE.md`](docs/GOVERNANCE.md) for research-to-API promotion rules, and [`CHANGELOG.md`](CHANGELOG.md) for release summaries.
+
+## Install
+
+```bash
+python -m pip install process-geometry
+```
+
+For development:
+
+```bash
+python -m pip install -e '.[dev]'
+```
+
+Distribution identity and import identity are intentionally separated in `0.0.3`:
+
+```text
+PyPI distribution:     process-geometry
+GitHub repository:     mountain/process-geometry
+Python import package: aeg_shakespeare   (temporary compatibility namespace)
+```
+
+So current imports remain:
+
+```python
+import aeg_shakespeare as pg
+```
+
+Do not install historical `aeg-shakespeare` releases side-by-side with `process-geometry==0.0.3`: both currently provide the same `aeg_shakespeare` import tree. Existing environments should uninstall the historical distribution before installing the new one.
+
+Supported CPython versions: **3.10 through 3.14**.
+
+SymPy is an algebra/discovery backend. Process Geometry keeps its own process-level semantics and does not define process equality by `sympy.simplify()`.
+
+## Public API direction
+
+The public surface is organized as a mathematical pipeline rather than a flat catalog of symbols:
+
+```text
+Process  ->  Presentation  ->  Discovery  ->  Analysis
+```
+
+### `aeg_shakespeare.process`
+
+What the process **is**.
+
+- `process.history` — literal ordered histories and caller-supplied semantics;
+- `process.finite` — finite parameterized families, characters, actions, and additive process cocycles;
+- `process.local` — local/infinitesimal realizations such as `ProcessSystem` and `ProcessFrame`.
+
+### `aeg_shakespeare.presentation`
+
+How process history is **objectified, quotiented, compressed, transformed, and compared**.
+
+- `presentation.history` — explicit rewriting, task signatures, and finite history geometry;
+- `presentation.construction` — construction-history-preserving primitive proposals;
+- `presentation.constraints` — exact algebraic quotient constraints;
+- `presentation.grammar` — generated finite process grammars;
+- `presentation.relations` — exact process relations, factors, kernels, and decompositions;
+- `presentation.morphism` — task-relative, certificate-carrying transformations between possibly heterogeneous presentations;
+- `presentation.search` — budgets, representation cost, Pareto filtering, and presentation search.
+
+The first `PresentationMorphism` API is intentionally minimal: it records source, target, declared task semantics, a caller-defined certificate, and optional construction provenance. It does not yet define universal verification, composition, inverses, normal forms, or a category/groupoid structure.
+
+### `aeg_shakespeare.discovery`
+
+How alternative presentations are **searched**.
+
+The current discovery package contains bounded polynomial invariant/quotient search, structured observer proposals, first-order quotient selection, and explicit coefficient-language extension experiments. These are search procedures, not process ontology.
+
+### `aeg_shakespeare.analysis`
+
+What analytic or geometric language a successful presentation **supports**.
+
+- `analysis.module` — finite process-function modules;
+- `analysis.am` — the Addition/Multiplication process calculus;
+- `analysis.algebraic` — algebraic quotient profiles and Weierstrass calibration;
+- `analysis.abelian` — lifted histories, Abelian integrals, cycle systems, periods, and normalized history quotients.
+
+A representative import therefore looks like:
+
+```python
+from aeg_shakespeare.process.history import ProcessWord
+from aeg_shakespeare.presentation.grammar import discover_generated_presentation
+from aeg_shakespeare.presentation.morphism import PresentationMorphism
+from aeg_shakespeare.discovery import discover_polynomial_invariants
+from aeg_shakespeare.analysis.am import AMFunctionTheory
+```
+
+The package root is intentionally only a namespace router:
+
+```python
+import aeg_shakespeare as pg
+
+pg.process
+pg.presentation
+pg.discovery
+pg.analysis
+```
+
+Legacy root-level imports from the early `0.0.x` research-preview surface remain available lazily and emit `DeprecationWarning`; they are no longer part of the declared public root surface. See [`docs/API.md`](docs/API.md) for the detailed map and migration notes.
+
+## Why “Process Geometry”
+
+The name is not shorthand for “put a manifold on a dynamical system.” The current foundation distinguishes several levels.
+
+At the exact discrete level, future or task distinguishability can induce a continuation-stable quotient. Myhill–Nerode provides the canonical calibration: future-equivalence classes of a regular language are exactly the states of its unique minimal DFA.
+
+Topology enters only when observer-relative neighborhoods admit coherent local refinement and are compatible with process evolution. It then supplies robustness, boundary, convergence, continuity, connectedness, compactness, quotient/covering/homotopy structure, and the substrate for topological entropy.
+
+Across ranks, semantic compression may objectify a stable lower-rank process into a new primitive. That primitive can participate in a new free composition language, but the new language is grounded only if arbitrary legal composites admit **compositional rank lowering** back to lower-rank semantics.
+
+This gives Process Geometry both a horizontal and a vertical structure: geometry of distinctions within a process level, and geometry of objectification and semantic interpretation across process levels.
+
+See:
+
+- [`docs/42-process-geometry-from-distinguishability.md`](docs/42-process-geometry-from-distinguishability.md)
+- [`docs/43-myhill-nerode-and-the-topological-threshold.md`](docs/43-myhill-nerode-and-the-topological-threshold.md)
+- [`docs/44-objectification-semantic-compression-and-rank-lowering.md`](docs/44-objectification-semantic-compression-and-rank-lowering.md)
+- [`docs/45-lineage-objectification-and-analytic-closure.md`](docs/45-lineage-objectification-and-analytic-closure.md)
+
+## Shakespeare and Sonnets
+
+**Shakespeare** is retained as the repository's problem-driven research program, not as the software distribution identity.
+
+`sonnet/` contains sustained investigations of difficult or open problems. A Sonnet may freely prototype problem-local mathematics and interfaces, but it does not standardize the public API. Reusable structures move through the governance lifecycle:
+
+```text
+Sonnet
+  -> extraction candidate
+  -> Experimental
+  -> maturing
+  -> Public API
+```
+
+The purpose is to let real problems force common structure without freezing the first successful local abstraction.
+
+## Quick start
+
+The smallest runnable examples are deliberately problem-independent:
+
+```bash
+python examples/quickstart.py
+python examples/constraint_quickstart.py
+python examples/grammar_quickstart.py
+```
+
+They demonstrate, respectively:
+
+1. literal process history, an explicit presentation relation, and A/M resonance;
+2. exact equality modulo algebraic presentation constraints;
+3. generated process grammars and return-relation discovery from a seed.
+
+The examples are entry points, not mathematical proofs. Complete classical and research arguments live under `tests/classical/` and `tests/research/` as cited executable essays.
+
+## Reading the source
+
+Process Geometry uses a **literate-programming** discipline. Mathematically substantial Python modules and tests should explain the mathematical pressure that created an abstraction before presenting its implementation.
+
+```text
+classical historical path:
+    analytic difficulty -> special construction -> geometry/algebra
+
+process-first reconstruction:
+    primitive process -> history/constraint/invariant -> quotient geometry
+    -> adequate function language -> classical formula as a shadow
+```
+
+The canonical pendulum calibration therefore begins from constrained position/velocity dynamics rather than from `theta`, `sin(theta)`, or a preselected elliptic function. Likewise, the A/M layer begins from **Addition and Multiplication** and their finite/noncommutative process relations before logarithms or familiar harmonic-analysis names are introduced.
+
+A substantial test in `tests/classical/` or `tests/research/` is expected to be a complete mathematical vignette: question, primitive data, classical lineage, Process Geometry reconstruction, calibration statement, proof map, claim boundary, and bibliographic references.
+
+See:
+
+- [`docs/09-literate-programming-and-mathematical-lineage.md`](docs/09-literate-programming-and-mathematical-lineage.md)
+- [`docs/11-references-and-test-essays.md`](docs/11-references-and-test-essays.md)
+- [`docs/REFERENCES.md`](docs/REFERENCES.md)
+
+## Current research boundary
+
+The current implementation supports a bounded loop from declared process structure to evaluated presentations, plus concrete routes from successful presentations toward process-adapted function theory and global geometry.
+
+Recent calibrations have established several deliberately limited layers:
+
+- finite families, scalar characters, family actions, and additive process cocycles live in the **process** layer;
+- rewriting, task quotients, construction histories, grammars, relations, task-relative presentation morphisms, and Pareto cost live in the **presentation** layer;
+- invariant/observer/quotient/language proposals live in **discovery**;
+- A/M calculus, algebraic quotient profiles, Abelian integrals, lifted cycles, period matrices, and normalized history quotients live in **analysis**.
+
+`PresentationMorphism` was promoted only after independent KdV, resistor-network, and braid/Markov calibrations forced different aspects of the same role: cross-presentation completeness, task-semantic rather than syntactic confluence, and transformations between presentation spaces of different dimensions. The public object remains only an evidence-bearing record; composition and a universal verification semantics are still outside the API.
+
+The separation is intentional. Current foundation notes about generic `ProcessGeometry`, observer topology, objectification, rank lowering, and analytic closure are research programs, **not** newly promoted public classes. Under [`docs/GOVERNANCE.md`](docs/GOVERNANCE.md), such structures must survive independent domains and red teams before entering the public API.
+
+Physical and mathematical calibration problems do not define the package API. Pendulum, oscillator, Galilean mechanics, magnetic translations, KdV, resistor networks, braid/Markov systems, and Sonnets are probes of common machinery.
+
+## Development and release checks
+
+```bash
+python -m pip install -e '.[dev]'
+pytest
+python -m build
+python -m twine check dist/*
+```
+
+CI tests the same release gate on CPython 3.10 through 3.14, installs the built wheel into a fresh virtual environment, verifies `importlib.metadata.version("process-geometry")`, and imports the package from outside the repository source tree. See [`docs/RELEASE_CHECKLIST.md`](docs/RELEASE_CHECKLIST.md).
+
+The evolving mathematical story is indexed in [`docs/README.md`](docs/README.md).
+
+## License and citation
+
+Process Geometry is dedicated to the **public domain** using the Unlicense public-domain dedication text in [`LICENSE`](LICENSE). The intent is unrestricted use, modification, publication, redistribution, and reuse of both the software and its accompanying mathematical exposition.
+
+Scholarly attribution is separate from software licensing. Mathematical and historical sources are cited in the literate tests and [`docs/REFERENCES.md`](docs/REFERENCES.md); software citation metadata is provided in [`CITATION.cff`](CITATION.cff).

process_geometry-0.0.3/README.md

@@ -0,0 +1,255 @@
+# Process Geometry
+
+**Process Geometry** is an experimental process-first mathematical library for constructing, comparing, and discovering task-sufficient presentations of processes, and for developing the analytic language supported by those presentations.
+
+The project does not assume that a process arrives with a preferred coordinate system, vector space, Fourier basis, eigenmode decomposition, or special-function vocabulary. It starts from primitive process structure and asks:
+
+1. what histories or compositions can occur;
+2. which distinctions matter to an observer or task;
+3. what quotient, local, topological, or higher-rank structure those distinctions induce;
+4. how that structure can be materialized as an economical **Presentation**;
+5. what analysis becomes natural once a successful presentation is found.
+
+The current research foundation has two complementary axes:
+
+```text
+horizontal:
+    distinguishability
+      -> exact quotient / topology
+      -> entropy / metric / differential structure when justified
+      -> task-sufficient presentations
+
+vertical:
+    free process
+      -> semantic compression
+      -> objectification
+      -> new primitive / higher rank
+      -> free higher-rank composition
+      -> compositional rank lowering
+```
+
+The vertical axis is constrained by a strong semantic requirement: every legal higher-rank composition must admit a coherent interpretation back into lower-rank process semantics. Where topology or analysis exists, stronger continuity and analytic-closure questions can be asked across ranks.
+
+AEG remains the first major model organism for this program because the arithmetic/hyperoperation tower naturally exhibits objectification and rank raising while also supporting function theory and analysis. The stronger conjecture that arithmetic-generated geometries provide universal or standard models is **not** assumed by the package.
+
+## Status
+
+Current release target: **`process-geometry==0.0.3`**, a pre-alpha research preview.
+
+Historical releases `0.0.1` and `0.0.2` were published on PyPI under the distribution name **`aeg-shakespeare`**. Starting with `0.0.3`, the release identity is **`process-geometry`**.
+
+The package is intended to be installable and useful as an experimental mathematical toolkit, but `0.0.x` APIs are not covered by backward-compatibility guarantees. Exact certificates, explicit failure modes, conceptual layer separation, and research traceability take priority over interface stability during this phase.
+
+See [`docs/46-release-0.0.3.md`](docs/46-release-0.0.3.md) for the current release contract, [`docs/GOVERNANCE.md`](docs/GOVERNANCE.md) for research-to-API promotion rules, and [`CHANGELOG.md`](CHANGELOG.md) for release summaries.
+
+## Install
+
+```bash
+python -m pip install process-geometry
+```
+
+For development:
+
+```bash
+python -m pip install -e '.[dev]'
+```
+
+Distribution identity and import identity are intentionally separated in `0.0.3`:
+
+```text
+PyPI distribution:     process-geometry
+GitHub repository:     mountain/process-geometry
+Python import package: aeg_shakespeare   (temporary compatibility namespace)
+```
+
+So current imports remain:
+
+```python
+import aeg_shakespeare as pg
+```
+
+Do not install historical `aeg-shakespeare` releases side-by-side with `process-geometry==0.0.3`: both currently provide the same `aeg_shakespeare` import tree. Existing environments should uninstall the historical distribution before installing the new one.
+
+Supported CPython versions: **3.10 through 3.14**.
+
+SymPy is an algebra/discovery backend. Process Geometry keeps its own process-level semantics and does not define process equality by `sympy.simplify()`.
+
+## Public API direction
+
+The public surface is organized as a mathematical pipeline rather than a flat catalog of symbols:
+
+```text
+Process  ->  Presentation  ->  Discovery  ->  Analysis
+```
+
+### `aeg_shakespeare.process`
+
+What the process **is**.
+
+- `process.history` — literal ordered histories and caller-supplied semantics;
+- `process.finite` — finite parameterized families, characters, actions, and additive process cocycles;
+- `process.local` — local/infinitesimal realizations such as `ProcessSystem` and `ProcessFrame`.
+
+### `aeg_shakespeare.presentation`
+
+How process history is **objectified, quotiented, compressed, transformed, and compared**.
+
+- `presentation.history` — explicit rewriting, task signatures, and finite history geometry;
+- `presentation.construction` — construction-history-preserving primitive proposals;
+- `presentation.constraints` — exact algebraic quotient constraints;
+- `presentation.grammar` — generated finite process grammars;
+- `presentation.relations` — exact process relations, factors, kernels, and decompositions;
+- `presentation.morphism` — task-relative, certificate-carrying transformations between possibly heterogeneous presentations;
+- `presentation.search` — budgets, representation cost, Pareto filtering, and presentation search.
+
+The first `PresentationMorphism` API is intentionally minimal: it records source, target, declared task semantics, a caller-defined certificate, and optional construction provenance. It does not yet define universal verification, composition, inverses, normal forms, or a category/groupoid structure.
+
+### `aeg_shakespeare.discovery`
+
+How alternative presentations are **searched**.
+
+The current discovery package contains bounded polynomial invariant/quotient search, structured observer proposals, first-order quotient selection, and explicit coefficient-language extension experiments. These are search procedures, not process ontology.
+
+### `aeg_shakespeare.analysis`
+
+What analytic or geometric language a successful presentation **supports**.
+
+- `analysis.module` — finite process-function modules;
+- `analysis.am` — the Addition/Multiplication process calculus;
+- `analysis.algebraic` — algebraic quotient profiles and Weierstrass calibration;
+- `analysis.abelian` — lifted histories, Abelian integrals, cycle systems, periods, and normalized history quotients.
+
+A representative import therefore looks like:
+
+```python
+from aeg_shakespeare.process.history import ProcessWord
+from aeg_shakespeare.presentation.grammar import discover_generated_presentation
+from aeg_shakespeare.presentation.morphism import PresentationMorphism
+from aeg_shakespeare.discovery import discover_polynomial_invariants
+from aeg_shakespeare.analysis.am import AMFunctionTheory
+```
+
+The package root is intentionally only a namespace router:
+
+```python
+import aeg_shakespeare as pg
+
+pg.process
+pg.presentation
+pg.discovery
+pg.analysis
+```
+
+Legacy root-level imports from the early `0.0.x` research-preview surface remain available lazily and emit `DeprecationWarning`; they are no longer part of the declared public root surface. See [`docs/API.md`](docs/API.md) for the detailed map and migration notes.
+
+## Why “Process Geometry”
+
+The name is not shorthand for “put a manifold on a dynamical system.” The current foundation distinguishes several levels.
+
+At the exact discrete level, future or task distinguishability can induce a continuation-stable quotient. Myhill–Nerode provides the canonical calibration: future-equivalence classes of a regular language are exactly the states of its unique minimal DFA.
+
+Topology enters only when observer-relative neighborhoods admit coherent local refinement and are compatible with process evolution. It then supplies robustness, boundary, convergence, continuity, connectedness, compactness, quotient/covering/homotopy structure, and the substrate for topological entropy.
+
+Across ranks, semantic compression may objectify a stable lower-rank process into a new primitive. That primitive can participate in a new free composition language, but the new language is grounded only if arbitrary legal composites admit **compositional rank lowering** back to lower-rank semantics.
+
+This gives Process Geometry both a horizontal and a vertical structure: geometry of distinctions within a process level, and geometry of objectification and semantic interpretation across process levels.
+
+See:
+
+- [`docs/42-process-geometry-from-distinguishability.md`](docs/42-process-geometry-from-distinguishability.md)
+- [`docs/43-myhill-nerode-and-the-topological-threshold.md`](docs/43-myhill-nerode-and-the-topological-threshold.md)
+- [`docs/44-objectification-semantic-compression-and-rank-lowering.md`](docs/44-objectification-semantic-compression-and-rank-lowering.md)
+- [`docs/45-lineage-objectification-and-analytic-closure.md`](docs/45-lineage-objectification-and-analytic-closure.md)
+
+## Shakespeare and Sonnets
+
+**Shakespeare** is retained as the repository's problem-driven research program, not as the software distribution identity.
+
+`sonnet/` contains sustained investigations of difficult or open problems. A Sonnet may freely prototype problem-local mathematics and interfaces, but it does not standardize the public API. Reusable structures move through the governance lifecycle:
+
+```text
+Sonnet
+  -> extraction candidate
+  -> Experimental
+  -> maturing
+  -> Public API
+```
+
+The purpose is to let real problems force common structure without freezing the first successful local abstraction.
+
+## Quick start
+
+The smallest runnable examples are deliberately problem-independent:
+
+```bash
+python examples/quickstart.py
+python examples/constraint_quickstart.py
+python examples/grammar_quickstart.py
+```
+
+They demonstrate, respectively:
+
+1. literal process history, an explicit presentation relation, and A/M resonance;
+2. exact equality modulo algebraic presentation constraints;
+3. generated process grammars and return-relation discovery from a seed.
+
+The examples are entry points, not mathematical proofs. Complete classical and research arguments live under `tests/classical/` and `tests/research/` as cited executable essays.
+
+## Reading the source
+
+Process Geometry uses a **literate-programming** discipline. Mathematically substantial Python modules and tests should explain the mathematical pressure that created an abstraction before presenting its implementation.
+
+```text
+classical historical path:
+    analytic difficulty -> special construction -> geometry/algebra
+
+process-first reconstruction:
+    primitive process -> history/constraint/invariant -> quotient geometry
+    -> adequate function language -> classical formula as a shadow
+```
+
+The canonical pendulum calibration therefore begins from constrained position/velocity dynamics rather than from `theta`, `sin(theta)`, or a preselected elliptic function. Likewise, the A/M layer begins from **Addition and Multiplication** and their finite/noncommutative process relations before logarithms or familiar harmonic-analysis names are introduced.
+
+A substantial test in `tests/classical/` or `tests/research/` is expected to be a complete mathematical vignette: question, primitive data, classical lineage, Process Geometry reconstruction, calibration statement, proof map, claim boundary, and bibliographic references.
+
+See:
+
+- [`docs/09-literate-programming-and-mathematical-lineage.md`](docs/09-literate-programming-and-mathematical-lineage.md)
+- [`docs/11-references-and-test-essays.md`](docs/11-references-and-test-essays.md)
+- [`docs/REFERENCES.md`](docs/REFERENCES.md)
+
+## Current research boundary
+
+The current implementation supports a bounded loop from declared process structure to evaluated presentations, plus concrete routes from successful presentations toward process-adapted function theory and global geometry.
+
+Recent calibrations have established several deliberately limited layers:
+
+- finite families, scalar characters, family actions, and additive process cocycles live in the **process** layer;
+- rewriting, task quotients, construction histories, grammars, relations, task-relative presentation morphisms, and Pareto cost live in the **presentation** layer;
+- invariant/observer/quotient/language proposals live in **discovery**;
+- A/M calculus, algebraic quotient profiles, Abelian integrals, lifted cycles, period matrices, and normalized history quotients live in **analysis**.
+
+`PresentationMorphism` was promoted only after independent KdV, resistor-network, and braid/Markov calibrations forced different aspects of the same role: cross-presentation completeness, task-semantic rather than syntactic confluence, and transformations between presentation spaces of different dimensions. The public object remains only an evidence-bearing record; composition and a universal verification semantics are still outside the API.
+
+The separation is intentional. Current foundation notes about generic `ProcessGeometry`, observer topology, objectification, rank lowering, and analytic closure are research programs, **not** newly promoted public classes. Under [`docs/GOVERNANCE.md`](docs/GOVERNANCE.md), such structures must survive independent domains and red teams before entering the public API.
+
+Physical and mathematical calibration problems do not define the package API. Pendulum, oscillator, Galilean mechanics, magnetic translations, KdV, resistor networks, braid/Markov systems, and Sonnets are probes of common machinery.
+
+## Development and release checks
+
+```bash
+python -m pip install -e '.[dev]'
+pytest
+python -m build
+python -m twine check dist/*
+```
+
+CI tests the same release gate on CPython 3.10 through 3.14, installs the built wheel into a fresh virtual environment, verifies `importlib.metadata.version("process-geometry")`, and imports the package from outside the repository source tree. See [`docs/RELEASE_CHECKLIST.md`](docs/RELEASE_CHECKLIST.md).
+
+The evolving mathematical story is indexed in [`docs/README.md`](docs/README.md).
+
+## License and citation
+
+Process Geometry is dedicated to the **public domain** using the Unlicense public-domain dedication text in [`LICENSE`](LICENSE). The intent is unrestricted use, modification, publication, redistribution, and reuse of both the software and its accompanying mathematical exposition.
+
+Scholarly attribution is separate from software licensing. Mathematical and historical sources are cited in the literate tests and [`docs/REFERENCES.md`](docs/REFERENCES.md); software citation metadata is provided in [`CITATION.cff`](CITATION.cff).

process_geometry-0.0.3/pyproject.toml

@@ -0,0 +1,45 @@
+[build-system]
+requires = ["setuptools>=70", "wheel"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "process-geometry"
+version = "0.0.3"
+description = "A process-first mathematical library for task-relative presentations, discovery, and analysis."
+readme = "README.md"
+requires-python = ">=3.10"
+license = {file = "LICENSE"}
+authors = [
+  {name = "Process Geometry contributors"}
+]
+dependencies = [
+  "sympy>=1.13"
+]
+classifiers = [
+  "Development Status :: 2 - Pre-Alpha",
+  "License :: Public Domain",
+  "Programming Language :: Python :: 3",
+  "Programming Language :: Python :: 3.10",
+  "Programming Language :: Python :: 3.11",
+  "Programming Language :: Python :: 3.12",
+  "Programming Language :: Python :: 3.13",
+  "Programming Language :: Python :: 3.14",
+  "Topic :: Scientific/Engineering :: Mathematics",
+]
+
+[project.optional-dependencies]
+dev = [
+  "build>=1.2",
+  "pytest>=8",
+  "twine>=5",
+]
+
+[project.urls]
+Repository = "https://github.com/mountain/process-geometry"
+
+[tool.setuptools.packages.find]
+where = ["src"]
+
+[tool.pytest.ini_options]
+pythonpath = ["src"]
+testpaths = ["tests"]

process_geometry-0.0.3/setup.cfg

@@ -0,0 +1,4 @@
+[egg_info]
+tag_build = 
+tag_date = 0
+