pgc-runtime 4.0.0__tar.gz → 6.0.0__tar.gz

{pgc_runtime-4.0.0 → pgc_runtime-6.0.0}/NOTICE

@@ -1,4 +1,4 @@
-PGS — Protocol-Governed Systems
+PGC — Protocol-Governed Computing
 Copyright 2026 Bhash Ganti aka Bachi
 
 This project introduces a protocol-first execution model in which:

{pgc_runtime-4.0.0/pgc_runtime.egg-info → pgc_runtime-6.0.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: pgc-runtime
-Version: 4.0.0
+Version: 6.0.0
 Summary: PGC protocol runtime — executes a sealed snapshot as governed DAG traversal and emits traces (import package: runtime)
 Author-email: Bhash Ganti <bachipeachy@gmail.com>
 License-Expression: Apache-2.0
@@ -22,6 +22,8 @@ License-File: LICENSE
 License-File: NOTICE
 Provides-Extra: reference
 Requires-Dist: pgc-governance>=2.0.0; extra == "reference"
+Provides-Extra: render
+Requires-Dist: pgc-inspector>=6.0.0; extra == "render"
 Dynamic: license-file
 
 # protocol_runtime
@@ -78,17 +80,17 @@ payload         external input (JSON)
 data-root       the state storage boundary; one data root is one instance
 ```
 
-A run writes an append-only trace alongside the state its declared side effects produce:
+A run writes an append-only trace beside the state its declared side effects produce, both under
+the data root:
 
 ```
-traces/<TRACE_ID>/
-    <TRACE_ID>.jsonl    append-only execution log
-    <TRACE_ID>.md       human-readable summary
-    <TRACE_ID>.png      the execution path, rendered
-
-data/
-    registry/           idempotent state
-    events/             append-only history
+<data-root>/traces/<domain>/<WF>/<TRACE_ID>/
+    <TRACE_ID>.jsonl    append-only execution log, one SCHEMA_TRACE_EVENT_V0 event per line
+    <TRACE_ID>.png      the path the run took, drawn only on request (`run --behavior-logic`,
+                        or `behavior-logic <trace>`)
+
+<data-root>/<domain>/<subdomain>/
+    the stores the domain's runtime binding declares
 ```
 
 ## Running
@@ -100,15 +102,18 @@ data/
 ./run.sh examine /abs/trace.jsonl
 ```
 
-`run.sh` wraps the CLI, also installed as the `protocol_runtime` console script, with four
-subcommands:
+`run.sh` wraps the CLI, also installed as the `protocol_runtime` console script:
 
 | command | what it does |
 |---|---|
 | `run` | execute a workflow against a data root |
+| `replay` | re-execute a run from its recorded outcomes and compare it with the original |
+| `conformance` | run a compiled domain's test vectors; report each transform proven, unproven or refused |
 | `boot` | warm-boot the assembled snapshot — load and hash-verify every manifest domain |
-| `examine` | analyze a completed trace file |
-| `behavior-logic` | render the execution path from a completed trace as a PNG |
+| `coordinator` | serve as the coordinating node of a federated node group |
+| `worker` | serve as a worker node of a federated node group |
+| `examine` | read a completed trace: its path by node, contracts, results, events and errors |
+| `behavior-logic` | render a completed trace as a PNG: the path, each route's outcome, and why each node decided as far as the trace records it (drawn from the inspector's `si.execution.explain`; needs `pgc-runtime[render]`) |
 
 `PGC_SNAPSHOT_ROOT` overrides the snapshot location; `PGC_IMPL_ROOTS` is the colon-separated set of
 roots on `PYTHONPATH` for domain capability implementations.
@@ -117,6 +122,12 @@ roots on `PYTHONPATH` for domain capability implementations.
 establishes that the snapshot is intact and executable before any workflow runs. A surface-only
 snapshot has no workflow to traverse, and warm reboot is exactly what proves it sound anyway.
 
