A forensic way to understand a codebase.

30-second architecture

One runtime, small layers with one job each.

FORGE is not a single script that scans a repository and prints findings. It is a small set of layers, each with one job, composed by one runtime.

Methodology

Observe | Hypothesize | Falsify | Verify | Seal

The implementation separates observations, hypotheses, verification, and presentation. Select a stage to inspect what it does and what it does not claim.

A quick evaluation frame

Not another “find bugs” prompt.

FORGE makes the things a reviewer needs to trust an audit part of the result: declared scope, evidence, rejected hypotheses, limitations, role boundaries, and reproducible artifacts.

The real runtime roles

Bounded agents, one sealed result.

Each role has a limited responsibility. The orchestrator merges provenance-bearing findings; it does not let one agent silently reason on behalf of another.

Source of truth: the current runtime validates the roles listed in forge/agent_protocol.py. Documentation and implementation are intentionally linked here so technical reviewers can inspect both.

Evidence, not theater

Daubert-inspired engineering boundaries.

FORGE borrows forensic discipline: distinguish observation from inference, preserve discarded hypotheses, expose the testable boundary, and make artifact integrity independently checkable.

audit_repository(path="/path/to/repository", output_dir="forge-run")
get_findings(run_output_dir="forge-run")
get_coverage(run_output_dir="forge-run")
verify_seal(sealed_path="forge-run/verification-manifest.sealed.json")

Dogfooding and stress tests

Forge is part of the evidence, too.

The project treats its own defects and its blind spots as material for the audit trail. This is not a claim of perfection; it is a commitment to preserve the correction path.

All successful and failed historical FORGE runs are published for review in annatchijova/forge-results.

Public case studies / Casos públicos

Real repositories, visible adjudication.

FORGE was not demonstrated on repositories seeded with bugs. The snapshots, source history, sealed artifacts, and subsequent fixes are public so judges can inspect the complete path.

Boundary: a FORGE finding is not automatically a confirmed vulnerability, and a false positive is not automatically useless. Both the original evidence and the adjudication remain visible.

Read the full case-study record →

Skills: honest applicability

A policy document is not automatically an executable detector.

The skills catalog is deliberately visible here because reviewers should be able to see the difference between a documented policy, an executable contract, and a result marked undetermined.

This distinction is intentional: Forge must not imply that a policy was enforced merely because a Markdown document exists. The skill runtime records applicability and limits; an unresolved applicability can trigger an abstention.

Read the governance skill contract and catalog →

How the project was strengthened

Human-led, model-assisted engineering.

The collaboration history belongs in the documentation because it explains how Forge was improved, while keeping a firm boundary: built-in audit decisions remain local and deterministic unless a future model-backed adapter is explicitly installed and recorded.

Attribution note: the Terra/Luna session history is build context provided by Anna Tchijova. It is not embedded in a sealed audit artifact and is not used by Forge to make an audit decision.

Read the source

This page is a map, not a substitute for evidence.

The technical claims above point to repository materials. Start with these primary documents and implementations.