Repository navigation
Development Roadmap
Build · Verify · Improve · Release
A transparent overview of implemented capabilities, outstanding validation, proposed engineering priorities, and release-readiness requirements.
Home · Framework Architecture · Contributing · Release Process
Repository: krishanth7/EveryO
Maintainer: @krishanth7
Roadmap type: Current-state summary and proposed future direction
Important
Roadmap Status
The repository README marks the original ten roadmap objectives as implemented. This page therefore focuses on validation, hardening, compatibility, performance, and maintainability rather than presenting those original objectives as unfinished.
Future milestones in this Wiki are proposals, not approved commitments. No release date, performance improvement, or production-readiness claim is guaranteed.
- Executive Overview
- Project Vision
- Current Development Status
- Original Roadmap Completion
- Roadmap Principles
- Engineering Workstreams
- Milestone A — Baseline Verification
- Milestone B — Numerical Reliability
- Milestone C — GPU Validation
- Milestone D — Distributed Validation
- Milestone E — Interoperability
- Milestone F — Performance
- Milestone G — Developer Experience
- Milestone H — Security and Hardening
- Milestone I — Release Readiness
- Technical Priorities
- Proposed Release Strategy
- Acceptance Criteria
- Testing Strategy
- Performance Measurement
- Risk Register
- Prioritization Framework
- Contribution Opportunities
- Roadmap Governance
- Progress Reporting
- Frequently Asked Questions
- Official References
- Closing Statement
EveryO is an open-source neural computing framework designed for readable implementations, reproducible experiments, and numerical verification.
Its foundational capabilities are implemented, including tensor computation, automatic differentiation, neural network modules, optimizers, training utilities, model serialization, and optional interoperability and acceleration features.
The next stage of development should emphasize evidence-based reliability.
| Area | Current Position |
|---|---|
| Package version | 0.2.0 |
| Development classification | Alpha |
| Core tensor engine | Implemented |
| Automatic differentiation | Implemented |
| Neural network modules | Implemented |
| Training and optimization | Implemented |
| Model serialization | Implemented |
| ONNX interoperability | Implemented for supported models |
| Mixed precision | Implemented |
| Quantization | Implemented |
| Profiling | Implemented |
| CUDA | Implemented; hardware validation limited |
| Distributed execution | Implemented; multi-machine validation limited |
| Production readiness | Not claimed |
IMPLEMENTED FRAMEWORK
|
v
BASELINE VERIFICATION
|
v
NUMERICAL HARDENING
|
+------+------+
| |
v v
GPU VALIDATION DISTRIBUTED VALIDATION
| |
+------+------+
|
v
INTEROPERABILITY TESTING
|
v
PERFORMANCE EVIDENCE
|
v
RELEASE READINESS
The diagram represents a proposed engineering sequence, not an approved release schedule.
EveryO aims to make neural computing understandable and inspectable.
The framework prioritizes:
- Transparent implementations.
- Correct mathematical behavior.
- Reproducible experiments.
- CPU-first accessibility.
- Optional hardware acceleration.
- Explicit documentation of limitations.
- Sustainable open-source maintenance.
The proposed long-term direction is a dependable experimental framework with clearly documented capabilities and limitations.
This does not imply an intention to compete directly with large-scale production training frameworks on throughput or ecosystem size.
The repository currently declares:
[project]
name = "everyo"
version = "0.2.0"
requires-python = ">=3.9"The package metadata classifies EveryO as alpha software.
Three states must remain distinct.
Implemented
The functionality exists in source code.
Verified
Defined tests have demonstrated the expected behavior in specified environments.
Production-ready
Operational reliability, compatibility, security, and support requirements have been established for the intended production use.
Implementation alone does not establish production readiness.
The repository README describes the original roadmap as complete.
Its implemented capabilities include:
| Capability | Status |
|---|---|
| Tensors and mathematical operations | Implemented |
| Reverse-mode autograd | Implemented |
| Neural network layers | Implemented |
| Optimizers and losses | Implemented |
| Dataset and training utilities | Implemented |
| Serialization | Implemented |
| Optional CUDA | Implemented |
| Mixed precision | Implemented |
| ONNX export | Implemented |
| Quantization, profiling, and distributed utilities | Implemented |
The implementation of these features does not mean every workload, hardware platform, tensor shape, or distributed configuration has been validated.
The README specifically identifies remaining validation limitations for CUDA and multi-machine distributed execution.
Future development should follow six principles.
Numerical correctness must be established before claiming an optimization is beneficial.
Optional acceleration should not make the core framework dependent on a GPU.
Experiments and benchmarks should include sufficient information to reproduce their results.
Supported Python versions, devices, dtypes, and export formats should be documented.
Changes should avoid unnecessary attack surfaces and unauthorized data transmission.
New functionality should justify its ongoing maintenance cost.
The following workstreams are proposed.
| Workstream | Focus | Priority Proposal |
|---|---|---|
| Numerical correctness | Gradients, stability, edge cases | P0 |
| GPU validation | Real-device tests and diagnostics | P0 |
| Distributed validation | Cross-machine execution | P1 |
| Serialization security | Malformed input and compatibility | P0 |
| ONNX interoperability | Export fidelity and shape handling | P1 |
| Performance | Reproducible benchmarking | P1 |
| Developer experience | Documentation and diagnostics | P2 |
| Release engineering | Artifacts, compatibility, process | P1 |
P0: Highest proposed priority.
P1: Important proposed priority.
P2: Useful improvement.
These priorities are recommendations and require maintainer acceptance.
Proposed objective: Establish a reproducible baseline for the current implementation.
- Confirm package installation on supported Python versions.
- Run the complete CPU test suite.
- Verify formatting and linting.
- Record optional dependency behavior.
- Validate CLI diagnostic commands.
- Confirm examples execute as documented.
python -m pip install -e ".[dev]"
python -m pytest -q
ruff check .
ruff format --check .
everyo doctor- Supported environments install successfully.
- Core tests pass.
- Optional tests skip cleanly when dependencies are unavailable.
- Documentation matches observed behavior.
- Failures have reproducible reports.
- Test summary.
- Compatibility matrix.
- Known limitations register.
- Reproducibility instructions.
Proposed objective: Expand confidence in tensor and gradient correctness.
- Broadcasting.
- Indexing.
- Reductions.
- Matrix multiplication.
- Convolution.
- Normalization.
- Recurrent operations.
- Attention.
- Loss functions.
For differentiable functions, compare analytical gradients against central finite differences:
\frac{f(x+h)-f(x-h)}{2h} ]
Compare the result with the autograd gradient using appropriate absolute and relative tolerances.
Proposed cases include:
- Scalar tensors.
- Singleton dimensions.
- Broadcast dimensions.
- Non-square matrices.
- Extreme input magnitudes.
- Empty or invalid inputs where applicable.
- Repeated backward operations.
- Non-contiguous arrays.
- Numerical overflow and underflow.
- New tests have defined expected behavior.
- Numerical tolerances are documented.
- Regressions are reproducible.
- No unsupported precision guarantees are introduced.
Proposed objective: Verify EveryO's CUDA implementation on compatible NVIDIA hardware.
The repository documents five native CUDA kernels:
- Vector addition.
- Element-wise multiplication.
- ReLU.
- Tiled matrix multiplication.
- Reduction sum.
- Build the native extension on supported toolchains.
- Run real-device tests.
- Compare outputs against NumPy.
- Test boundary dimensions.
- Test repeated allocations and deallocations.
- Verify error handling.
- Check device memory behavior.
- Document hardware and driver versions.
python -m pip install -e ".[cuda]"
./scripts/build_cuda.sh- Native extension builds successfully in documented environments.
- Supported operations match reference results within defined tolerances.
- Device errors are reported clearly.
- CPU-only execution remains unaffected.
A successful CI build does not establish successful GPU execution.
Proposed objective: Validate distributed execution beyond same-host process tests.
EveryO includes data-parallel utilities and a TCP-based process group.
- Test execution on two physical machines.
- Verify gradient synchronization.
- Validate collective operation behavior.
- Test worker failure scenarios.
- Measure communication overhead.
- Document network assumptions.
- Test reproducibility across worker counts.
The documented TCP process-group protocol assumes a trusted network and does not provide transport encryption.
Untrusted-network deployment should not be represented as supported without appropriate security changes.
- Cross-machine execution is reproducible.
- Numerical agreement is measured.
- Failure behavior is documented.
- Network and security limitations are explicit.
Proposed objective: Improve confidence in model exchange and external reference comparisons.
Test:
- Supported feedforward models.
- Convolution and pooling layouts.
- Recurrent models.
- Attention models.
- Static shape behavior.
- Conditional dynamic-batch support.
Maintain numerical comparisons for supported operations.
A valid ONNX file is not sufficient evidence of correct model behavior.
Exported models should be executed through ONNX Runtime and compared with EveryO outputs.
- Supported model families have round-trip or export verification.
- Numerical differences are recorded.
- Shape restrictions are documented.
- Unsupported operations fail clearly.
Proposed objective: Establish trustworthy performance measurements.
- Tensor operations.
- Matrix multiplication.
- Forward passes.
- Backward passes.
- Optimizer updates.
- Model training.
- Serialization.
- ONNX inference.
- Optional CUDA execution.
Every published benchmark should record:
EveryO version:
Python version:
Operating system:
CPU:
GPU:
RAM:
NumPy version:
Input shape:
Input dtype:
Warm-up runs:
Measured runs:
Statistic:
Reference implementation:
- Use equivalent workloads.
- Separate warm-up from measurement.
- Record variability.
- Avoid cherry-picked results.
- Publish reproducible commands.
Performance claims are supported by repeatable measurements and documented methodology.
Proposed objective: Make EveryO easier to install, understand, debug, and contribute to.
Potential improvements:
- Installation troubleshooting.
- Architecture diagrams.
- Complete API examples.
- Numerical correctness explanations.
- CUDA setup instructions.
- Model export limitations.
- Contribution tutorials.
Potential improvements:
- More actionable diagnostics.
- Clearer optional dependency errors.
- Environment summaries.
- Improved benchmark reporting.
Examples should:
- Run with documented dependencies.
- Use supported APIs.
- Avoid fabricated results.
- Include expected shapes.
- Explain numerical assumptions.
New contributors can reproduce the documented development workflow without undocumented manual steps.
Proposed objective: Strengthen security validation around supported interfaces.
Review .evo archive handling for:
- Malformed metadata.
- Unexpected file structures.
- Excessive archive sizes.
- Invalid parameter shapes.
- Unsupported module types.
- Path traversal risks.
- Resource exhaustion.
Review dependency updates for:
- Compatibility.
- Security advisories.
- License obligations.
- Reproducible builds.
Review:
- Buffer boundaries.
- Memory ownership.
- Error handling.
- Device allocation behavior.
- Identified issues have documented resolutions.
- Security-sensitive tests are added where practical.
- The security policy accurately describes supported versions.
- No new unauthorized telemetry or network activity is introduced.
Proposed objective: Establish measurable criteria for future releases.
- Tests pass on supported environments.
- Formatting and linting pass.
- Package artifacts build.
- Documentation is updated.
- Changelog entries are reviewed.
- Compatibility changes are documented.
- Known limitations are published.
- Release artifacts are verified.
Potential artifacts include:
- Source distribution.
- Python wheel.
- Release notes.
- Compatibility notes.
- Test summary.
A release should be reproducible and its limitations clearly stated.
Maintain:
- Correct broadcasting.
- Consistent dtype behavior.
- Reliable shape validation.
- Predictable device handling.
Maintain:
- Correct gradient accumulation.
- Stable graph traversal.
- Clear backward semantics.
- Regression coverage.
Maintain compatibility for existing modules while expanding test coverage for edge cases.
Verify optimizer state updates and numerical behavior.
Improve diagnostics for:
- Invalid inputs.
- Non-finite losses.
- Gradient clipping.
- Checkpoint restoration.
- Evaluation behavior.
Improve validation and documentation for batching, preprocessing, and reproducibility.
This section is a proposed framework, not an approved release plan.
- Correctness regressions.
- Security hardening.
- GPU validation.
- Documentation consistency.
- Distributed testing.
- ONNX compatibility.
- Performance evidence.
- Improved release tooling.
- Broader compatibility.
- Sustainable maintenance.
- Better diagnostic tooling.
- Research-oriented improvements.
The project uses a changelog and semantic versioning conventions.
Future version numbers should be selected by the maintainer according to the actual scope of changes.
No version or release date is promised by this page.
A proposed roadmap item should have a measurable definition of completion.
| Requirement | Evidence |
|---|---|
| Functionality | Working implementation |
| Correctness | Automated tests |
| Numerical behavior | Reference comparisons |
| Compatibility | Supported-environment checks |
| Documentation | Updated usage guidance |
| Security | Relevant review |
| Reproducibility | Commands and environment details |
| Approval | Maintainer review |
A feature should not be marked complete merely because a pull request exists.
Completion should reflect implementation, validation, documentation, and acceptance.
End-to-End Tests
|
Integration Tests
|
Numerical Tests
|
Unit Tests
CPU tests remain the baseline for core framework validation.
Tests requiring TensorFlow, ONNX, or CUDA should clearly report whether they ran or were skipped.
Every fixed defect should ideally receive a test that would have detected the original problem.
Potential measurements include:
- Operation latency.
- Training throughput.
- Peak memory usage.
- Serialization time.
- Numerical error.
- Export fidelity.
Performance should not be improved by silently weakening numerical correctness.
Compare changes against a documented baseline.
Reports should distinguish measured results from expected improvements.
| Risk | Impact | Proposed Mitigation |
|---|---|---|
| GPU hardware unavailable in CI | Limited runtime validation | Dedicated hardware testing |
| Distributed network failures | Training instability | Cross-machine failure tests |
| Numerical regressions | Incorrect gradients | Finite-difference tests |
| Export shape restrictions | Invalid inference assumptions | Explicit compatibility checks |
| Native memory defects | Reliability or security issues | Native-code testing |
| Dependency incompatibility | Installation failures | Compatibility matrix |
| Documentation drift | User confusion | Documentation review |
| Maintainer capacity | Delayed progress | Focused scope and prioritization |
Risks should be updated when new evidence becomes available.
The following scoring model is proposed for comparing roadmap candidates.
| Criterion | Suggested Weight |
|---|---|
| Correctness impact | 30% |
| User impact | 20% |
| Security impact | 20% |
| Maintenance value | 15% |
| Implementation feasibility | 15% |
Assign each criterion a score from 1 to 5.
[ PriorityScore = 0.30C + 0.20U + 0.20S + 0.15M + 0.15F ]
Where:
- (C): Correctness impact.
- (U): User impact.
- (S): Security impact.
- (M): Maintenance value.
- (F): Feasibility.
The formula is an optional decision aid. It does not replace maintainer judgment.
Community members can help advance the proposed roadmap.
- Documentation improvements.
- Example corrections.
- Reproducible bug reports.
- Small unit tests.
- Gradient regression tests.
- Serialization validation.
- Optimizer tests.
- CLI diagnostics.
- CUDA hardware testing.
- Distributed execution validation.
- ONNX tracing improvements.
- Numerical stability investigations.
- Reproducible performance analysis.
Read:
Browse:
EveryO follows a maintainer-led governance model.
Identify Opportunity
|
v
Open Issue / Discussion
|
v
Technical Evaluation
|
v
Scope and Risk Review
|
v
Maintainer Decision
|
v
Implementation
|
v
Testing
|
v
Acceptance / Deferral
The maintainer determines which proposals become official project priorities.
Roadmap changes should explain:
- What changed.
- Why it changed.
- What evidence supports the decision.
- Whether compatibility is affected.
Roadmap inclusion does not guarantee delivery.
Future roadmap updates should use consistent status definitions.
| Status | Meaning |
|---|---|
| Proposed | Suggested but not approved |
| Accepted | Approved for planned work |
| In Progress | Implementation underway |
| Implemented | Code exists |
| Validating | Verification underway |
| Completed | Acceptance criteria satisfied |
| Deferred | Work postponed |
| Cancelled | Work discontinued |
## Roadmap Item
**Title:**
**Status:** Proposed
**Priority:**
**Owner:** Unassigned
**Related Issue:**
**Scope:**
**Acceptance Criteria:**
**Known Risks:**
**Validation Evidence:**
**Last Reviewed:** GitHub issues, pull requests, release notes, and repository source code should provide evidence for status changes.
Is the original EveryO roadmap complete?
The repository README marks the original roadmap objectives as implemented.
This does not establish complete production validation.
Is EveryO production-ready?
No production-readiness claim is made. The repository classifies the project as alpha software.
Will CUDA support improve?
Additional real-hardware validation is a proposed priority, not a guaranteed commitment.
Will EveryO support more model architectures?
Additional architectures may be proposed through the contribution process.
Any implementation should satisfy correctness, maintenance, and documentation requirements.
When will the next version be released?
No release date is guaranteed by this roadmap.
Can contributors propose roadmap changes?
Yes. Use GitHub Issues or Discussions.
Who approves roadmap priorities?
The project maintainer, according to the governance policy.
| Resource | Link |
|---|---|
| Repository | EveryO |
| README and Original Roadmap | README.md |
| Package Metadata | pyproject.toml |
| Changelog | CHANGELOG.md |
| Architecture | docs/architecture.md |
| CUDA | docs/cuda.md |
| Scaling | docs/scaling.md |
| Tests | GitHub Actions |
| Issues | GitHub Issues |
| Discussions | GitHub Discussions |
| Contributing | CONTRIBUTING.md |
| Governance | GOVERNANCE.md |
| Security | SECURITY.md |
EveryO has established a broad experimental neural computing foundation.
Its future progress should be measured by the reliability of its implementations, the quality of its tests, the transparency of its limitations, and the sustainability of its development.
The proposed roadmap emphasizes:
- Correctness.
- Validation.
- Compatibility.
- Security.
- Reproducibility.
- Maintainability.
The next milestone is not simply more functionality. It is stronger evidence that existing functionality behaves as documented.
Next Recommended Page: Troubleshooting Guide →
Home · Framework Architecture · Contributing
EveryO — Open Machine Learning. Built for Developers.
Project Maintainer: @krishanth7
Open Source · MIT Licensed · Community Driven
© 2026 EveryO Contributors