+**A process verifies a snapshot once.** `runtime.api` keeps a booted snapshot resident and runs
+against it as often as it is asked. A rewritten manifest, or a different trust anchor or profile
+root, is verified afresh, and a snapshot that no longer verifies is refused. `boot` itself always
+performs the full determination. A governed run then costs a few milliseconds, not a third of a
+second.
+
 **A data root is an instance, not an interface.** Two data roots against the same snapshot are two
 independent instances of the same governed behavior.
 
@@ -128,6 +139,21 @@ invoking transforms, applying side effects — and routes on the declared outcom
 nothing by name at execution time: the compiler assigned integer addresses, and traversal operates
 on those.
 
+**A workflow may run one contract at several places.** Each place is a node key, and the contract
+it runs is named separately. The compiler seals each place's routing on its own, and refuses a sealed
+dispatch that does not realize every transition declared at that node. Routing is by node, and the
+trace names the place that ran.
+
+**Not every step is determined by its inputs.** A transform is a deterministic atom, a
+non-deterministic atom, or a molecule, and a different constitution governs each. A molecule has no
+implementation: the runtime runs its declared steps. A non-deterministic atom's result is recorded
+where it is produced, and `replay` substitutes the recorded result, so a run is reproducible even
+when a step is not.
+
+**One snapshot can run across nodes.** Under a federated placement, a coordinator schedules units of
+work to workers over a shared store. Under the signed federated profile, every node verifies the
+snapshot's signature before it runs anything.
+
 Every step emits evidence. The trace is not a log the runtime chose to write; it is the record of
 the path actually taken through a graph that was fixed before the run began, which is what makes a
 run reproducible and reviewable after the fact.
@@ -146,7 +172,7 @@ Apache-2.0. See `LICENSE` and `NOTICE`.
 | `pgc-assembler` | `snapshot_assembler` | projections → sealed snapshot |
 | `pgc-runtime` | `protocol_runtime` | snapshot → governed execution |
 | `pgc-inspector` | `snapshot_inspector` | snapshot → read-only inspection |
-| `pgc-transformation` | `transformation` | change request → protocol artifacts |
+| `pgc-transformation` | `transformation_compilers` | change request → protocol artifacts |
 | `pgc-governance` | `software_governance` | the governance surface and its capability implementations |
 | `pgc-workloads` | `conformance_workloads` | the workloads that make conformance observable |
 | `pgc-domains` | `business_domains` | the business domain implementations the composed snapshot binds |
@@ -166,26 +192,28 @@ pgc            # reports what is installed and whether the anchor resolves
 
 `PGC_DOMAIN_ROOTS` names an additional domain contributing its own `registry/structures` — the
 directory that *directly contains* it, not the repository above it; pointing one level too high is a
-silent no-op. `PGC_SNAPSHOT_ROOT` is where compiled output is written, and each domain build needs
-its own: every layer's output consolidates into one root, and verification rejects any file in that
-root the current build did not declare. `PGC_SNAPSHOT_PROFILES` is the directory holding snapshot
-profiles, required by the assembler and the runtime alike.
+silent no-op. `PGC_SNAPSHOT_PROFILES` is the directory holding snapshot profiles, required by the
+assembler and the runtime alike.
+
+**Where a build writes is declared, not supplied.** Each build configuration names its root in
+`output_configuration.root`, and every layer's output consolidates there. The compiler does not read
+`PGC_SNAPSHOT_ROOT`; the runtime does, with its own meaning — the assembled snapshot to execute.
 
