STOP TRUSTING GHOST CODE

System Architecture

OpenClaw operates as a pipeline of specialized analysis modules, each designed to examine a specific dimension of repository legitimacy. The modules run in parallel where possible and feed their results into a central verdict engine.

Pipeline Overview

Core Components

• Repository Fetcher — Handles cloning, caching, and file tree mapping. Supports public GitHub repositories with private repo support planned. Generates a complete file manifest with metadata (size, type, last modified).
• Code Forensics Engine — Performs static analysis on every source file. Checks for function definitions matching claimed functionality, import/usage consistency, execution path coherence, code complexity metrics, and copy-paste detection.
• Commit Analyzer — Examines the full git history for anomalous patterns. Detects single-day dumps, artificial inflation, bot-like timing, inconsistent authorship, and force-push evidence.
• Dependency Auditor — Validates package manifests (package.json, requirements.txt, Cargo.toml, etc.) against actual import statements. Detects phantom dependencies, missing dependencies, and version inconsistencies.
• Test Scanner — Searches for test files, test directories, CI/CD configuration, coverage reports, and test-to-code ratios. Distinguishes between meaningful tests and placeholder stubs.
• Metric Verifier — Extracts numerical claims from README and documentation, then searches the codebase for evaluation scripts, benchmark datasets, and measurement code that would produce those numbers.
• AI Model Validator — Specialized module for ML repositories. Checks architecture definitions, model weight availability, training script functionality, and cross-references claims with arXiv, HuggingFace, and PapersWithCode.
• Verdict Engine — Aggregates signals from all modules using a weighted scoring algorithm. Produces a final verdict (LEGIT or FAKE REPO) with a confidence percentage and detailed evidence breakdown.

Technology Stack

• AI backbone: Claude (Anthropic) for natural language analysis and reasoning
• Static analysis: Custom AST parsers for Python, JavaScript, TypeScript, Rust, Go
• Git analysis: libgit2 bindings for efficient history traversal
• Infrastructure: Sandboxed execution environments for safe code analysis
• API: RESTful JSON API with WebSocket support for real-time scan progress

Analysis Methodology

OpenClaw employs a multi-dimensional analysis approach. Each dimension contributes weighted signals to the final verdict, ensuring no single factor produces a false positive or negative.

Code Forensics

Every source file in the repository is analyzed for:

• Function/class definitions that match README-claimed functionality
• Import statements that correspond to actual usage in code
• Execution paths that are logically coherent and reachable
• Code complexity appropriate for the claimed project scope
• Dead code ratio — high ratios suggest generated or copy-pasted code
• Naming conventions and style consistency across the codebase

Commit Pattern Analysis

The git history reveals crucial information about how a project was actually developed. Suspicious patterns include:

• Single-day dumps where the entire project appears in one or two commits
• Artificial inflation through meaningless whitespace or formatting changes
• Bot-like commit timing with unnaturally regular intervals
• Inconsistent author information suggesting copied histories
• Evidence of force-pushes that may hide the actual development timeline
• Commit message patterns that suggest automated or bulk generation

Test Coverage Analysis

Legitimate software projects have testing infrastructure. We scan for:

• Test files and test directories (tests/, __tests__/, spec/, etc.)
• CI/CD configuration (.github/workflows, .gitlab-ci.yml, Jenkinsfile)
• Coverage report artifacts and configuration
• Test-to-code ratio analysis
• Quality assessment: meaningful tests vs. placeholder stubs

Metric Verification

When repositories claim specific performance metrics (accuracy, speed, benchmarks), we verify:

• Presence of evaluation scripts that could produce the claimed numbers
• Benchmark datasets referenced and accessible
• Reproducibility of claimed results given the code structure
• Cross-referencing with published papers when cited

Dependency Audit

• All declared dependencies are real, published packages
• Declared dependencies are actually imported in source code
• No critical dependencies are missing from the manifest
• Version pinning follows security best practices
• No known vulnerabilities in dependency tree

Scoring System

The verdict engine uses a weighted multi-signal scoring algorithm to produce two primary metrics: the Legitimacy Score and the Confidence Level.

Legitimacy Score (0-100)

Confidence Level

Signal Weights

Each analysis module contributes a weighted signal to the final score. Default weights (configurable via strictness parameter):

API Reference

The ClawGit API provides programmatic access to the scanning engine. Currently in closed beta with limited access.

Scan Repository

Get Scan Status

Export Report

Rate Limits

Flag Taxonomy

OpenClaw uses a standardized taxonomy of red and green flags to categorize findings. Each flag is backed by specific evidence from the analysis.

Red Flags

Green Flags

Integration Guide

ClawGit can be integrated into your development workflow through multiple channels. All integrations use the same underlying OpenClaw engine.

GitHub Actions

CLI Tool (Planned)

Webhook Notifications

Privacy and Security

• Repository data is not stored after analysis completes
• All scan results are encrypted in transit (TLS 1.3)
• No source code is copied, retained, or used for training
• Analysis runs in isolated, sandboxed environments
• API keys are scoped and revocable
• SOC 2 Type II compliance planned for enterprise launch