Repository navigation
Roadmap
Build · Validate · Improve · Scale · Evolve
A transparent record of EveryO's implemented capabilities, verification boundaries, and proposed next-stage engineering priorities.
Home · Framework Architecture · Contributing · Project Governance
Project Maintainer: @krishanth7
Authoritative Roadmap: README.md — Roadmap
Important
Roadmap Status
EveryO's original 10-item roadmap is marked complete in the repository README.
10 of 10 objectives have shipped.
This does not mean every implementation has been validated in every environment. In particular, CUDA execution on real GPU hardware and distributed training across multiple physical machines have documented verification gaps.
All additional priorities proposed in this Wiki are recommendations, not approved commitments.
- Overview
- Project Vision
- Current Development Status
- Original Roadmap Completion
- Milestone 1 — Tensor and Autograd Foundation
- Milestone 2 — Neural Network Capabilities
- Milestone 3 — Training and Optimization
- Milestone 4 — Interoperability
- Milestone 5 — Performance and Scaling
- Milestone 6 — CUDA Acceleration
- Milestone 7 — Distributed Computing
- Milestone 8 — Quantization and Profiling
- Milestone 9 — ONNX Tracing
- Implementation Versus Verification
- Known Technical Limitations
- Proposed Next-Stage Priorities
- Proposed Hardware Validation Program
- Proposed Performance Engineering
- Proposed Distributed Systems Validation
- Proposed Reliability and Compatibility Work
- Proposed Developer Experience Improvements
- Research and Experimental Directions
- Milestone Acceptance Criteria
- Contribution Opportunities
- Roadmap Governance
- Progress Reporting
- Official References
- Next Steps
EveryO is an open-source neural computing framework built around a NumPy-based tensor engine and reverse-mode automatic differentiation.
Its goal is to make neural computing understandable, reproducible, and technically verifiable.
EveryO is designed for:
- Learning.
- Research.
- Experimentation.
- Numerical analysis.
- Teaching.
- Framework development.
The original roadmap focused on extending a foundational neural network framework with modern model architectures, interoperability, and scaling capabilities.
Those original objectives are now implemented.
The next stage should focus on strengthening verification, performance, reliability, and practical usability.
Make neural computing accessible through readable implementations, transparent mathematics, and reproducible experiments.
EveryO emphasizes:
- Understandable implementations.
- Correct automatic differentiation.
- Minimal core dependencies.
- CPU-first functionality.
- Optional acceleration.
- Reproducible experiments.
- Explicit performance measurement.
- Honest reporting of limitations.
BUILD
|
v
TRAIN
|
v
MEASURE
|
v
UNDERSTAND
|
v
ACCELERATE
EveryO is not currently presented as a production-scale replacement for established deep learning runtimes.
Its primary strength is a readable and verifiable implementation of neural computing concepts.
EveryO 0.2.0
Source:
Original Roadmap Completion
████████████████████ 100%
Implemented: 10
Total: 10
Outstanding: 0
This completion percentage describes the original feature roadmap, not overall software maturity.
The package metadata classifies EveryO as alpha software.
| Area | Status |
|---|---|
| Tensor engine | Implemented |
| Automatic differentiation | Implemented |
| Neural network layers | Implemented |
| Recurrent architectures | Implemented |
| Attention and transformers | Implemented |
| Training and optimization | Implemented |
| ONNX interoperability | Implemented |
| Mixed precision | Implemented |
| Quantization | Implemented |
| Profiling | Implemented |
| CUDA extension | Implemented; hardware validation limited |
| Distributed training | Implemented; cross-machine validation limited |
The repository README identifies the following ten completed objectives.
| # | Original Objective | Repository Status |
|---|---|---|
| 1 | Convolution and pooling layers | Complete |
| 2 | Batch and layer normalization | Complete |
| 3 | Recurrent layers, attention, transformers | Complete |
| 4 | Mixed-precision training | Complete |
| 5 | ONNX interoperability | Complete |
| 6 | Distributed training | Complete |
| 7 | GPU-resident tensors | Complete |
| 8 | Multi-node distributed training | Complete |
| 9 | Model quantization and profiling | Complete |
| 10 | Tracing ONNX exporter | Complete |
Complete means that the feature has been implemented according to the repository's documented roadmap.
It does not necessarily mean:
- Production readiness.
- Extensive hardware validation.
- Cross-platform performance parity.
- Support for every model architecture.
- Exhaustive real-world testing.
The official README is the authoritative record of original roadmap completion.
Status: Implemented
The tensor engine is the foundation of EveryO.
- Tensor creation.
- Dtypes.
- Shape handling.
- Broadcasting.
- Indexing.
- Reductions.
- Matrix multiplication.
- Device abstraction.
- NumPy interoperability.
The framework implements reverse-mode automatic differentiation.
import everyo as eo
x = eo.tensor(
[2.0],
requires_grad=True,
)
y = x * x
y.backward()
print(x.grad)Expected gradient:
[4.]
The project uses finite-difference gradient checks and TensorFlow comparisons where applicable.
- Numerical edge cases.
- Gradient stability.
- Error diagnostics.
- Performance regressions.
- Additional tests.
These are ongoing engineering concerns, not unfinished original roadmap items.
Status: Implemented
EveryO supports multiple neural network architecture families.
Implemented:
LinearSequentialReLUDropout
Implemented:
Conv2DMaxPool2DAvgPool2D
Implemented:
BatchNorm1DBatchNorm2DLayerNorm
Implemented:
RNNLSTMGRU
Implemented:
MultiHeadAttentionPositionalEncodingTransformerEncoderBlockTransformerEncoder
import everyo as eo
model = eo.Sequential(
eo.Linear(64, 128),
eo.ReLU(),
eo.Dropout(0.2),
eo.Linear(128, 10),
)Recommended future work:
- Broader architecture testing.
- Improved error messages.
- Better performance diagnostics.
- More educational examples.
Status: Implemented
EveryO includes a training system and optimization utilities.
- Training loops.
- Validation.
- Metrics.
- Early stopping.
- Checkpointing.
- Learning-rate scheduling.
- Gradient clipping.
Implemented optimizers include:
- SGD.
- Momentum.
- Nesterov momentum.
- Adam.
- AMSGrad.
EveryO provides:
eo.autocast
eo.GradScalerThe implementation uses selective float16 computation while preserving float32 master parameters.
The documented CPU mixed-precision path is not a guaranteed speed improvement.
NumPy may perform float16 arithmetic through wider intermediate representations.
- Expanded training diagnostics.
- Better reproducibility reports.
- More extensive mixed-precision tests.
- Performance characterization.
Status: Implemented
EveryO supports optional interoperability with external machine learning tools.
TensorFlow is used for reference comparisons and optional backend functionality.
It is not required for core EveryO operation.
EveryO provides:
eo.export_onnx
eo.run_onnx
eo.onnx_availableThe layer-based exporter supports documented feedforward, convolutional, pooling, normalization, and activation operations.
The tracing exporter supports additional recurrent and attention architectures by recording executed primitive operations.
The repository documents ONNX Runtime comparisons rather than treating successful file creation as sufficient validation.
- Broader operator coverage.
- Improved shape diagnostics.
- Expanded compatibility tests.
- More export examples.
Status: Implemented
EveryO includes performance-related features such as:
- Mixed precision.
- Profiling.
- Quantization.
- Distributed training.
- Optional CUDA acceleration.
Performance claims must be supported by reproducible measurements.
The CLI supports benchmark execution:
everyo benchmark --sizes 128 256 512 1024python benchmarks/benchmark_training.py --epochs 10Improve measurement quality before making broad performance claims.
Status: Implemented, hardware verification incomplete
EveryO includes an optional CUDA extension.
The README documents five CUDA kernels:
- Vector addition.
- Element-wise multiplication.
- ReLU.
- Tiled matrix multiplication.
- Reduction sum.
EveryO provides:
eo.cuda.to_deviceThe GPU-residency design reduces repeated host/device transfers during chained operations.
The repository documents a transfer-counting test using a stand-in for the native extension.
For a ten-operation chain:
With per-operation transfers: 30 crossings
With resident tensor design: 3 crossings
These are documented test results for transfer-counting behavior, not GPU performance measurements.
The README states that CUDA kernel correctness has not been exercised in its GPU-less CI environment.
Real NVIDIA GPU hardware validation is a high-value recommended next step.
Status: Implemented, physical multi-machine validation incomplete
EveryO supports data-parallel training.
The framework uses multiple processes and gradient aggregation.
The repository also implements TCP-based process-group functionality.
The README documents all-reduce testing across separate operating-system processes communicating over TCP.
The repository does not claim completed validation across two physically separate machines.
The documented TCP protocol assumes a trusted network and does not provide transport encryption.
- Test across separate hosts.
- Characterize network failure behavior.
- Measure synchronization overhead.
- Document trusted-network deployment requirements.
Status: Implemented
EveryO provides:
compact = eo.quantize_dynamic(model)The documented implementation uses int8 weights with per-output-channel scaling.
Quantization is a size and numerical-fidelity trade-off in the current implementation.
It should not be advertised as a guaranteed inference-speed improvement.
EveryO provides:
with eo.profile() as run:
model(batch)
run.summary()run.export_chrome_trace("trace.json")- More detailed performance reports.
- Memory profiling.
- Performance regression tracking.
- Benchmark reproducibility.
Status: Implemented
The tracing ONNX exporter completed the original roadmap.
A tracing exporter records the primitive operations executed during a model's forward pass.
This enables export of architectures that are difficult to represent through a simple layer-by-layer mapping.
eo.export_onnx_traced
eo.trace_operations
eo.TRACEABLE_OPERATIONSThe repository reports ONNX Runtime comparisons for:
- RNN.
- LSTM.
- GRU.
- MultiHeadAttention.
- TransformerEncoderBlock.
- TransformerEncoder.
A traced graph represents the execution path used during tracing.
Loop lengths and certain shapes may be fixed by the example input.
EveryO checks proposed dynamic-batch behavior against another batch size and falls back to fixed-batch export when necessary.
- Expanded operator support.
- Better dynamic-shape diagnostics.
- Additional runtime comparisons.
- More explicit unsupported-case reporting.
Feature implementation and feature verification are separate dimensions.
| Status | Meaning |
|---|---|
| Implemented | Feature exists in source |
| Unit-tested | Relevant tests exist and have been run |
| Integration-tested | Interoperability or subsystem behavior has been tested |
| Hardware-validated | Tested on required physical hardware |
| Production-validated | Evaluated in representative production workloads |
| Capability | Implemented | Documented Verification Boundary |
|---|---|---|
| Autograd | Yes | Finite differences |
| Convolution | Yes | Numerical and TensorFlow comparisons |
| Recurrent models | Yes | Functional and numerical tests |
| ONNX tracing | Yes | ONNX Runtime comparisons |
| Quantization | Yes | Numerical fidelity and weight tests |
| Profiling | Yes | Timing and trace tests |
| GPU residency | Yes | Transfer-counting stand-in |
| CUDA kernels | Yes | Real GPU validation not established in CI |
| TCP distributed training | Yes | Separate processes on one host |
| Cross-host distributed training | Implemented path | Two-machine validation not established |
Never convert an implementation claim into an unsupported validation claim.
The README explicitly documents several boundaries.
EveryO is not currently positioned as a production training runtime.
GPU hardware is required to validate native CUDA execution.
TCP process-group behavior has been tested across processes but not across separate physical machines in the documented CI environment.
Tracing may specialize execution paths and shapes.
The existing int8 implementation does not provide a dedicated faster inference kernel.
CPU execution may be slower despite reduced storage precision.
EveryO should not claim superiority over optimized frameworks without representative benchmarks.
The original roadmap is complete.
The following priorities are proposals for a new roadmap, not existing approved commitments.
| Priority | Proposed Work | Expected Value |
|---|---|---|
| P0 | Real CUDA hardware validation | Establish kernel correctness |
| P0 | Cross-host distributed tests | Validate multi-machine behavior |
| P1 | Numerical regression expansion | Strengthen reliability |
| P1 | Cross-platform compatibility | Improve usability |
| P1 | Performance regression tracking | Detect slowdowns |
| P2 | Expanded ONNX coverage | Improve interoperability |
| P2 | Memory and allocation profiling | Improve diagnostics |
| P2 | Documentation and examples | Improve onboarding |
| Research | Optimized quantized inference | Explore performance opportunities |
Priority labels express a recommended ordering only.
Status: Proposed
Validate EveryO's CUDA extension on real NVIDIA hardware.
- Kernel correctness.
- Device-memory safety.
- Boundary dimensions.
- Repeated execution.
- Host/device transfers.
- Numerical tolerance.
- CPU fallback.
Test representative NVIDIA GPU generations where hardware is available.
Record:
- GPU model.
- Driver version.
- CUDA toolkit version.
- Operating system.
- Python version.
- NumPy version.
- EveryO commit.
A hardware validation milestone should not be marked complete until:
- Relevant kernels execute on real hardware.
- Results are compared against trusted CPU references.
- Boundary cases are tested.
- Memory errors are investigated.
- Test evidence is recorded.
Status: Proposed
- Identify bottlenecks.
- Improve benchmark consistency.
- Track regressions.
- Reduce avoidable allocations.
| Category | Suggested Measurement |
|---|---|
| Tensor operations | Latency and throughput |
| Matrix multiplication | Size-dependent performance |
| Convolution | Forward and backward time |
| Training | Epoch time |
| Serialization | Save/load time |
| ONNX export | Export time and correctness |
| Distributed training | Scaling efficiency |
| CUDA | Transfer and kernel timings |
Record:
- Hardware.
- Software versions.
- Input sizes.
- Dtypes.
- Warm-up iterations.
- Repetitions.
- Summary statistics.
- Correctness comparison.
Benchmarks should not be presented as universal performance guarantees.
Status: Proposed
Validate distributed training across at least two physically separate machines.
- Normal all-reduce.
- Different network latencies.
- Rank disconnection.
- Timeout handling.
- Incorrect world size.
- Partial worker failure.
- Repeated initialization.
- Numerical agreement.
The current TCP transport assumes a trusted network.
A future deployment design should assess whether authentication or transport security is required.
Document:
- Hardware.
- Network topology.
- Process count.
- Test results.
- Failure behavior.
- Known limitations.
Status: Proposed
Recommended work:
- More edge-case tests.
- Gradient regression tests.
- Serialization robustness.
- Error-message consistency.
- Deterministic test fixtures.
Test supported Python versions and relevant operating systems.
Ensure optional dependencies remain optional.
Validate:
- Wheel installation.
- Source distribution.
- CLI execution.
- Core imports.
- Examples.
- Optional extras.
Continue reviewing:
- Dependencies.
- Model archive loading.
- Configuration parsing.
- Native memory handling.
Status: Proposed
- Expand API examples.
- Improve architecture explanations.
- Add troubleshooting guides.
- Maintain runnable tutorials.
- Explain limitations clearly.
Potential improvements:
- More informative diagnostics.
- Better environment reporting.
- Clearer optional-backend errors.
- Reproducibility summaries.
- Focused starter issues.
- Better test documentation.
- Clear review expectations.
- Consistent issue descriptions.
Potential tutorials:
- Building an autograd operation.
- Implementing a neural network layer.
- Understanding gradient flow.
- Comparing CPU and CUDA execution.
- Exporting models to ONNX.
Status: Exploratory — Not Committed
Future research could investigate:
- Additional neural network architectures.
- New differentiable operations.
- Optimized inference paths.
- Improved mixed-precision execution.
- Memory-efficient training techniques.
- Expanded model interoperability.
- More efficient distributed synchronization.
A research proposal should identify:
- Problem statement.
- Expected benefit.
- Technical feasibility.
- Alternatives.
- Dependencies.
- Testing methodology.
- Compatibility impact.
- Maintenance cost.
Experimental work should be clearly labeled and should not be presented as stable functionality.
Research proposals require normal technical review and maintainer approval before becoming committed roadmap items.
A roadmap milestone should have measurable completion criteria.
# Milestone: Title
## Status
Proposed
## Objective
What will be achieved?
## Scope
What is included?
## Deliverables
- Deliverable 1
- Deliverable 2
## Verification
- Required tests
- Benchmark evidence
- Documentation evidence
## Dependencies
List prerequisites.
## Limitations
Describe exclusions.
## Acceptance Criteria
- [ ] Implementation complete
- [ ] Tests complete
- [ ] Documentation complete
- [ ] Maintainer review complete
## Decision
PendingA milestone should be marked complete only when its approved acceptance criteria have been met.
Link:
- Pull requests.
- Tests.
- Benchmarks.
- Documentation.
- Review decisions.
The original roadmap is complete, so contributors should use the current issue tracker to find active work.
- Bug fixes.
- Numerical testing.
- Documentation.
- Performance benchmarks.
- CUDA validation.
- Distributed systems testing.
- ONNX compatibility.
- Developer tooling.
git clone https://github.com/krishanth7/EveryO.git
cd EveryO
python -m venv .venv
python -m pip install -e ".[dev]"Activate the virtual environment before installing dependencies.
python -m pytest -qruff check .
ruff format --check .Follow:
EveryO is a maintainer-led project.
The project maintainer sets technical direction and makes final decisions when consensus cannot be reached.
- Open an issue for bounded improvements.
- Use a discussion or design issue for architecture changes.
- Describe trade-offs.
- Identify compatibility impacts.
- Provide verification criteria.
Roadmap changes should be reviewed and documented.
A roadmap item does not guarantee a release date.
Progress should be measured against defined scope.
Original Feature Roadmap
Completed: 10
Total: 10
Completion: 100%
Next-Stage Engineering Program
Status: Not approved as a formal roadmap
Priorities:
- Hardware validation
- Cross-host testing
- Reliability
- Performance
- Compatibility
- Documentation
No completion percentage is assigned to the proposed program because its scope and milestones have not been approved.
Each progress update should distinguish:
- Implemented.
- Tested.
- Verified on required hardware.
- Under review.
- Proposed.
- Deferred.
Use links to actual source changes and test results.
Do not fabricate completion dates, benchmarks, or validation results.
| Resource | Link |
|---|---|
| EveryO Repository | GitHub |
| Original Roadmap | README.md |
| Changelog | CHANGELOG.md |
| Project Configuration | pyproject.toml |
| Architecture | docs/architecture.md |
| Autograd | docs/autograd.md |
| CUDA | docs/cuda.md |
| Scaling | docs/scaling.md |
| API Reference | docs/api-reference.md |
| Examples | examples |
| Tests | tests |
| Issues | GitHub Issues |
| Pull Requests | GitHub Pull Requests |
| Governance | GOVERNANCE.md |
| Contributing | CONTRIBUTING.md |
| Security | SECURITY.md |
Continue with EveryO's community and support documentation.
| Wiki Page | Focus |
|---|---|
| Support and Troubleshooting | Getting help and resolving common issues |
| Frequently Asked Questions | Common technical questions |
| Project Governance | Decision-making and project leadership |
| Contributing | Contributor onboarding |
| Release Process | Release validation and publishing |
Wiki links become active after the corresponding pages are created.
Original Roadmap: 10 / 10 Implemented
Next Recommended Page: Support and Troubleshooting →
Home · Framework Architecture · Project Governance
EveryO — Open Machine Learning. Built for Developers.
Project Maintainer: @krishanth7
Open Source · MIT Licensed · Community Driven
© 2026 EveryO Contributors