If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/accord-net/framework shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 5y ago

• 17 active contributors
• LGPL-2.1 licensed
• CI configured
• ⚠ Stale — last commit 5y ago
• ⚠ Concentrated ownership — top contributor handles 52% of recent commits
• ⚠ LGPL-2.1 is copyleft — check downstream compatibility
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live accord-net/framework repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/accord-net/framework.

What it runs against: a local clone of accord-net/framework — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in accord-net/framework | Confirms the artifact applies here, not a fork | | 2 | License is still LGPL-2.1 | Catches relicense before you depend on it | | 3 | Default branch development exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 2028 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of accord-net/framework. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/accord-net/framework.git
#   cd framework
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of accord-net/framework and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "accord-net/framework(\\.git)?\\b" \\
  && ok "origin remote is accord-net/framework" \\
  || miss "origin remote is not accord-net/framework (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(LGPL-2\\.1)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"LGPL-2\\.1\"" package.json 2>/dev/null) \\
  && ok "license is LGPL-2.1" \\
  || miss "license drift — was LGPL-2.1 at generation time"

# 3. Default branch
git rev-parse --verify development >/dev/null 2>&1 \\
  && ok "default branch development exists" \\
  || miss "default branch development no longer exists"

# 4. Critical files exist
test -f ".appveyor.yml" \\
  && ok ".appveyor.yml" \\
  || miss "missing critical file: .appveyor.yml"
test -f ".travis.yml" \\
  && ok ".travis.yml" \\
  || miss "missing critical file: .travis.yml"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "Copyright.txt" \\
  && ok "Copyright.txt" \\
  || miss "missing critical file: Copyright.txt"
test -f "Externals/Json.NET/Json100r3/license.txt" \\
  && ok "Externals/Json.NET/Json100r3/license.txt" \\
  || miss "missing critical file: Externals/Json.NET/Json100r3/license.txt"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2028 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1998d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/accord-net/framework"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Accord.NET Framework is a comprehensive machine learning, computer vision, statistics, and scientific computing library for .NET that provides unified APIs for supervised/unsupervised learning, neural networks, image processing, and statistical analysis. It offers implementations of algorithms like decision trees, support vector machines, Naive Bayes, k-means clustering, and deep learning primitives, all accessible from C# with support for Windows, Xamarin, Unity3D, and Linux. Multi-framework monorepo: core algorithm implementations in C# source under Accord.* namespaces, with Externals/ directory containing pinned dependencies (Json.NET for net20/net35/net40/net45/netstandard1.0/1.3, NUnit for testing, GhostAPI DLLs for hardware). Build targets multiple .NET frameworks via .csproj configurations. CI configured via .appveyor.yml and .travis.yml for Windows and Linux builds respectively.

