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/apache/mxnet 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.

GO — Healthy across all four use cases

• 18 active contributors
• Distributed ownership (top contributor 20% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 3y ago

_{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 apache/mxnet repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/apache/mxnet.

What it runs against: a local clone of apache/mxnet — 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 apache/mxnet | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 956 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of apache/mxnet. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/apache/mxnet.git
#   cd mxnet
#
# 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 apache/mxnet and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f ".mxnet_root" \\
  && ok ".mxnet_root" \\
  || miss "missing critical file: .mxnet_root"
test -f ".github/workflows" \\
  && ok ".github/workflows" \\
  || miss "missing critical file: .github/workflows"
test -f "3rdparty/mshadow" \\
  && ok "3rdparty/mshadow" \\
  || miss "missing critical file: 3rdparty/mshadow"
test -f "3rdparty/ctc_include" \\
  && ok "3rdparty/ctc_include" \\
  || miss "missing critical file: 3rdparty/ctc_include"
test -f ".licenserc.yaml" \\
  && ok ".licenserc.yaml" \\
  || miss "missing critical file: .licenserc.yaml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 956 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~926d)"
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/apache/mxnet"
  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).

Apache MXNet is a deep learning framework that unifies symbolic and imperative programming paradigms through a dynamic, mutation-aware dataflow dependency scheduler. It automatically parallelizes operations on CPU, GPU, and distributed systems (12MB+ C++, 8.6MB+ Python codebase) with built-in support for multi-language bindings (Python, R, Julia, Scala, Go, JavaScript via the src/ and python/ module structure). Core innovation: its scheduler intelligently resolves computation graphs at runtime, enabling both efficiency (via symbolic optimization) and flexibility (via eager execution). Core monolith structure: C++ engine (src/, include/) implements the scheduler and op kernels; python/ wraps via C bindings; 3rdparty/ vendors CTCLoss (moderngpu), miniz compression. Build artifacts: CMakeLists.txt orchestrates compilation; Dockerfile enables containerized builds. Tests likely in tests/ (inferred). Multiple language runtimes sit alongside Python (R, Go, Scala bindings elsewhere).

ML engineers and researchers building production deep learning systems who need portability across devices (mobile, GPU clusters, CPUs) without sacrificing either performance or ease of use. Contributors: distributed systems engineers optimizing scheduler logic, GPU kernel developers (CUDA files in 3rdparty/), and framework binding maintainers for polyglot deployments.

Highly mature: Apache Foundation project with significant GitHub stars, 12M+ lines of C++ core logic, organized CI/CD via .github/workflows/, and contributors across multiple organizations. ASF governance (.asf.yaml, LICENSE management via .licenserc.yaml) indicates long-term stability. However, commits may be less frequent than growth-stage projects—check recent activity in main branch for active development velocity.

Moderate maintenance risk: large C++/CUDA codebase (12M lines) requires specialized expertise; CTC (Connectionist Temporal Classification) in 3rdparty/ctc_include/ is dated (moderngpu from 2010s era). Dependency surface wide (boto3, PyYAML in requirements). Complex build system (CMake with clang-tidy, .cmakelintrc enforcement) can cause integration friction. Check for breaking changes in releases—symbolic-to-imperative migration still affects some users.

Unable to confirm from static snapshot, but repo organization suggests active maintenance: recent workflow additions (GitHub Actions in .github/workflows/*.yml), license compliance tooling (.licenserc.yaml, .git-blame-ignore-revs for better blame tracking), and code quality gates (clang-tidy, cmakelintrc). Check issues labeled 'pr-awaiting-review' and GitHub releases for current momentum.

git clone https://github.com/apache/mxnet.git
cd mxnet
mkdir build && cd build
cmake ..
make -j$(nproc)
cd ../python && pip install -e .

Alternatively, for CPU-only Python: pip install mxnet. See Dockerfile for reproducible Ubuntu 18.04 build baseline.

Daily commands: Python (imperative, eager):

import mxnet as mx
x = mx.nd.array([1, 2, 3])
y = mx.nd.sum(x)
print(y)

Training loop (symbolic + autograd):

net = mx.gluon.nn.Sequential()
net.add(mx.gluon.nn.Dense(10))
trainer = mx.gluon.Trainer(net.collect_params(), 'adam')
# See examples/ for full runnable scripts

For C++ inference: compile libmxnet.so and link against include/mxnet/*.h headers.

• .mxnet_root — Root marker file for MXNet project initialization and build configuration discovery.
• .github/workflows — CI/CD pipeline definitions that all contributors must understand for testing and deployment workflows.
• 3rdparty/mshadow — Core tensor computation library dependency that underpins MXNet's numerical operations on CPU/GPU.
• 3rdparty/ctc_include — Connectionist Temporal Classification library headers critical for sequence-to-sequence learning tasks.
• .licenserc.yaml — License compliance configuration that all contributions must satisfy to maintain Apache 2.0 compliance.
• .gitmodules — Git submodule configuration defining external dependencies and their versions required for the build.

Add a new GPU kernel to ModernGPU

1. Create kernel header in ModernGPU device directory following the CTA (Cooperative Thread Array) pattern used by existing kernels (3rdparty/ctc_include/contrib/moderngpu/include/device/ctaloadbalance.cuh)
2. Register kernel in the device utilities abstraction layer alongside other parallel primitives (3rdparty/ctc_include/contrib/moderngpu/include/mgpudevice.cuh)
3. Add integration test in a neuralnet guide example to verify kernel correctness on real data (3rdparty/mshadow/guide/neuralnet/convnet.cu)

Add a new loss function (e.g., focal loss)

1. Implement CPU version following the mshadow expression template pattern with operator overloading (3rdparty/mshadow/guide/defop.cpp)
2. Add corresponding GPU kernel using ModernGPU primitives for parallel reduction if needed (3rdparty/ctc_include/contrib/moderngpu/include/device/ctasegreduce.cuh)
3. Update the parameter server to distribute loss computation across nodes if distributed training is needed (3rdparty/mshadow/mshadow-ps/dist_async_sum-inl.h)

Enable CI/CD for a new platform (e.g., Windows MSVC)

1. Create new GitHub Actions workflow file in the workflows directory following macOS pattern (.github/workflows/os_x_mklbuild.yml)
2. Define platform-specific CMake configuration and lint rules (.cmakelintrc)
3. Add platform to ASF project metadata and build matrix (.asf.yaml)

Contribute distributed training optimization

1. Study existing parameter server implementations and choose backend (local, Rabit, or distributed) (3rdparty/mshadow/mshadow-ps/ps_local-inl.h)
2. Implement gradient aggregation logic following the async communication pattern (3rdparty/mshadow/mshadow-ps/dist_async_sum-inl.h)
3. Add distributed training example to validate end-to-end correctness (3rdparty/mshadow/guide/mshadow-ps/dist_async_sum.cpp)
4. Open RFC for design review and performance evaluation (.github/ISSUE_TEMPLATE/rfc.md)

• Expression Templates (mshadow) — Enable compile-time operator fusion and lazy evaluation for maximum GPU utilization and memory bandwidth efficiency without runtime overhead
• ModernGPU Cooperative Thread Arrays (CTAs) — Provide scalable, cache-efficient GPU kernel primitives (scan, reduce, merge) that dynamically balance work across hardware topology
• Parameter Server abstraction (ps_local, ps_dist, ps_rabit) — Decouple distributed training logic from communication backend, enabling transparent scaling from single-machine to multi-node clusters
• Multi-language bindings (Python, R, Julia, Scala, Go, JavaScript) — Maximize accessibility and adoption by providing native APIs for each ecosystem while sharing unified C++/CUDA core
• Dynamic computation graph with mutation-aware scheduler — Support imperative programming model (changes to graph during execution) while preserving optimization opportunities through dependency tracking

• Use expression templates for tensor operations instead of runtime dispatch

  • Why: Compile-time fusion and code generation eliminate abstraction overhead and enable aggressive SIMD/GPU vectorization
  • Consequence: Longer compilation times and steeper learning curve for contributors adding new operators

• Implement parameter server as separate layer (mshadow-ps) rather than integrated into core

  • Why: Modularity allows users to choose communication backend and swap out for custom implementations without recompiling core
  • Consequence: Added complexity in distributed training setup and synchronization between PS and tensor engine

• Support both static (symbolic) and dynamic (imperative) execution models

  • Why: Serves diverse user needs: static graphs for deployment optimization, dynamic for research experimentation
  • Consequence: Larger codebase maintaining two execution paths and more complex scheduling logic

• Does not provide built-in distributed orchestration (no Kubernetes/YARN integration—users manage cluster topology externally)
• Not a hardware-agnostic framework—specialized GPU kernels assume NVIDIA CUDA architecture
• Does not handle automatic model parallelism or pipeline scheduling across heterogeneous devices
• Not a high-level application framework—users must manually construct computation graphs (see Gluon for higher-level API)

1. CUDA capability matching: Build flags (compute_XX, sm_XX in CMakeLists.txt) must match target GPU architecture or kernels silently fail to compile. 2. Memory pool scoping: Operations reuse memory aggressively; in-place ops (x += y) may alias unexpected tensors—use x = x + y for safety. 3. Symbol vs. NDArray context: Symbolic graphs built with mx.sym.* must be bound to executors; mixing NDArray imperative ops with Symbol graphs requires explicit conversion. 4. CTC loss version: 3rdparty/ctc_include/ uses moderngpu from ~2010s; newer CUDA versions (11+) may require custom build flags (see CMakeLists.txt CUDA detection). 5. Python GIL in scheduler: Multi-threaded scheduler can deadlock if Python callbacks block; use mx.nd operations instead of Python loops for parallelization.

• Dynamic Dependency Scheduler — MXNet's core differentiator—automatically discovers and parallelizes both symbolic and imperative ops at runtime without static graph freezing; essential to understanding why MXNet avoids tracing overhead
• Symbolic vs. Imperative Programming — MXNet uniquely blends both paradigms (symbol for optimization, imperative for debugging); a user must understand when to use mx.sym.* (lazy evaluation, graph optimization) vs. mx.nd.* (eager evaluation, immediate feedback)
• Operator Kernel Specialization (CPU/GPU/Device-Agnostic) — Operators in src/operator/ define a contract; multiple kernels (CPU, CUDA, MKL variants) implement the same op—understanding this abstraction is crucial for performance tuning and adding hardware support
• CTC Loss (Connectionist Temporal Classification) — 3rdparty/ctc_include/ implements CTC for sequence-to-sequence tasks (speech recognition, OCR); this is a non-trivial kernel that differs from generic ops—essential context for NLP/speech practitioners
• Memory Pool & In-Place Operations — MXNet aggressively reuses memory buffers for performance; in-place operations (x += y) can cause subtle aliasing bugs—understanding the memory model prevents data corruption in production models
• Gluon API (Keras-like nn.Module) — python/mxnet/gluon/ provides high-level abstractions (nn.Dense, nn.Conv2D, Trainer) for most users; understanding the Gluon paradigm vs. lower-level Symbol/NDArray APIs determines code clarity and debuggability
• Cross-Language Bindings (ctypes, JNI, Go cgo) — MXNet's multi-language support (Python, R, Julia, Go, JavaScript) relies on C FFI; understanding how libmxnet.so is wrapped helps when debugging language-specific issues or porting to new runtimes

• pytorch/pytorch — Direct competitor with similar symbolic+imperative unification (TorchScript) and CUDA backend; PyTorch won mindshare but MXNet's scheduler approach remains distinct
• tensorflow/tensorflow — Older symbolic framework (TF1) vs. eager-first (TF2); MXNet positioned as middle ground; Keras-like Gluon API mirrors tf.keras modularity
• NVIDIA/tensorrt — Compilation target for MXNet symbolic graphs; users often export MXNet models to TensorRT for inference optimization on NVIDIA GPUs
• dmlc/gluon-cv — Companion ecosystem repo providing pretrained vision models (ResNet, SSD, etc.) built on MXNet's Gluon API; example of production usage patterns
• apache/mxnet-cu102 — Official CUDA 10.2 build variant; shows how Apache maintains binary wheels for specific CUDA versions (mirrors pattern for cu110, cu111 branches)

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.

Add GitHub Actions workflow for Python dependency security scanning

The repo has .github/workflows with license_check.yml and link_check.yml, but no automated scanning for vulnerable Python dependencies (boto3, PyYAML). Given that boto3==1.26.48 and PyYAML==5.1 are pinned versions, a security audit workflow would catch known CVEs and outdated dependencies. This is critical for a distributed ML framework used in production.

• [ ] Create .github/workflows/python_security_check.yml using pip-audit or safety to scan requirements files
• [ ] Configure workflow to run on PR creation and scheduled daily
• [ ] Add check to fail CI if high/critical vulnerabilities are found
• [ ] Document the security scanning setup in CONTRIBUTING.md or similar

Add unit tests for .asf.yaml and .licenserc.yaml configuration validation

The repo has ASF-specific config files (.asf.yaml, .licenserc.yaml) that control license compliance and repository settings, but there are no visible tests validating their schema or correctness. With .github/workflows/license_check.yml already present, adding schema validation tests would prevent misconfiguration.

• [ ] Create tests/config/test_asf_yaml.py to validate .asf.yaml structure against ASF guidelines
• [ ] Create tests/config/test_license_config.py to validate .licenserc.yaml matches actual license headers
• [ ] Add GitHub Action to run these validation tests on PRs that modify config files
• [ ] Ensure tests verify that 3rdparty licenses (ctc_include, mshadow) are properly declared

Add CI workflow to verify 3rdparty submodule dependencies are up-to-date

The .gitmodules and 3rdparty/ directory contain external dependencies (mshadow, ctc_include, moderngpu) that are bundled. There's no visible automated check to alert maintainers when these submodules have new versions or known security issues. This is especially important given the complexity of GPU/CUDA code in these dependencies.

• [ ] Create .github/workflows/submodule_audit.yml to check for outdated submodule commits
• [ ] Add step to verify LICENSE files exist in all 3rdparty dirs (ctc_include/LICENSE, mshadow/LICENSE, moderngpu/LICENSE)
• [ ] Generate report showing which submodules have updates available and their release notes
• [ ] Document how to update submodules securely in CONTRIBUTING.md

• Add shape inference tests for dynamic rank tensors: src/operator/ has op forward signatures but tests for rank-N tensors (>4D) are sparse—add test cases in tests/ for operations like transpose, reshape with symbolic dimensions (e.g., -1 in shapes).
• Document CUDA arch compatibility matrix: No single file lists which CUDA/cuDNN/sm_XX combinations are CI-tested; create docs/BUILD_MATRIX.md mapping CMake flags to tested GPU models (V100, A100, etc.) to reduce user build errors.
• Add Python type hints to gluon.nn: python/mxnet/gluon/nn/ uses untyped .py files (Dense, Conv2D); adding stub files (.pyi) or inline annotations helps IDE autocompletion and catches user errors early—low-risk, high-UX impact.

The MXNet repository has a moderate security posture with notable dependency vulnerabilities. The most critical issue is the outdated PyYAML 5.1 with known arbitrary code execution vulnerabilities (CVE-2020-1747, CVE-2020-14343), which should be immediately updated to 6.0+. boto3 is also significantly outdated and should be updated. The SECURITY.md vulnerability disclosure policy is incomplete, which could impede responsible vulnerability reporting. On the positive side, the project maintains proper Apache ASF licensing, includes security headers configuration files (.clang-tidy, etc.), and follows open-source best practices. Recommend: (1) Update PyYAML immediately, (2) Update boto3 to latest stable, (3) Complete SECURITY.md, (4) Implement automated dependency scanning and SBOMs.

• High · Outdated PyYAML Dependency — Dependencies/Package file (PyYAML==5.1). PyYAML version 5.1 is known to have security vulnerabilities including arbitrary code execution via the default YAML loader (CVE-2020-1747, CVE-2020-14343). This version was released in March 2019 and multiple critical patches have been released since then. Fix: Update PyYAML to version 6.0 or later. Ensure the codebase uses safe_load() instead of load() when parsing YAML files. The recommended version is 6.0.1 or the latest stable release.
• Medium · Outdated boto3 Dependency — Dependencies/Package file (boto3==1.26.48). boto3 version 1.26.48 is significantly outdated (released in December 2022). Using outdated AWS SDK versions may miss security patches and bug fixes released in newer versions, potentially exposing the application to known vulnerabilities. Fix: Update boto3 to the latest stable version (1.28.x or higher as of 2024). Implement automated dependency scanning and update policies to ensure dependencies are regularly patched.
• Medium · Missing Security Headers Configuration — Repository root / Configuration files. The codebase appears to lack explicit security configuration files (CORS headers, CSP, X-Frame-Options, etc.) that would typically be found in web-serving components. While this is a distributed computing framework, any HTTP-exposed components should have hardened security headers. Fix: If any web services are exposed, implement security headers via middleware. Document security best practices for users deploying MXNet in web contexts. Consider adding security configuration examples in documentation.
• Low · Incomplete SECURITY.md File — SECURITY.md. The SECURITY.md file appears to be incomplete, with the security reporting policy not fully documented (text cuts off at 'denial of service attacks'). This may leave users uncertain about the proper vulnerability disclosure process. Fix: Complete the SECURITY.md file with: (1) Full vulnerability reporting instructions, (2) Security contact email or reporting mechanism, (3) Expected response timeframe, (4) Disclosure policy, (5) Supported versions with security updates.
• Low · Third-Party Dependencies Lack Explicit License Verification — 3rdparty/ directory and root. The 3rdparty directory contains multiple vendored dependencies (ctc, miniz, mshadow) with LICENSE files, but there's no centralized dependency manifest or SBOM (Software Bill of Materials) to track all transitive dependencies and their security posture. Fix: Implement automated SBOM generation and dependency scanning using tools like OWASP Dependency-Check or Snyk. Maintain a dependencies.json or similar manifest documenting all vendored libraries, versions, and license/security status.

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.