paramesh 1.1.0__tar.gz

paramesh-1.1.0/ARCHITECTURE.md

@@ -0,0 +1,180 @@
+# Architecture
+
+## Control plane
+
+One coordinator serves one immutable run configuration. Configuration includes
+the run ID, fixed worker membership, ordered shard endpoints, synchronization mode,
+learning rate, aggregation rule and barrier timeout. Run creation is currently a
+local JSON configuration operation, not a mutable remote API.
+
+Workers register using protocol version 1 and an allowed worker ID. A random
+session token identifies a control-plane lease. A live identity cannot be claimed
+twice. The coordinator uses a monotonic clock: a node is initially `registered`,
+then `healthy` after a heartbeat, `suspect` after 5 seconds and `unavailable` after
+15 seconds. Thresholds can be set when constructing the coordinator. A completed
+worker remains `completed`, rather than appearing as a failed node later.
+
+Expired workers may register a fresh control-plane session; old tokens cannot
+send heartbeats. The coordinator durably reserves a monotonically increasing
+generation, fences it on every shard, then issues the new session. An interrupted
+partial fence never reuses a generation. Shard updates reject superseded generations.
+
+Run configuration, generation counters and progress survive in checksummed SQLite
+state. Restart invalidates prior leases and requires re-registration; it does not
+pretend saved monotonic-clock timestamps are live leases. `global_step` is a
+reported completed-step lower watermark across configured workers, not a global
+atomic model version. Shard endpoints remain configured; dynamic registration
+and coordinator replication are not implemented.
+
+## Data plane and ownership
+
+Workers talk directly to shards over gRPC. Parameter ownership is:
+
+```text
+int.from_bytes(sha256(parameter_name.encode()).digest()[:8], "big") % shard_count
+```
+
+Shard index is the endpoint's position in the immutable configuration. Python's
+randomized built-in hash is never used. Renaming a parameter or changing the
+shard count can move ownership; live resharding is unsupported. Whole tensors
+are assigned to shards, so load can be uneven and shards can be empty for very
+small models. The two-shard MLP test asserts both shards own parameters.
+
+The worker model performs forward and backward passes with PyTorch. Each shard
+stores float32 NumPy weights and applies SGD itself. Plain SGD has no momentum
+or Adam state; weights, version and replay receipts are authoritative. Supporting
+a stateful optimizer will require including its state in checkpoints.
+
+## Protocol and validation
+
+Source: `proto/paramesh/rpc/training.proto`; package: `paramesh.v1`. Python bindings
+and message `.pyi` files are generated and checked into source control. CI compares
+fresh generation with committed bytes. New compatible fields can be added without
+reusing existing field numbers. The wire version is early and not a stable public
+API commitment yet.
+
+Tensors carry a name, shape, explicit `float32-le` dtype and little-endian bytes.
+The decoder allows at most eight dimensions, 4 MiB per tensor, 1,024 tensors and
+8 MiB of tensor data per collection. RPC messages themselves are capped at 8 MiB,
+including protobuf overhead. Scalars are allowed; zero-sized tensors are not.
+Neither network endpoints nor model loading accept arbitrary Python object files.
+
+Each update validates run identity, configured worker membership, exact parameter
+names and shapes, dtype, payload length, finite values, update sequence and base
+version. Decoding happens before entering the optimizer critical section. A
+condition lock serializes commits. Proposed new weights are computed separately
+and checked for overflow before replacing any authoritative weight.
+
+## Versions, sequence numbers and retries
+
+Each shard has its own monotonically increasing version, starting at zero.
+Every accepted optimizer step increments it once, even for an empty shard. A
+worker's update sequence starts at zero and increases by one per local iteration.
+These are distinct counters: async shard versions count every worker's updates.
+
+The shard remembers the latest accepted sequence, SHA-256 request fingerprint,
+resulting version and staleness for each configured worker. An identical retry
+returns that receipt without applying SGD again. A changed retry or sequence gap
+is rejected. Memory is bounded by membership and one in-flight barrier. Older
+receipts are not retained. Weights, SGD configuration, versions, receipts and fences
+are committed together to SQLite WAL with `synchronous=FULL` before acknowledgement.
+This supports retry after a process restart when the volume survives; it is not
+an exactly-once delivery claim after storage loss.
+
+Workers use explicit RPC deadlines and retry transient unavailable/deadline errors
+at most three times with short backoff. They reuse the original request bytes;
+they do not recompute a gradient after an ambiguous transport failure. Calls use
+wait-for-ready within their deadlines so reconnection can outlast a transient
+failure rather than exhausting retries immediately. A test
+simulates losing the response after commit and verifies one update, not two.
+
+## Synchronization
+
+### Synchronous
+
+Every worker submits one gradient per version. The shard accumulates a fixed
+membership barrier, computes mean or sum and commits one SGD update. Float64
+accumulation reduces summation overflow before conversion to float32 weights.
+Mean gives equal weight to each worker, which is equivalent to the demo's local
+reference because each worker has the same number of examples.
+
+A shared deadline takes the earliest participant deadline, capped by the configured
+barrier timeout. Late final arrivals cannot commit merely because an expired
+waiting thread has not resumed yet. A timeout clears that shard's pending contributions and wakes waiting calls.
+Membership is not silently reduced. The server's RPC thread limit exceeds the
+configured worker count, preventing waiting participants from starving the final
+arrival. No distributed commit ties separate shard barriers together.
+
+### Asynchronous
+
+Each valid gradient commits immediately. Staleness is `current_shard_version -
+base_version` and is returned to the worker. Ordering depends on process and
+network scheduling; async training is not expected to match synchronous SGD.
+
+### Bounded lag
+
+An update whose shard-local staleness exceeds `max_staleness` receives
+`FAILED_PRECONDITION`. The worker pulls fresh weights and recomputes gradients
+for contributions that have not yet committed in its current iteration. Already
+accepted shards are not submitted again with changed contents. Refreshes are
+bounded to 100 attempts; exhaustion fails the worker visibly.
+
+Consequently a worker iteration can combine contributions computed from different
+model snapshots. The bound is enforced at each shard's acceptance point. There is
+no single global version, atomic multi-shard pull or classic SSP worker-clock bound.
+
+## Failure and admission boundaries
+
+Missing workers abort local synchronous barriers; membership is not silently
+reduced. A worker journals complete gradient requests before sending them. After
+restart it reads each shard's progress, skips completed contributions and finishes
+the original pending step under its replacement generation. Fingerprints exclude
+only generation metadata, so replacing a worker cannot change an already committed
+gradient. Fresh bounded-mode recomputation only changes uncommitted contributions.
+
+Shard restart reloads the last durable weights and receipts before serving traffic.
+Tests actually terminate worker/shard processes and compare the completed sync run
+with local SGD. State files have an OS-owned single-writer lock released on exit
+or process death, preventing overlapping writers from corrupting worker journals.
+Whole-run offline checkpoints preserve coordinator metadata, shard snapshots and
+worker journals together. Export holds all source database leases; restore validates
+every object before publishing fresh state. A partial multi-shard step retains its
+original gradient bytes. Local and S3-compatible immutable stores publish manifests
+last; an interrupted upload is not restorable. See [the recovery design](docs/recovery-design.md)
+and [operator commands](docs/checkpoints.md). Live peers must never be mixed with
+an older restored shard. Topology remapping and online coordinated cuts are unsupported.
+
+gRPC admission is bounded to `2 * worker_count + 4` concurrent calls per shard;
+excess requests receive resource exhaustion. Workers issue one gradient push at
+a time. These limits do not replace deployment resource limits or provide a full
+cluster-wide backpressure scheme. No unbounded training request queue is added.
+
+## Deployment and evidence
+
+The native demo spawns separate processes with OS-assigned loopback ports. It
+waits for readiness, starts workers, collects final parameters and compares sync
+weights against concatenated-data PyTorch SGD. Its control pipes are trusted,
+local parent-child IPC, never the training transport.
+
+Compose defines separate containers with an internal network, dropped capabilities,
+read-only filesystems, five persistent volumes and no public training ports. Local
+container verification checks actual training, role enforcement, clean shutdown
+and state-preserving recreation. A large dependency download was completed in
+validated ranges and matched PyTorch's published SHA-256; the local bootstrap
+mirror did not change the installed package. Normal Git-backed builds use the
+default official CPU index. No Coolify, k3s, AWS or Azure deployment has been exercised.
+
+The optional SeaweedFS storage profile has a private network and a persistent volume.
+The maintenance helper receives storage credentials and can reach external endpoints;
+training containers receive neither storage credentials nor a public route.
+The optional operations profile adds a separate lifecycle event plane and telemetry
+backends. NATS carries bounded allowlisted events, never gradient traffic. Broker
+failure does not participate in registration, fencing, SGD or durable receipts.
+Prometheus scrapes process/RPC metrics; OTel propagates gRPC trace context to Tempo.
+The dashboard persists up to 200 validated events and mirrors them to Loki.
+Its sampler uses read-only RPCs and fixed backend queries; its browser receives
+neither data-plane nor administrative credentials. UI and Grafana publish loopback
+ports through a management network, while internal networks keep training and
+operations services private. See [operations](docs/operations.md) for definitions
+and failure limits. Azure Blob checkpoints are verified against Azurite; online
+checkpoint coordination and hosted validation remain future work.