-`PGC_BUILD_ROOT` is accepted and reported and **nothing reads it** — `PGC_SNAPSHOT_ROOT` is the
-anchor that controls output.
+`PGC_BUILD_ROOT` is accepted and reported and **nothing reads it**.
 
 The full sequence, with the repositories it needs, is in
 [`pgc_install`](https://github.com/protocol-governed-computing/pgc_install).
 
-**Versioning.** Two schemes, and the published version follows the second.
+**Versioning.** Two numbers name two different things.
 
-- **Internal** — each repository's `VERSION` file, a monotonic composition ordinal. PGC versions the
-  composition rather than each repo: they release together and the governance closure forces lockstep,
-  so the ordinal names which composition a repo belongs to. Development happens on `dev/<N>` and each
-  cycle is tagged `release-<N>`. This is not published.
-- **Public** — `PUBLIC_VERSION`, tagged on every component repository. The platform is at **`v3`**.
+- **Published** — this distribution's `version` in `pyproject.toml`. It moves on its own. A release
+  that changes this repository bumps it, and a release that leaves the repository unchanged keeps it.
+- **Composition** — the public identity (`v6`, …) names one composition of the whole family.
+  `pgc_release` records which version of each distribution that composition holds, and `pgc_install`
+  pins exactly those versions.
 
-**The published version is the public one: `v4` is `4.0.0`.** The standard the packages implement is a
-separate artifact on its own track and is not this number.
+Each repository's `VERSION` file holds the workspace's cycle ordinal, which names the `dev/<N>`
+branch. It is development accounting, and it is never published. The standard the packages
+implement is a separate artifact on its own track, and none of these numbers is its revision.
 
 The standard these packages implement is published separately: https://doi.org/10.5281/zenodo.22150616

{pgc_runtime-4.0.0 → pgc_runtime-6.0.0}/README.md

@@ -52,17 +52,17 @@ payload         external input (JSON)
 data-root       the state storage boundary; one data root is one instance
 ```
 
-A run writes an append-only trace alongside the state its declared side effects produce:
+A run writes an append-only trace beside the state its declared side effects produce, both under
+the data root:
 
 ```
-traces/<TRACE_ID>/
-    <TRACE_ID>.jsonl    append-only execution log
-    <TRACE_ID>.md       human-readable summary
-    <TRACE_ID>.png      the execution path, rendered
-
-data/
-    registry/           idempotent state
-    events/             append-only history
+<data-root>/traces/<domain>/<WF>/<TRACE_ID>/
+    <TRACE_ID>.jsonl    append-only execution log, one SCHEMA_TRACE_EVENT_V0 event per line
+    <TRACE_ID>.png      the path the run took, drawn only on request (`run --behavior-logic`,
+                        or `behavior-logic <trace>`)
+
+<data-root>/<domain>/<subdomain>/
+    the stores the domain's runtime binding declares
 ```
 
 ## Running
@@ -74,15 +74,18 @@ data/
 ./run.sh examine /abs/trace.jsonl
 ```
 
-`run.sh` wraps the CLI, also installed as the `protocol_runtime` console script, with four
-subcommands:
+`run.sh` wraps the CLI, also installed as the `protocol_runtime` console script:
 
 | command | what it does |
 |---|---|
 | `run` | execute a workflow against a data root |
+| `replay` | re-execute a run from its recorded outcomes and compare it with the original |
+| `conformance` | run a compiled domain's test vectors; report each transform proven, unproven or refused |
 | `boot` | warm-boot the assembled snapshot — load and hash-verify every manifest domain |
-| `examine` | analyze a completed trace file |
-| `behavior-logic` | render the execution path from a completed trace as a PNG |
+| `coordinator` | serve as the coordinating node of a federated node group |
+| `worker` | serve as a worker node of a federated node group |
+| `examine` | read a completed trace: its path by node, contracts, results, events and errors |
+| `behavior-logic` | render a completed trace as a PNG: the path, each route's outcome, and why each node decided as far as the trace records it (drawn from the inspector's `si.execution.explain`; needs `pgc-runtime[render]`) |
 
 `PGC_SNAPSHOT_ROOT` overrides the snapshot location; `PGC_IMPL_ROOTS` is the colon-separated set of
 roots on `PYTHONPATH` for domain capability implementations.
@@ -91,6 +94,12 @@ roots on `PYTHONPATH` for domain capability implementations.
 establishes that the snapshot is intact and executable before any workflow runs. A surface-only
 snapshot has no workflow to traverse, and warm reboot is exactly what proves it sound anyway.
 