.NET developers (C#, VB.NET, F#) building machine learning applications who need production-ready implementations of classical ML algorithms and computer vision without wrapping Python libraries or writing native interop code. Researchers and data scientists using the .NET ecosystem who need integrated statistics and scientific computing alongside their ML models.

ARCHIVED and no longer actively maintained as of the repository state shown. The project had 14-15 years of development history and is production-grade code, but the maintainer has officially archived it and recommends forking. CI pipelines (AppVeyor, Travis CI) are in place and NuGet packages exist, indicating it was mature, but expect no future updates or security patches from the original repository.

Critical risk: project is officially archived with no active maintenance or support. Dependency risk is moderate—the codebase includes vendored copies of external libraries (Newtonsoft.Json, NUnit, GhostAPI), some potentially outdated (Json.NET 10.0r3 is old). Single-maintainer risk is now moot since it's unmaintained, but forking will require adoption of maintenance burden. No open issues or PRs are visible in provided data, so active problems are unknown.

Nothing—the project is archived. The README explicitly states 'This project is currently archived' and the maintainer (Cesar De Souza) has stopped active development after 14-15 years. The last visible CI configuration suggests the project was building successfully before archival, but no new work is occurring.

Clone via git clone --recursive https://github.com/accord-net/framework.git (note --recursive for .gitmodules in Externals/). The framework is a .NET library, not an executable; open the solution in Visual Studio 2015+ or compile via MSBuild: msbuild Accord.sln /p:Configuration=Release. NuGet packages are available via Install-Package Accord if you want to use it as a dependency in another project rather than modify this codebase.

Daily commands: This is a library, not a runnable application. To build: msbuild Accord.sln /p:Configuration=Release /p:Platform='Any CPU'. To run tests: use NUnit test runner in Externals/NUnit/NUnit.Console-3.6.1/ against compiled test assemblies, or run nunit3-console Accord.Tests.dll after building. To use in your own project, reference the compiled Accord.*.dll bindles or install from NuGet.

• .appveyor.yml — CI/CD configuration for Windows builds; essential for understanding the automated test and release pipeline.
• .travis.yml — CI/CD configuration for Linux/macOS builds; critical for cross-platform build validation.
• CONTRIBUTING.md — Contribution guidelines that define coding standards, PR processes, and development workflows for all contributors.
• Copyright.txt — Licensing and copyright information; must be reviewed to understand intellectual property constraints and permissions.
• Externals/Json.NET/Json100r3/license.txt — Third-party dependency license; ensures compliance and clarifies JSON serialization library constraints.

• Core ML Algorithms (C#, LINQ, Generics) — Statistical learning, classification, regression, clustering, dimensionality reduction implementations.
  • Failure mode: Incorrect mathematical results if numerical stability not maintained; poor performance on large datasets.
• Computer Vision Module (C#, GhostAPI, AForge integration) — Image processing, feature extraction, object detection, and visual filtering.
  • Failure mode: Segmentation faults or incorrect image operations if memory bounds violated; hardware driver crashes if device unavailable.
• Statistics & Probability (C#, Math.NET numerics) — Distribution sampling, hypothesis testing, Bayesian inference, entropy calculations.
  • Failure mode: Numerical underflow/overflow in extreme distributions; convergence failures in MCMC samplers.
• Serialization & Persistence (Newtonsoft.Json, C#) — Model save/load, JSON interop, configuration management via Newtonsoft.Json.
  • Failure mode: Data loss if JSON schema changes; backward compatibility breaks in archived versions.
• Build & Testing Infrastructure (AppVeyor, Travis CI, NUnit, MSBuild) — CI/CD orchestration, cross-platform validation, artifact generation.
  • Failure mode: Build matrix explosion; flaky tests on Linux/Windows divergence; NUnit framework version conflicts.

• User Application → Accord.NET Assembly (.dll) — User code instantiates ML algorithms (e.g., SVM, KMeans) from loaded assembly.
• Accord.NET Assembly → Training Data (arrays/matrices) — Algorithms operate on in-memory numerical data (double[] arrays, Matrix types).
• Trained Model → Newtonsoft.Json — Model parameters serialized to JSON via JsonConvert for storage or REST API transmission.
• Deserialized JSON → Accord.NET Assembly — Previously saved model reloaded into algorithm instance for inference.
• Hardware Device (optional) → GhostAPI Wrapper — Imaging devices (cameras, USB devices) communicate via GhostAPI DLL; data streamed to CV algorithms.
• Test Suite → NUnit Framework — Unit tests validate algorithm correctness and numerical stability across .NET versions.

Add a New Machine Learning Algorithm

1. Review CONTRIBUTING.md for code style and structure conventions (CONTRIBUTING.md)
2. Create algorithm implementation in the appropriate namespace folder within the core library (not visible in root file list but inferred from ML-focused README) (SOURCE/Accord.[Domain]/[AlgorithmName].cs)
3. Add unit tests using NUnit framework in parallel test structure (Externals/NUnit/NUnit.Framework-3.6.1/bin/net-4.5/nunit.framework.dll)
4. Ensure CI/CD passes on both Windows and Unix platforms (.appveyor.yml)

Integrate a Hardware Device or External Library

1. Add external DLL to Externals folder following existing patterns (e.g., GhostAPI structure) (Externals/GhostAPI/GhostAPI.dll)
2. Create wrapper class that abstracts device communication (SOURCE/Accord.Imaging/[DeviceName]Wrapper.cs)
3. Document in README and update Contributors.txt with attributions (Contributors.txt)

Add JSON Serialization Support to a Data Model

1. Ensure Newtonsoft.Json dependency is referenced (already bundled) (Externals/Json.NET/Json100r3/net45/Newtonsoft.Json.dll)
2. Decorate model classes with JsonProperty and JsonConverter attributes (SOURCE/Accord.[Domain]/Models/[ModelName].cs)
3. Add serialization tests using NUnit (Externals/NUnit/NUnit.Framework-3.6.1/bin/net-4.5/nunit.framework.dll)

• C# .NET Framework (2.0–4.5+) — Cross-platform ML/CV library requiring broad .NET version support for Windows enterprise and research environments.
• Newtonsoft.Json (Json.NET) — Industry-standard JSON serialization for .NET; bundled to ensure deterministic builds and offline availability.
• NUnit 3.6.1 — Comprehensive unit testing framework; multiple .NET target versions (2.0, 3.5, 4.0, 4.5) included to test across legacy and modern CLRs.
• AppVeyor + Travis CI — Dual CI/CD pipelines ensure simultaneous validation on Windows (.appveyor.yml) and Unix-like systems (.travis.yml).

• Support .NET 2.0 through .NET 4.5+ in single codebase

  • Why: Legacy enterprise systems require older .NET versions; broad compatibility maximizes adoption.
  • Consequence: Code must avoid modern C# features (async/await, LINQ, generics heavily); maintenance burden increases with version divergence.

• Bundle external dependencies in Externals/ rather than NuGet-only

  • Why: Ensures reproducible offline builds; avoids package manager availability issues in research/isolated environments.
  • Consequence: Repository size increases; manual updates required for bundled libraries; harder to track upstream security patches.

• Archive the project after 14–15 years

  • Why: Maintainer resources exhausted; ML landscape evolved beyond project scope; community can fork and extend.
  • Consequence: No active security patches or feature development; users must fork to continue; legacy codebase remains stable but unmaintained.

• Real-time inference at scale (no async/parallel execution guarantees)
• GPU acceleration (CPU-only implementation)
• Cloud-native deployment (no Docker, Kubernetes support)
• Python interoperability (C# .NET only)
• Modern deep learning frameworks (no TensorFlow/PyTorch bindings; static ML algorithms focus)

• Legacy .NET version compatibility code (Medium) — Throughout core algorithm implementations (inferred from multi-target build structure): Conditional compilation for .NET 2.0 vs. 4.5 creates code duplication and obscures primary logic with #if directives.
• Bundled external dependencies without version pinning: undefined

Multi-framework targeting is complex—code must compile under net20 (no LINQ), net35 (no async), net40 (no nullability), net45, and netstandard1.0/1.3. Externals/Json.NET must be manually updated in 6 separate locations if upgraded. GhostAPI DLL is Windows-only native code; Linux builds will fail if code tries to load it without proper platform detection. The project uses old MSBuild format (.csproj), not the newer SDK-style; Visual Studio 2019+ may require migration on first open. No clear build instructions in README; developers must infer MSBuild usage from .csproj files.

• Support Vector Machine (SVM) with kernel methods — Core supervised learning algorithm in Accord; understanding kernel trick (RBF, polynomial kernels) is essential for using Accord.MachineLearning.VectorMachines correctly
• Expectation-Maximization (EM) algorithm — Foundation for Gaussian Mixture Models and hidden Markov models in Accord.Statistics; EM is used to fit latent variable models when direct optimization is intractable
• Convex optimization and Quadratic Programming (QP) — SVM training, logistic regression, and other Accord algorithms reduce to QP solvers; understanding dual formulation and SMO is key to extending these implementations
• Sparse matrix representations (CSR/CSC format) — Accord.Math uses sparse matrices for efficiency in high-dimensional data; the framework provides CSR (Compressed Sparse Row) storage to avoid allocating dense matrices
• Multithreading and parallel BLAS operations — Accord.Math wraps linear algebra via multi-threaded BLAS/LAPACK calls; knowing when operations are parallelized (matrix multiply, decomposition) prevents bottlenecks in large datasets
• Cross-validation and stratified sampling — Accord.Statistics.Models uses k-fold and stratified cross-validation to prevent overfitting; understanding fold generation and stratification strategies is critical for model evaluation
• Bayesian inference and conjugate priors — Accord implements Naive Bayes, Bayesian networks, and Dirichlet-Multinomial conjugates for probabilistic models; conjugacy enables closed-form EM updates in mixture models

• ML.NET/ML.NET — Microsoft's modern machine learning library for .NET; the spiritual successor to Accord.NET, actively maintained, but requires .NET Core/5+
• SciSharp/Tensorflow.NET — TensorFlow bindings for .NET; provides deep learning capabilities that Accord.NET's neural networks don't cover, complements Accord for modern AI workloads
• aforge/framework — Original AForge.NET project that Accord.NET merged with; Accord was created by extending AForge with unified ML APIs
• CommunityToolkit/dotnet — Microsoft's community toolkit for .NET containing utilities and helpers; useful companion for developers building on archived Accord code
• nmkataoka/LightGBM.NET — Gradient boosting library bindings for .NET; provides an alternative to Accord's decision tree/ensemble methods with production ML deployment focus

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Migrate Externals dependencies from local binaries to NuGet package references

The repo contains outdated bundled external dependencies (Json.NET 10.0r3, NUnit 3.6.1, GhostAPI) stored directly in the Externals/ folder. This is a maintenance burden and security risk. Migrating these to proper NuGet package references in .csproj files would reduce repo size, simplify updates, and follow modern .NET best practices. This is particularly important since the project is archived and needs modernization for forks.

• [ ] Analyze all .csproj files to identify current package reference patterns
• [ ] Replace Externals/Json.NET references with Newtonsoft.Json NuGet package (latest stable matching the codebase)
• [ ] Replace Externals/NUnit direct references with NUnit NuGet package in test projects
• [ ] Remove or document the Externals/GhostAPI dependency - determine if it's still used or can be removed
• [ ] Update .appveyor.yml and .travis.yml CI configurations to remove dependency on local Externals paths
• [ ] Add a migration guide to CONTRIBUTING.md explaining the change for future maintainers

Add comprehensive GitHub Actions workflow to replace AppVeyor and Travis CI

The repo uses legacy CI systems (.appveyor.yml, .travis.yml) that are harder to maintain and view on GitHub. A modern GitHub Actions workflow would provide better integration, visibility, and maintainability. Since this is an archived project that may be forked, a clear CI template would help new maintainers set up testing immediately.

• [ ] Create .github/workflows/build-and-test.yml that targets multiple .NET frameworks (net20, net35, net40, net45, netstandard1.0+)
• [ ] Configure matrix builds for Windows and Linux runners given the cross-platform nature of Accord.NET
• [ ] Integrate NUnit3 console runner from Externals/NUnit for test execution
• [ ] Add build steps for both Debug and Release configurations
• [ ] Document the CI setup in CONTRIBUTING.md with badges in README.md
• [ ] Ensure the workflow validates that Externals dependencies are properly referenced

Create missing unit test coverage documentation and test suite template for core modules

The repo has NUnit infrastructure but the file structure shows no test files in the provided listing. Given that this is a scientific computing library with critical algorithms (ML, CV, statistics), establishing clear test structure and documenting testing patterns is essential for forks. A concrete test template and coverage guide would help contributors maintain quality.

• [ ] Create TESTING.md documenting the test structure and NUnit conventions used in the project
• [ ] Identify the main source modules (likely in src/ or similar - not fully visible in listing) that lack corresponding test projects
• [ ] Create a template test project structure showing examples for statistical computing, ML, and CV modules
• [ ] Add sample unit tests (3-5 concrete examples) for one core module demonstrating proper test patterns
• [ ] Document test execution in CONTRIBUTING.md: 'Run tests with: nunit3-console.exe path/to/tests.dll'
• [ ] Add GitHub Actions test reporting to surface test results in PR checks

• Update Externals/Json.NET from 10.0r3 to latest LTS version (13.x or 14.x) by downloading the official NuGet package binaries and placing them in all 6 target framework folders (net20, net35, net40, net45, netstandard1.0, netstandard1.3), then recompile and verify backward compatibility.
• Add missing XML documentation comments to public methods in Accord.MachineLearning/VectorMachines/SupportVectorMachine.cs and related SVM classes—currently many public methods lack <summary> tags, reducing IntelliSense usability in Visual Studio.
• Create a consolidated BUILD.md in the root documenting exact steps to compile on Windows (Visual Studio 2015+), Linux (Mono), and .NET Core, including handling of the Externals/ dependencies and GhostAPI platform-specific code; README.md currently mentions 'patter' (incomplete sentence) and omits build instructions.

The Accord.NET Framework codebase presents significant security concerns primarily due to its archived status and use of severely outdated dependencies from 2016. The project contains multiple high-severity issues: unmaintained versions of Newtonstein.Json and NUnit with known CVEs, inclusion of unverifiable binary dependencies, and support for obsolete .NET Framework versions. Most critically, as an archived project, there is no mechanism for security patches or vulnerability remediation. Organizations using this codebase in production should plan migration to actively maintained alternatives or establish a dedicated security maintenance fork. The codebase is suitable only for reference, learning, or non-critical legacy systems where security risks can be accepted.

• High · Outdated and Vulnerable Dependencies — Externals/Json.NET/Json100r3/, Externals/NUnit/NUnit.Console-3.6.1, Externals/NUnit/NUnit.Framework-3.6.1. The codebase includes very old versions of critical dependencies: Newtonsoft.Json 10.0.0 (released 2016) and NUnit 3.6.1 (released 2016). These versions contain known security vulnerabilities and lack security patches from the last 7+ years. Newtonsoft.Json in particular has had multiple CVEs patched in newer versions. Fix: Update to the latest versions of all dependencies. For Newtonsoft.Json, use version 13.x or later. For NUnit, use version 3.13.x or later. Implement a dependency management strategy with regular security updates.
• High · Archived Project - No Maintenance — README.md, Project Status. The project is officially archived and no longer maintained. This means security vulnerabilities discovered in the future will not be patched, and the codebase will accumulate technical debt and security risks over time. Fix: If this codebase is in use, create a maintained fork or migrate to actively maintained alternatives. Conduct a comprehensive security audit before using in production. Consider the long-term maintenance burden.
• Medium · Included Binary Dependencies — Externals/GhostAPI/. The codebase includes pre-compiled binary files (GhostAPI.dll, PbkComm32.dll, PbkUsbPort.dll) from external sources without visible source code or verification. These could potentially contain malicious code or vulnerabilities that are difficult to audit. Fix: Verify the integrity and source of all binary dependencies. Use checksums or digital signatures. Consider building from source when possible. Document the purpose and origin of each external binary.
• Medium · Multiple .NET Framework Versions with Mixed Support Levels — Externals/NUnit/NUnit.Framework-3.6.1/bin/. The codebase supports multiple .NET Framework versions including very old ones (net-2.0, net-3.5, net-2.0) which have been out of support for many years. Code targeting these versions may not benefit from modern security fixes. Fix: Deprecate support for obsolete .NET Framework versions. Focus on .NET 6.0+ or .NET Framework 4.7.2+. Remove binaries for net-2.0 and net-3.5 targets.
• Low · Git Submodule Dependency — .gitmodules. The presence of .gitmodules indicates submodule dependencies which may not be pinned to specific secure versions, potentially allowing for supply chain risks if submodule repositories are compromised. Fix: Review all git submodules. Pin to specific commit hashes rather than branches. Consider alternatives like package managers (NuGet) for better version control and security tracking.
• Low · CI/CD Configuration Review Needed — .travis.yml, .appveyor.yml. CI/CD files (.travis.yml, .appveyor.yml) are present but content was not provided. These should be reviewed for secrets, insecure configurations, and best practices. Fix: Review CI/CD configurations for: hardcoded credentials, insecure environment variable handling, secure artifact signing, and build isolation. Use secrets management tools properly.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.