paramesh-1.1.0/BENCHMARKS.md

@@ -0,0 +1,238 @@
+# Correctness evidence and benchmark methodology
+
+The `demo` command is a CPU correctness run, not a performance benchmark.
+It runs real training in independent processes and exports a JSON report:
+
+```powershell
+paramesh demo --mode sync --workers 2 --shards 2 --steps 20 --output artifacts/sync.json
+paramesh demo --mode async --workers 2 --shards 2 --steps 20 --output artifacts/async.json
+paramesh demo --mode bounded --workers 2 --shards 2 --steps 20 --output artifacts/bounded.json
+```
+
+## Numerical reference
+
+### Captured CPU evidence
+
+These are actual 20-step runs at commit
+`fca471cdfaa0e12bd8dcf212323b7013685e895d` with a clean working tree, recorded
+on November 1, 2026 using Windows AMD64, Python 3.12.10 and PyTorch 2.15.0+cpu.
+Each run used two workers and two nonempty shards; both workers completed.
+
+| Mode | Initial MSE | Final MSE | Final shard versions | Max absolute error vs local SGD | Raw artifact |
+| --- | --- | --- | --- | --- | --- |
+| Sync | 14.232687 | 0.733824 | 20, 20 | 5.96e-8 | [JSON](docs/evidence/sync-cpu.json) |
+| Async | 14.232687 | 0.538783 | 40, 40 | Not equivalent | [JSON](docs/evidence/async-cpu.json) |
+| Bounded | 14.232687 | 0.508454 | 40, 40 | Not equivalent | [JSON](docs/evidence/bounded-cpu.json) |
+
+These final losses are single-run observations, not a convergence ranking. Async
+and bounded runs have twice as many shard SGD updates as sync for the same local
+worker iteration count. Their artifacts were collected concurrently, so wall
+times must not be used for a performance comparison. No CPU/RAM inventory or
+steady-state benchmark was collected for these correctness runs.
+
+The sync reference uses the same seeded MLP initialization, concatenates the same
+32-example worker datasets and applies PyTorch SGD for the same number of steps.
+Worker mean-reduced MSE gradients are averaged by each shard. Since worker batches
+are equal-sized, that matches the reference objective. Tests require maximum
+absolute parameter difference below `1e-6` and loss reduction.
+
+Async and bounded runs assert completion, expected shard update counts and loss
+reduction for this workload. They are not compared numerically to sync because
+their update order and model snapshots differ. This is not a general convergence
+guarantee for arbitrary models or learning rates.
+
+## Report fields and limitations
+
+Reports include worker/shard counts, process count, version counters, ownership,
+initial/final full-dataset loss, worker-local pre-update losses, refresh counts,
+reference error, Python/PyTorch/OS/architecture, timestamp and Git commit/dirty state.
+The workload description records model dimensions, seeds, batch size, learning
+rate, optimizer, aggregation, CPU device and thread count. Unknown Git provenance
+is labeled `unknown`, such as when using a wheel outside a checkout.
+
+`worker_wall_seconds_including_startup` begins before workers are spawned and ends
+when their results arrive. It includes imports, startup, training and final heartbeat;
+it excludes shard/coordinator startup, cleanup and the local reference. It is not
+steady-state throughput or an RPC latency metric. No speedup, scaling efficiency,
+compression gain or cloud performance is claimed. Recovery timings below use a
+separate deliberately paced fault scenario.
+
+## Captured process recovery
+
+Clean source `f92103a92071a339253fcad5203642151af650ad`, Windows AMD64,
+Python 3.12.10/PyTorch 2.15.0+cpu, November 1, 2026. Two workers/two shards,
+20 synchronous steps, 0.1-second deliberate per-step delay. Test leases are
+1.5 seconds suspect / 3 seconds unavailable, not the default 5 / 15 seconds.
+
+| Actual terminated process | Detection | Time from termination to later progress | Final shard versions | Raw report |
+| --- | --- | --- | --- | --- |
+| Worker 0 | 3.000 s heartbeat lease | 7.047 s | 20, 20 | [worker recovery](docs/evidence/worker-recovery.json) |
+| Shard 0 | 0.562 s observer RPC failure | 4.828 s | 20, 20 | [shard recovery](docs/evidence/shard-recovery.json) |
+
+Both runs finish with maximum parameter error `5.96e-8` against uninterrupted local
+SGD. The worker replacement advances generation 1 to 2 and resumes from durable
+step 7. These single-run timings include replacement process startup/imports;
+they are not recovery SLAs or steady-state benchmarks. These particular runs did
+not replay an in-flight contribution. A separate checkpoint/RPC integration test
+forces partial delivery and verifies one replay without duplicate application.
+Uncommitted computation lost before journaling is not instrumented.
+
+## Controlled uncompressed framework
+
+```powershell
+uv sync --locked --all-extras --python 3.12
+.\.venv\Scripts\Activate.ps1
+paramesh benchmark --output artifacts/baseline --warmup-steps 20 --steps 200 --repetitions 3
+```
+
+Use a fresh output directory: existing results are never overwritten. Each trial
+creates separate authenticated coordinator/shard/worker processes and fresh durable
+state. Workers finish warm-up, wait until every peer is ready, then begin a measured
+session in the same already imported processes. The session includes channel setup,
+replacement registration/fencing and final heartbeat. Its throughput is explicitly
+**warm-process session throughput**, not pure steady-state compute throughput.
+The original startup-inclusive demo duration remains separate.
+
+Modes run sequentially with their order rotated between repetitions. The workload
+remains the seeded CPU 4→8→1 MLP and repeated 32-example batch per worker, with one
+Torch thread per process, float32 transport, durable SQLite commits and no deliberate
+step delay. Bounded mode uses the existing shard-local lag limit of 1; the complete
+RunConfig and warm-up session durations are preserved in each raw trial.
+Trace/network exporters are disabled; bounded client RPC recording is
+enabled consistently across modes. Instrumentation overhead is included and not
+calibrated away. This is a small-model protocol/storage-overhead experiment.
+
+| Artifact | Meaning |
+| --- | --- |
+| `trial-NNN-mode.json` | Complete actual trial, losses, versions, provenance and raw client RPC samples |
+| `rpc.csv` | One observed client attempt: method/status, elapsed seconds and protobuf request/response bytes |
+| `trials.csv` | Measured window, processed examples, latency percentiles, payload totals, loss and shard-commit deltas |
+| `manifest.json` | Configuration, host CPU/RAM/clock, lock hash, actual trial order and completion/failure status |
+| `overview.png` / `.svg` | Recorded trial dots, median and observed range; no confidence-interval claim |
+
+Use `--hidden-width 256` to repeat the same seeded workload with a larger MLP and
+measure substantially larger raw float32 gradient messages. The default width 8
+preserves the original tiny baseline. Width is recorded in the manifest and every
+trial; it changes the model computation and payload together, so larger-width
+throughput is not a pure transport measurement. Keep correctness/reference checks
+enabled and compare actual RPC payload bytes. This loopback benchmark does not model
+cross-host bandwidth or establish that compression will help. Large widths can
+destabilize this fixed-learning-rate workload; failed numerical checks invalidate
+the trial rather than producing performance evidence.
+
+### External workloads
+
+The same benchmark API accepts a `TrainingWorkload` with top-level, spawn-safe
+model and batch factories. The bundled CLI remains the deterministic MLP default;
+custom workloads can use the runnable example:
+
+```powershell
+python examples/external_benchmark.py --output artifacts/external-linear
+```
+
+This records the external model, raw RPC observations, mode-specific results,
+source metadata and numerical checks in the same artifact schema. Keep the model,
+dataset, optimizer and update budget identical when comparing modes; the existing
+warnings about different commit semantics still apply.
+
+Completed manifests can be shown in the authenticated dashboard Evidence page by setting
+`PARAMESH_EXTERNAL_ARTIFACTS_DIR` to the artifact directory before starting the operations
+Compose profile (for example, `python scripts/quickstart.py --no-build`).
+Rows are labeled `external workload` and remain read-only post-run evidence; the dashboard does
+not claim live monitoring of a separate external process harness.
+
+Each worker records start/end with the same host's system-wide monotonic performance
+clock. The aggregate window spans the earliest measured start through the latest
+end, excluding result serialization and model evaluation. Processed examples equal
+the verified measured worker iterations times batch size; they are not unique data.
+Client latency includes the interceptor/application path and server waits, including
+synchronous barriers and durable commits. P95 uses the successful observed calls in
+each trial; failures remain in the raw CSV and payload totals. Bytes exclude HTTP/2,
+TLS and NIC overhead. Captured records contain sizes/statuses, never tensor values
+or authentication metadata. Capture overflow fails the benchmark result.
+
+Equal worker iterations cause different SGD commit counts in sync versus async or
+bounded mode. Compare convergence and update budgets alongside throughput; do not
+turn a mode's rate into a claim of equal-quality training speedup. Three repetitions
+describe observed variability and do not establish statistical significance.
+
+The host is an ordinary workstation with background applications and the retained
+operations stack running. CPU/memory/clock metadata make that context inspectable,
+but do not establish resource isolation or multi-machine network performance.
+Completed trial artifacts survive a later failure/interruption; a completed run's
+numerical-failure diagnostics are written before validation raises. A mid-trial
+termination may yield only failure status, rather than a complete raw result.
+Only successful complete output may support a measurement claim. CI's small test runs verify framework behavior,
+not a performance baseline. [The design contract](docs/benchmark-design.md) records
+the boundaries; [Python clock semantics](https://docs.python.org/3.12/library/time.html)
+and [Matplotlib export](https://matplotlib.org/stable/api/_as_gen/matplotlib.figure.Figure.savefig.html)
+support the timing and chart implementation.
+
+### ParamMesh versus a local PyTorch reference
+
+The scaling-matrix helper measures the same seeded workload through the existing
+ParamMesh process harness and a single-process PyTorch SGD reference:
+
+```powershell
+python examples/scaling_matrix.py `
+  --output artifacts/scaling-matrix `
+  --workers 1 2 4 `
+  --repetitions 3 `
+  --warmup-steps 20 `
+  --steps 200
+```
+
+Each worker count gets raw ParamMesh and reference JSON, a combined `trials.csv`,
+an environment/lock manifest, and a chart. The reference uses the same model
+factory, worker datasets, optimizer, steps and CPU thread limit; the comparison
+therefore describes protocol overhead and scaling behavior for that workload, not
+model quality or a universal speedup. Add `8` only when the host has enough
+isolated CPU capacity. Failures are preserved in the manifest and invalidate a
+performance claim rather than being treated as missing samples.
+
+The clean-source one-repetition smoke capture is preserved in
+[`docs/evidence/benchmarks/scaling-matrix-local-2026-11-07/`](docs/evidence/benchmarks/scaling-matrix-local-2026-11-07/README.md).
+The first three-repetition 1/2/4-worker capture is preserved in
+[`docs/evidence/benchmarks/scaling-matrix-local-2026-11-07-three-repetition/`](docs/evidence/benchmarks/scaling-matrix-local-2026-11-07-three-repetition/README.md).
+Both retain raw output with the same metadata and checksum rules.
+
+## Remaining performance work
+
+### Repeated local fault trials
+
+`paramesh recovery-benchmark --output artifacts/recovery-trials --repetitions 3`
+repeats the existing real 20-step synchronous worker-kill and shard-kill scenarios
+in fresh processes and durable state. It alternates fault order, retains each raw
+JSON run, writes a manifest with hardware/lock/provenance and `trials.csv`, and plots
+individual observations with median and observed range. It refuses an existing output
+directory and keeps completed reports if a later trial fails. Every recorded success
+requires both shards at version 20, completed workers, a positive detection-to-progress
+interval and maximum error below `1e-6` against uninterrupted local SGD.
+
+The worker detection observation is the coordinator's 3-second unavailable lease;
+the shard observation is a failed 0.5-second RPC probe. They are different detection
+mechanisms, so compare each to its own behavior. The run includes a deliberate
+0.1-second per-step delay and process replacement/import time. Termination-to-progress
+is not full job recovery or an SLA. The harness does not instrument uncommitted
+computation lost before journaling; it cannot claim zero lost work. CI's single
+repetition checks the CLI and dependencies, not a statistical baseline.
+
+The [recorded local uncompressed baseline](docs/evidence/benchmarks/uncompressed-local-2026-11-02/README.md)
+preserves nine clean-source trials, the exact dependency lock, raw RPC observations,
+checksums and generated charts. Median warm-process rates were 4,119 / 4,562 / 4,999
+processed examples/s for sync / async / bounded respectively. Different update
+budgets prevent treating those rates as equal-quality speedups. The 196-byte model
+gradient provides no evidence of a network-bandwidth bottleneck, so this dataset
+does not justify adding compression.
+
+The operations milestone exposes real protobuf bytes, RPC duration histograms,
+worker steps/examples, pre-update loss and accepted staleness. Its deliberately
+paced synthetic dashboards are operational evidence, not comparative performance
+benchmarks. [The stack report](docs/evidence/operations-stack.json) verifies actual
+backend integration at 100 steps; it records its development source identity.
+Native worker/shard fault reports above remain the numerical correctness reference.
+
+Broader model/payload sizes, resource isolation, strong/weak scaling, multi-host
+network conditions and compression experiments require separate controlled runs.
+Compression must be justified by measured payload/bottleneck evidence. Failure
+timings require real termination and verified restoration, not simulated statuses.

paramesh-1.1.0/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

paramesh-1.1.0/MANIFEST.in

@@ -0,0 +1,4 @@
+recursive-include proto *.proto
+recursive-include scripts *.py
+recursive-include examples *.json *.py
+include ARCHITECTURE.md BENCHMARKS.md SECURITY.md ROADMAP.md