+**A process verifies a snapshot once.** `runtime.api` keeps a booted snapshot resident and runs
+against it as often as it is asked. A rewritten manifest, or a different trust anchor or profile
+root, is verified afresh, and a snapshot that no longer verifies is refused. `boot` itself always
+performs the full determination. A governed run then costs a few milliseconds, not a third of a
+second.
+
 **A data root is an instance, not an interface.** Two data roots against the same snapshot are two
 independent instances of the same governed behavior.
 
@@ -102,6 +111,21 @@ invoking transforms, applying side effects — and routes on the declared outcom
 nothing by name at execution time: the compiler assigned integer addresses, and traversal operates
 on those.
 
+**A workflow may run one contract at several places.** Each place is a node key, and the contract
+it runs is named separately. The compiler seals each place's routing on its own, and refuses a sealed
+dispatch that does not realize every transition declared at that node. Routing is by node, and the
+trace names the place that ran.
+
+**Not every step is determined by its inputs.** A transform is a deterministic atom, a
+non-deterministic atom, or a molecule, and a different constitution governs each. A molecule has no
+implementation: the runtime runs its declared steps. A non-deterministic atom's result is recorded
+where it is produced, and `replay` substitutes the recorded result, so a run is reproducible even
+when a step is not.
+
+**One snapshot can run across nodes.** Under a federated placement, a coordinator schedules units of
+work to workers over a shared store. Under the signed federated profile, every node verifies the
+snapshot's signature before it runs anything.
+
 Every step emits evidence. The trace is not a log the runtime chose to write; it is the record of
 the path actually taken through a graph that was fixed before the run began, which is what makes a
 run reproducible and reviewable after the fact.
@@ -120,7 +144,7 @@ Apache-2.0. See `LICENSE` and `NOTICE`.
 | `pgc-assembler` | `snapshot_assembler` | projections → sealed snapshot |
 | `pgc-runtime` | `protocol_runtime` | snapshot → governed execution |
 | `pgc-inspector` | `snapshot_inspector` | snapshot → read-only inspection |
-| `pgc-transformation` | `transformation` | change request → protocol artifacts |
+| `pgc-transformation` | `transformation_compilers` | change request → protocol artifacts |
 | `pgc-governance` | `software_governance` | the governance surface and its capability implementations |
 | `pgc-workloads` | `conformance_workloads` | the workloads that make conformance observable |
 | `pgc-domains` | `business_domains` | the business domain implementations the composed snapshot binds |
@@ -140,26 +164,28 @@ pgc            # reports what is installed and whether the anchor resolves
 
 `PGC_DOMAIN_ROOTS` names an additional domain contributing its own `registry/structures` — the
 directory that *directly contains* it, not the repository above it; pointing one level too high is a
-silent no-op. `PGC_SNAPSHOT_ROOT` is where compiled output is written, and each domain build needs
-its own: every layer's output consolidates into one root, and verification rejects any file in that
-root the current build did not declare. `PGC_SNAPSHOT_PROFILES` is the directory holding snapshot
-profiles, required by the assembler and the runtime alike.
+silent no-op. `PGC_SNAPSHOT_PROFILES` is the directory holding snapshot profiles, required by the
+assembler and the runtime alike.
+
+**Where a build writes is declared, not supplied.** Each build configuration names its root in
+`output_configuration.root`, and every layer's output consolidates there. The compiler does not read
+`PGC_SNAPSHOT_ROOT`; the runtime does, with its own meaning — the assembled snapshot to execute.
 
