1. Overview
2. Project Vision
3. Current Development Status
4. Original Roadmap Completion
5. Milestone 1 — Tensor and Autograd Foundation
6. Milestone 2 — Neural Network Capabilities
7. Milestone 3 — Training and Optimization
8. Milestone 4 — Interoperability
9. Milestone 5 — Performance and Scaling
10. Milestone 6 — CUDA Acceleration
11. Milestone 7 — Distributed Computing
12. Milestone 8 — Quantization and Profiling
13. Milestone 9 — ONNX Tracing
14. Implementation Versus Verification
15. Known Technical Limitations
16. Proposed Next-Stage Priorities
17. Proposed Hardware Validation Program
18. Proposed Performance Engineering
19. Proposed Distributed Systems Validation
20. Proposed Reliability and Compatibility Work
21. Proposed Developer Experience Improvements
22. Research and Experimental Directions
23. Milestone Acceptance Criteria
24. Contribution Opportunities
25. Roadmap Governance
26. Progress Reporting
27. Official References
28. 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:

1. Understandable implementations.
2. Correct automatic differentiation.
3. Minimal core dependencies.
4. CPU-first functionality.
5. Optional acceleration.
6. Reproducible experiments.
7. Explicit performance measurement.
8. 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:

pyproject.toml

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.

The repository README identifies the following ten completed objectives.

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:

• Linear
• Sequential
• ReLU
• Dropout

Implemented:

• Conv2D
• MaxPool2D
• AvgPool2D

Implemented:

• BatchNorm1D
• BatchNorm2D
• LayerNorm

Implemented:

• RNN
• LSTM
• GRU

Implemented:

• MultiHeadAttention
• PositionalEncoding
• TransformerEncoderBlock
• TransformerEncoder

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.GradScaler

The 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_available

The 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 1024

python benchmarks/benchmark_training.py --epochs 10

Improve measurement quality before making broad performance claims.

Status: Implemented, hardware verification incomplete

EveryO includes an optional CUDA extension.

The README documents five CUDA kernels:

1. Vector addition.
2. Element-wise multiplication.
3. ReLU.
4. Tiled matrix multiplication.
5. Reduction sum.

EveryO provides:

eo.cuda.to_device

The 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_OPERATIONS

The 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.

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 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.

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:

1. Problem statement.
2. Expected benefit.
3. Technical feasibility.
4. Alternatives.
5. Dependencies.
6. Testing methodology.
7. Compatibility impact.
8. 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

Pending

A 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 -q

ruff check .

ruff format --check .

Follow:

CONTRIBUTING.md

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.

GOVERNANCE.md

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.

Continue with EveryO's community and support documentation.

Wiki links become active after the corresponding pages are created.