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/tensorflow/rust 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

• 8 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 67% of recent commits

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

What it runs against: a local clone of tensorflow/rust — 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 tensorflow/rust | 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 ≤ 510 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "tensorflow/rust(\\.git)?\\b" \\
  && ok "origin remote is tensorflow/rust" \\
  || miss "origin remote is not tensorflow/rust (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 "src/lib.rs" \\
  && ok "src/lib.rs" \\
  || miss "missing critical file: src/lib.rs"
test -f "src/session.rs" \\
  && ok "src/session.rs" \\
  || miss "missing critical file: src/session.rs"
test -f "src/eager/context.rs" \\
  && ok "src/eager/context.rs" \\
  || miss "missing critical file: src/eager/context.rs"
test -f "src/graph.rs" \\
  && ok "src/graph.rs" \\
  || miss "missing critical file: src/graph.rs"
test -f "src/saved_model.rs" \\
  && ok "src/saved_model.rs" \\
  || miss "missing critical file: src/saved_model.rs"

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

TensorFlow Rust provides idiomatic Rust language bindings for TensorFlow, enabling developers to build and run machine learning models directly in Rust without Python. It wraps the TensorFlow C API and automatically manages downloading or compiling the TensorFlow shared libraries, supporting both eager execution (via src/eager/) and graph-based models loaded from .pb or SavedModel formats. Monorepo structure: src/ contains core bindings organized as buffer.rs, checkpoint.rs, eager/ (eager execution API), with examples/ containing runnable Rust demos (addition.rs, mobilenetv3.rs, xor.rs) paired with Python model generation scripts. Separate subdirectories like src/eager/op/ handle operator definitions. Python examples in examples/*/ generate .pb model files consumed by Rust code.

Rust systems engineers and ML practitioners who need to deploy TensorFlow models in production Rust applications, particularly those building latency-sensitive services, embedded systems, or projects where Python interop is undesirable. Contributors are typically members of the TensorFlow SIG Rust community maintaining the bindings.

Actively developed but explicitly unstable per README: "This project is still under active development and not guaranteed to have a stable API." The codebase is substantial (15.9M lines of Rust), has CI/CD via GitHub Actions (.github/workflows/ci.yml), and maintains examples, but version 0.21.0 signals pre-1.0 status. Minimum supported Rust version is 1.58, indicating deliberate compatibility management.

High risk due to API instability guarantee and tight coupling to TensorFlow C API versioning (currently locked to TensorFlow 2.18.0 in dependencies). Breaking changes between minor versions are expected. Dependency on system-level TensorFlow libraries adds deployment friction—you must either have TensorFlow pre-installed or allow the build to compile it (via Bazel), which is memory-intensive. The --features tensorflow_unstable flag suggests core functionality is still experimental.

The README and file structure indicate active example development and SavedModel support (regression_savedmodel.rs). CI workflow exists in .github/workflows/ci.yml. The presence of RELEASING.md and CHANGELOG.md suggests structured release processes, but specific recent commit data is not provided in the repo metadata.

git clone https://github.com/tensorflow/rust.git
cd tensorflow/rust
cargo build -j 1

The -j 1 flag is critical per README to avoid excessive memory use during TensorFlow compilation. Prerequisites: Rust 1.58+, and either prebuilt TensorFlow libraries or git/Bazel/Python (numpy, dev, pip, wheel) to compile TensorFlow from source.

Daily commands: No single 'dev server'—instead run examples: cargo run --example addition or cargo run --example mobilenetv3. Each example has associated Python scripts (e.g., examples/regression/regression.py) that generate the model file the Rust code loads. Full test suite: cargo test.

• src/lib.rs — Entry point for the entire TensorFlow Rust bindings; defines public API and module structure
• src/session.rs — Core session management for graph-based TensorFlow execution; critical for running inference
• src/eager/context.rs — Eager execution context initialization and state management; required for eager mode operations
• src/graph.rs — Graph construction and manipulation abstractions; foundational for building TensorFlow computation graphs
• src/saved_model.rs — SavedModel format loading and inference; enables loading pre-trained TensorFlow models
• Cargo.toml — Workspace root configuration and TensorFlow C API dependency specification
• tensorflow-op-codegen/src/main.rs — Code generation tool for TensorFlow operations; maintains consistency between op definitions and bindings

Add a new mathematical operation to the high-level API

1. Define the operation builder in src/ops/math_ops.rs following the existing pattern (e.g., add, mul, etc.) (src/ops/math_ops.rs)
2. Add the operation to the Ops trait in src/ops/ops_impl.rs to make it available on Scope (src/ops/ops_impl.rs)
3. If generating from TensorFlow op definitions, update tensorflow-op-codegen/src/main.rs to include the new op (tensorflow-op-codegen/src/main.rs)
4. Add a test or example in examples/ demonstrating the new operation (examples/addition.rs)

Add support for a new TensorFlow model format or feature

1. Add protobuf definition parsing to src/protos/ if needed (e.g., src/protos/saved_model.rs) (src/protos/saved_model.rs)
2. Create new module in src/ (e.g., src/custom_model.rs) for loading and inference logic (src/lib.rs)
3. Export the new module type from src/lib.rs (src/lib.rs)
4. Create example in examples/ demonstrating the new feature (examples/mobilenetv3.rs)

Generate Rust bindings for additional TensorFlow operations

1. Update tensorflow-op-codegen/src/main.rs or src/lib.rs to add operation name to codegen allowlist (tensorflow-op-codegen/src/main.rs)
2. Run codegen tool (typically via build script) to generate raw operation bindings in src/eager/op/raw_ops.rs (tensorflow-op-codegen/src/bin/eager.rs)
3. Wrap generated operations with idiomatic Rust API in src/ops/ or src/eager/ (src/ops/ops_impl.rs)
4. Add integration tests demonstrating the new operation works correctly (examples/addition.rs)

Add a new eager execution utility or advanced feature

1. Create new module in src/eager/ (e.g., src/eager/my_feature.rs) with the implementation (src/eager/context.rs)
2. Export from src/eager.rs or src/lib.rs as needed (src/eager.rs)
3. Add unit tests in the module or src/eager/op/op_test_util.rs (src/eager/op/op_test_util.rs)
4. Document in comments and consider adding an example in examples/ (examples/addition.rs)

• TensorFlow C API — Provides stable, versioned interface to TensorFlow runtime; enables cross-platform support (Linux, macOS, Windows) with CPU/GPU acceleration
• Protocol Buffers — Standard serialization format for TensorFlow graph definitions, SavedModels, and configuration; enables interoperability with Python TensorFlow
• Rust — Memory safety without garbage collection; zero-cost abstractions; prevents data races; ideal for production ML inference systems
• Procedural Macros & Code Generation — Automatically generate idiomatic Rust bindings from TensorFlow op definitions; reduces manual maintenance and keeps bindings in sync with upstream

• Graph-based vs. Eager execution modes

  • Why: Different use cases: graph mode for production optimization, eager for research/debugging
  • Consequence: Developers must understand both APIs; code must support both execution paradigms

• Wrapping C API instead of reimplementing in pure Rust

  • Why: Leverages mature, battle-tested TensorFlow runtime; significantly faster development
  • Consequence: Requires TensorFlow C library installation; introduces FFI overhead; cannot customize core execution logic

• Codegen-based operation bindings rather than manual wrappers

  • Why: Covers hundreds of TensorFlow ops automatically; stays in sync with upstream
  • Consequence: Generated code less readable; requires understanding codegen infrastructure to add new ops

• High-level Scope/Graph API over low-level tensor operations

  • Why: Provides ergonomic Rust idioms; reduces verbosity compared to C API
  • Consequence: Additional abstraction layer; potential performance cost; harder to debug

• does not implement TensorFlow runtime (delegates to C library)
• does not support training/gradient computation natively (not exposed in current bindings)
• does not provide Python API compatibility (different ecosystem entirely)
• not intended for embedded systems or no-std environments

Memory during build: -j 1 is mandatory when compiling TensorFlow from source or you risk OOM. TensorFlow version lock: tensorflow-sys pins TensorFlow 2.18.0; mismatched system TensorFlow may cause silent failures. Python model generation: several examples require a working Python TensorFlow installation to generate .pb files—this is not automatic. Feature flag: --features tensorflow_unstable must be explicitly passed to use the expr module; it's off by default. SavedModel vs. CheckPoint: different APIs (src/eager/ vs. src/checkpoint.rs) for different model formats—wrong choice breaks at runtime, not compile time.

• Foreign Function Interface (FFI) & unsafe Rust — tensorflow-rust is fundamentally an FFI layer over TensorFlow's C API; understanding Rust's unsafe keyword, CString handling, and pointer lifetime management is prerequisite for any modification to core bindings.
• TensorFlow Eager Execution — The primary API surface (src/eager/) deviates from TensorFlow's graph-based model; eager execution evaluates operations immediately, not as a deferred computation graph, requiring different session/context management.
• Protocol Buffers (protobuf) — TensorFlow models are serialized as .pb (protobuf) files; src/checkpoint.rs and examples load these binary formats, requiring familiarity with protobuf structure and TensorFlow's specific schema.
• SavedModel Format — Modern TensorFlow model persistence uses SavedModel (assets + variables + graph.pb); regression_savedmodel.rs example and corresponding src/ APIs handle this multi-file format, distinct from legacy checkpoint format.
• Build Script Dependency Management (build.rs) — The README references tensorflow-sys crate's build.rs which dynamically downloads or compiles TensorFlow; understanding Cargo's build script phase is critical for troubleshooting linker issues and library discovery.
• Tensor Shape & Broadcasting — Rust type system cannot directly encode tensor shapes (unlike dependent typing languages); operations in src/eager/op/ silently assume shape compatibility, making shape errors runtime-only—a common footgun.
• Context & Scope Management — Eager execution requires an active TensorFlow context (src/eager/context.rs); operations are invalid outside scope, creating lifetime constraints not obvious in the type system—crucial for avoiding segfaults.

• tensorflow/tensorflow — The upstream C/C++ TensorFlow library that tensorflow-rust wraps via FFI; required to understand the C API surface being bound.
• huggingface/candle — Alternative Rust ML framework with pure Rust implementation (no C++ deps), solving similar use case but with different trade-offs (portability vs. feature parity).
• ndarray-rs/ndarray — N-dimensional array library used implicitly by many Rust ML projects; tensor representation patterns in tensorflow-rust are informed by ndarray conventions.
• tensorflow/community — Official TensorFlow SIG (Special Interest Group) community repo; SIG Rust is housed here and defines priorities for the Rust bindings.
• rustwasm/wasm-bindgen — Reference implementation for Rust-C FFI bindings; tensorflow-rust's build system and unsafe FFI patterns follow similar paradigms.

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 comprehensive unit tests for src/eager/op/raw_ops.rs

The raw_ops.rs file is a critical component for eager execution but has no corresponding test file in the repository. Given that src/eager/op/op_test_util.rs exists as a testing utility, there's an opportunity to create thorough unit tests covering raw operation construction, tensor input/output handling, and error cases. This would improve code reliability and serve as documentation for new contributors.

• [ ] Create src/eager/op/raw_ops_test.rs using op_test_util.rs patterns
• [ ] Write tests for basic raw op creation and execution
• [ ] Add tests for tensor handle conversions and type checking
• [ ] Test error handling for invalid inputs and operation states
• [ ] Run tests with cargo test and verify coverage

Implement missing eager execution examples with documentation

The examples directory contains graph-based examples (addition.rs, regression.rs, mobilenetv3.rs) but lacks eager execution examples. Given that src/eager/context.rs and src/eager/op.rs exist as mature modules, creating an eager execution example would help users understand how to use this API and identify any documentation gaps.

• [ ] Create examples/eager_basic.rs demonstrating context creation and tensor operations
• [ ] Create examples/eager_training.rs showing gradient computation and model training
• [ ] Add README.md in examples/ directory explaining when to use eager vs graph execution
• [ ] Include Python model generation scripts if needed for eager examples
• [ ] Test examples run without errors and produce expected output

Add CI workflow for MSRV (Minimum Supported Rust Version) testing

The .github/workflows/ci.yml exists but there's no visible MSRV testing configuration. Given the project's maturity and reliance on C API bindings, establishing an explicit MSRV policy and testing it in CI would prevent accidental breaking changes and help contributors understand compatibility requirements.

• [ ] Define MSRV in Cargo.toml using rust-version field
• [ ] Create .github/workflows/msrv.yml that tests against specified MSRV version
• [ ] Document MSRV policy in CONTRIBUTING.md
• [ ] Run MSRV CI on pull requests to catch compatibility issues early
• [ ] Update README.md with supported Rust versions section

• Add integration tests for src/buffer.rs buffer ownership and FFI safety—currently no dedicated test file visible in the structure.
• Document the SavedModel API in src/ with inline examples; regression_savedmodel.rs example exists but no doc comments explain the three-step load pattern (assets, variables, graph).
• Implement error context propagation in src/eager/op.rs—wrap C API errors with source location and operation name so users see which TF op failed, not just a generic C error code.

The TensorFlow Rust bindings project shows moderate security posture with several areas of concern. The primary vulnerabilities stem from potentially outdated dependencies (TensorFlow 2.18.0), unsafe FFI bindings required for C API interaction, and pre-built model files without integrity verification. The codebase lacks formal security documentation and vulnerability reporting mechanisms. While the project benefits from being part of the TensorFlow ecosystem with community oversight, immediate actions should focus on: (1) updating and auditing the TensorFlow dependency against known CVEs, (2) implementing security scanning in CI/CD, (3) establishing a vulnerability disclosure policy, and (4) auditing unsafe FFI code blocks. The project would benefit from adopting secure dependency management practices and supply chain security measures.

• High · Outdated TensorFlow Dependency — Dependencies/Package file (tensorflow == 2.18.0, tf_keras == 2.18.0). The codebase depends on TensorFlow 2.18.0 and tf_keras 2.18.0. These versions may contain known security vulnerabilities. TensorFlow has had multiple CVEs patched in newer releases. The specific versions mentioned should be checked against the National Vulnerability Database (NVD) and TensorFlow's security advisories. Fix: Update to the latest stable version of TensorFlow and tf_keras. Review TensorFlow's security advisories at https://github.com/tensorflow/tensorflow/security/advisories to identify any CVEs affecting version 2.18.0. Implement a dependency management strategy with regular updates.
• Medium · Pre-trained Model Files in Repository — examples/addition/model.pb, examples/regression/model.pb, examples/regression_savedmodel/saved_model.pb, examples/mobilenetv3/. The repository contains pre-built model files (model.pb, saved_model.pb) checked into version control. These binary files cannot be easily audited for integrity and may pose supply chain risks. Additionally, there's no apparent signature verification mechanism for these models. Fix: Consider moving pre-trained models to a secure artifact repository with checksum verification. Implement model signing and verification. Document the source and provenance of each model file. Use git-lfs (Large File Storage) for binary files if they must remain in version control.
• Medium · Unsafe FFI Bindings to TensorFlow C API — src/buffer.rs, src/eager/, src/graph.rs, and related FFI wrapper modules. As Rust bindings for TensorFlow's C API, this crate likely contains unsafe code blocks for FFI (Foreign Function Interface) calls. The structure indicates extensive FFI usage (src/buffer.rs, src/eager.rs, src/protos/, etc.). Improper FFI usage can lead to memory safety vulnerabilities including buffer overflows, use-after-free, and null pointer dereferences. Fix: Conduct a thorough security audit of all unsafe FFI blocks. Ensure proper memory ownership tracking, bounds checking, and null pointer validation. Consider using tools like miri for testing unsafe code. Document safety invariants for each unsafe block. Keep TensorFlow C API updated to patch native vulnerabilities.
• Low · Missing Security Policy Documentation — Repository root. The repository does not appear to have a SECURITY.md file or documented security policy. This makes it difficult for security researchers to report vulnerabilities responsibly and can lead to public disclosure of unpatched issues. Fix: Create a SECURITY.md file documenting the security policy, including how to report vulnerabilities, response timeframes, and supported versions. Follow the GitHub security advisory guidelines at https://github.com/tensorflow/rust/security/advisories.
• Low · No Dependency Lock File Visibility — .github/workflows/ci.yml. While Cargo.lock should exist for binary projects, the repository structure doesn't show explicit indication of dependency verification mechanisms like dependency scanning or SBOM (Software Bill of Materials) generation in CI/CD. Fix: Ensure Cargo.lock is committed to version control. Integrate dependency scanning tools (e.g., cargo-audit, cargo-deny) into the CI/CD pipeline. Generate and maintain an SBOM for supply chain transparency.

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.