-`PGC_BUILD_ROOT` is accepted and reported and **nothing reads it** — `PGC_SNAPSHOT_ROOT` is the
-anchor that controls output.
+`PGC_BUILD_ROOT` is accepted and reported and **nothing reads it**.
 
 The full sequence, with the repositories it needs, is in
 [`pgc_install`](https://github.com/protocol-governed-computing/pgc_install).
 
-**Versioning.** Two schemes, and the published version follows the second.
+**Versioning.** Two numbers name two different things.
 
-- **Internal** — each repository's `VERSION` file, a monotonic composition ordinal. PGC versions the
-  composition rather than each repo: they release together and the governance closure forces lockstep,
-  so the ordinal names which composition a repo belongs to. Development happens on `dev/<N>` and each
-  cycle is tagged `release-<N>`. This is not published.
-- **Public** — `PUBLIC_VERSION`, tagged on every component repository. The platform is at **`v3`**.
+- **Published** — this distribution's `version` in `pyproject.toml`. It moves on its own. A release
+  that changes this repository bumps it, and a release that leaves the repository unchanged keeps it.
+- **Composition** — the public identity (`v6`, …) names one composition of the whole family.
+  `pgc_release` records which version of each distribution that composition holds, and `pgc_install`
+  pins exactly those versions.
 
-**The published version is the public one: `v4` is `4.0.0`.** The standard the packages implement is a
-separate artifact on its own track and is not this number.
+Each repository's `VERSION` file holds the workspace's cycle ordinal, which names the `dev/<N>`
+branch. It is development accounting, and it is never published. The standard the packages
+implement is a separate artifact on its own track, and none of these numbers is its revision.
 
 The standard these packages implement is published separately: https://doi.org/10.5281/zenodo.22150616

{pgc_runtime-4.0.0 → pgc_runtime-6.0.0/pgc_runtime.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: pgc-runtime
-Version: 4.0.0
+Version: 6.0.0
 Summary: PGC protocol runtime — executes a sealed snapshot as governed DAG traversal and emits traces (import package: runtime)
 Author-email: Bhash Ganti <bachipeachy@gmail.com>
 License-Expression: Apache-2.0
@@ -22,6 +22,8 @@ License-File: LICENSE
 License-File: NOTICE
 Provides-Extra: reference
 Requires-Dist: pgc-governance>=2.0.0; extra == "reference"
+Provides-Extra: render
+Requires-Dist: pgc-inspector>=6.0.0; extra == "render"
 Dynamic: license-file
 
 # protocol_runtime
@@ -78,17 +80,17 @@ payload         external input (JSON)
 data-root       the state storage boundary; one data root is one instance
 ```
 
-A run writes an append-only trace alongside the state its declared side effects produce:
+A run writes an append-only trace beside the state its declared side effects produce, both under
+the data root:
 
 ```
-traces/<TRACE_ID>/
-    <TRACE_ID>.jsonl    append-only execution log
-    <TRACE_ID>.md       human-readable summary
-    <TRACE_ID>.png      the execution path, rendered
-
-data/
-    registry/           idempotent state
-    events/             append-only history
+<data-root>/traces/<domain>/<WF>/<TRACE_ID>/
+    <TRACE_ID>.jsonl    append-only execution log, one SCHEMA_TRACE_EVENT_V0 event per line
+    <TRACE_ID>.png      the path the run took, drawn only on request (`run --behavior-logic`,
+                        or `behavior-logic <trace>`)
+
+<data-root>/<domain>/<subdomain>/
+    the stores the domain's runtime binding declares
 ```
 
 ## Running
@@ -100,15 +102,18 @@ data/
 ./run.sh examine /abs/trace.jsonl
 ```
 
-`run.sh` wraps the CLI, also installed as the `protocol_runtime` console script, with four
-subcommands:
+`run.sh` wraps the CLI, also installed as the `protocol_runtime` console script:
 
 | command | what it does |
 |---|---|
 | `run` | execute a workflow against a data root |
+| `replay` | re-execute a run from its recorded outcomes and compare it with the original |
+| `conformance` | run a compiled domain's test vectors; report each transform proven, unproven or refused |
 | `boot` | warm-boot the assembled snapshot — load and hash-verify every manifest domain |
-| `examine` | analyze a completed trace file |
-| `behavior-logic` | render the execution path from a completed trace as a PNG |
+| `coordinator` | serve as the coordinating node of a federated node group |
+| `worker` | serve as a worker node of a federated node group |
+| `examine` | read a completed trace: its path by node, contracts, results, events and errors |
+| `behavior-logic` | render a completed trace as a PNG: the path, each route's outcome, and why each node decided as far as the trace records it (drawn from the inspector's `si.execution.explain`; needs `pgc-runtime[render]`) |
 
 `PGC_SNAPSHOT_ROOT` overrides the snapshot location; `PGC_IMPL_ROOTS` is the colon-separated set of
 roots on `PYTHONPATH` for domain capability implementations.
@@ -117,6 +122,12 @@ roots on `PYTHONPATH` for domain capability implementations.
 establishes that the snapshot is intact and executable before any workflow runs. A surface-only
 snapshot has no workflow to traverse, and warm reboot is exactly what proves it sound anyway.
 
+**A process verifies a snapshot once.** `runtime.api` keeps a booted snapshot resident and runs
+against it as often as it is asked. A rewritten manifest, or a different trust anchor or profile
+root, is verified afresh, and a snapshot that no longer verifies is refused. `boot` itself always
+performs the full determination. A governed run then costs a few milliseconds, not a third of a
+second.
+
 **A data root is an instance, not an interface.** Two data roots against the same snapshot are two
 independent instances of the same governed behavior.
 
@@ -128,6 +139,21 @@ invoking transforms, applying side effects — and routes on the declared outcom
 nothing by name at execution time: the compiler assigned integer addresses, and traversal operates
 on those.
 
+**A workflow may run one contract at several places.** Each place is a node key, and the contract
+it runs is named separately. The compiler seals each place's routing on its own, and refuses a sealed
+dispatch that does not realize every transition declared at that node. Routing is by node, and the
+trace names the place that ran.
+
+**Not every step is determined by its inputs.** A transform is a deterministic atom, a
+non-deterministic atom, or a molecule, and a different constitution governs each. A molecule has no
+implementation: the runtime runs its declared steps. A non-deterministic atom's result is recorded
+where it is produced, and `replay` substitutes the recorded result, so a run is reproducible even
+when a step is not.
+
+**One snapshot can run across nodes.** Under a federated placement, a coordinator schedules units of
+work to workers over a shared store. Under the signed federated profile, every node verifies the
+snapshot's signature before it runs anything.
+
 Every step emits evidence. The trace is not a log the runtime chose to write; it is the record of
 the path actually taken through a graph that was fixed before the run began, which is what makes a
 run reproducible and reviewable after the fact.
@@ -146,7 +172,7 @@ Apache-2.0. See `LICENSE` and `NOTICE`.
 | `pgc-assembler` | `snapshot_assembler` | projections → sealed snapshot |
 | `pgc-runtime` | `protocol_runtime` | snapshot → governed execution |
 | `pgc-inspector` | `snapshot_inspector` | snapshot → read-only inspection |
-| `pgc-transformation` | `transformation` | change request → protocol artifacts |
+| `pgc-transformation` | `transformation_compilers` | change request → protocol artifacts |
 | `pgc-governance` | `software_governance` | the governance surface and its capability implementations |
 | `pgc-workloads` | `conformance_workloads` | the workloads that make conformance observable |
 | `pgc-domains` | `business_domains` | the business domain implementations the composed snapshot binds |
@@ -166,26 +192,28 @@ pgc            # reports what is installed and whether the anchor resolves
 
 `PGC_DOMAIN_ROOTS` names an additional domain contributing its own `registry/structures` — the
 directory that *directly contains* it, not the repository above it; pointing one level too high is a
-silent no-op. `PGC_SNAPSHOT_ROOT` is where compiled output is written, and each domain build needs
-its own: every layer's output consolidates into one root, and verification rejects any file in that
-root the current build did not declare. `PGC_SNAPSHOT_PROFILES` is the directory holding snapshot
-profiles, required by the assembler and the runtime alike.
+silent no-op. `PGC_SNAPSHOT_PROFILES` is the directory holding snapshot profiles, required by the
+assembler and the runtime alike.
+
+**Where a build writes is declared, not supplied.** Each build configuration names its root in
+`output_configuration.root`, and every layer's output consolidates there. The compiler does not read
+`PGC_SNAPSHOT_ROOT`; the runtime does, with its own meaning — the assembled snapshot to execute.
 
-`PGC_BUILD_ROOT` is accepted and reported and **nothing reads it** — `PGC_SNAPSHOT_ROOT` is the
-anchor that controls output.
+`PGC_BUILD_ROOT` is accepted and reported and **nothing reads it**.
 
 The full sequence, with the repositories it needs, is in
 [`pgc_install`](https://github.com/protocol-governed-computing/pgc_install).
 
-**Versioning.** Two schemes, and the published version follows the second.
+**Versioning.** Two numbers name two different things.
 
-- **Internal** — each repository's `VERSION` file, a monotonic composition ordinal. PGC versions the
-  composition rather than each repo: they release together and the governance closure forces lockstep,
-  so the ordinal names which composition a repo belongs to. Development happens on `dev/<N>` and each
-  cycle is tagged `release-<N>`. This is not published.
-- **Public** — `PUBLIC_VERSION`, tagged on every component repository. The platform is at **`v3`**.
+- **Published** — this distribution's `version` in `pyproject.toml`. It moves on its own. A release
+  that changes this repository bumps it, and a release that leaves the repository unchanged keeps it.
+- **Composition** — the public identity (`v6`, …) names one composition of the whole family.
+  `pgc_release` records which version of each distribution that composition holds, and `pgc_install`
+  pins exactly those versions.
 
-**The published version is the public one: `v4` is `4.0.0`.** The standard the packages implement is a
-separate artifact on its own track and is not this number.
+Each repository's `VERSION` file holds the workspace's cycle ordinal, which names the `dev/<N>`
+branch. It is development accounting, and it is never published. The standard the packages
+implement is a separate artifact on its own track, and none of these numbers is its revision.
 
 The standard these packages implement is published separately: https://doi.org/10.5281/zenodo.22150616

{pgc_runtime-4.0.0 → pgc_runtime-6.0.0}/pgc_runtime.egg-info/SOURCES.txt

@@ -14,6 +14,7 @@ runtime/api.py
 runtime/boot.py
 runtime/cli.py
 runtime/conformance.py
+runtime/coordinator.py
 runtime/ct_errors.py
 runtime/ct_execute.py
 runtime/ct_executor.py
@@ -21,12 +22,16 @@ runtime/dispatcher.py
 runtime/evidence.py
 runtime/loader.py
 runtime/memory.py
+runtime/replay.py
 runtime/scheduler.py
 runtime/trace_viz.py
 runtime/examine/__init__.py
-runtime/examine/classifier.py
 runtime/examine/cli.py
-runtime/examine/hint_engine.py
-runtime/examine/locator.py
 runtime/examine/parser.py
-runtime/examine/reporter.py
+runtime/examine/reporter.py
+runtime/federation/__init__.py
+runtime/federation/client.py
+runtime/federation/coordinator.py
+runtime/federation/defaults.py
+runtime/federation/store.py
+runtime/federation/worker.py

{pgc_runtime-4.0.0 → pgc_runtime-6.0.0}/pgc_runtime.egg-info/requires.txt

@@ -1,3 +1,6 @@
 
 [reference]
 pgc-governance>=2.0.0
+
+[render]
+pgc-inspector>=6.0.0

{pgc_runtime-4.0.0 → pgc_runtime-6.0.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "pgc-runtime"
-version = "4.0.0"
+version = "6.0.0"
 description = "PGC protocol runtime — executes a sealed snapshot as governed DAG traversal and emits traces (import package: runtime)"
 readme = "README.md"
 requires-python = ">=3.10"
@@ -32,6 +32,9 @@ dependencies = []
 
 [project.optional-dependencies]
 reference = ["pgc-governance>=2.0.0"]
+# The PNG projection (`--behavior-logic`, `behavior-logic`) draws the inspector's explanation of a
+# run. Execution never imports the inspector; only `runtime.trace_viz` does.
+render = ["pgc-inspector>=6.0.0"]
 
 [project.scripts]
 protocol_runtime = "runtime.cli:main"