FORGE collects anonymized structural metadata to improve the algorithm for everyone.

What is FORGE?

FORGE is a fixpoint-based output repair framework for generative AI systems. It applies iterative correction lanes to LLM outputs until they converge to a structurally valid, self-consistent state — or it detects that convergence cannot be reached and terminates the loop gracefully.

The fixpoint repair process works by running a pipeline of typed "lanes" — structural validators, schema enforcers, format normalizers, and content-aware repair operators — in a loop. Each iteration takes the previous output, runs it through all active lanes, and checks whether the result has converged (i.e., whether the output is unchanged from the previous iteration). If it has, the repair is complete. If not, the loop continues.

When a repair loop fails — whether from oscillation (cyclic outputs), budget exhaustion, maximum iteration limits, lane errors, or parse failures — FORGE can optionally construct and transmit an anonymized FailureRecord describing the structural characteristics of that failure. This data enables pattern analysis across the entire FORGE user base, driving targeted improvements to lane ordering, convergence heuristics, default budgets, and failure detection algorithms.

Explore This Site

Dive into the details of how FORGE handles telemetry data — or confirm that it doesn't collect any personal data at all.

Telemetry at a Glance

A quick summary of the FORGE telemetry system's design, operation, and guarantees:

What a FailureRecord Contains

Each telemetry record contains exactly the following fields — no more, no less. This schema is enforced at the code level; additional fields cannot be added without a code change that would be visible in the commit history. For detailed descriptions of each field, see the Privacy Policy.

record_id             UUID       # random, not linked to any identity
timestamp             epoch      # rounded to the nearest hour boundary
forge_version         string     # semver of the FORGE library (e.g. "0.4.1")
deployment_id         hex        # opaque SHA-256 hash (hostname + PID)
content_type          enum       # "diff" | "json" | "text" | "code" | "structured"
content_length_bucket enum       # "tiny" | "small" | "medium" | "large"
structural_shape      dict       # abstract schema description, no actual values
failure_class         enum       # "oscillation" | "budget_exceeded" | "max_iterations" | ...
lanes_executed        string[]   # names of repair lanes that ran
lanes_failed          string[]   # names of repair lanes that errored
lane_state_transitions string[]  # state machine transitions observed
iteration_count       integer    # total fixpoint iterations attempted
oscillation_detected  boolean    # was a cyclic pattern detected?
fingerprint           hex        # SimHash of structural features (never content)

What is Never Collected

These categories of data are explicitly excluded from FORGE telemetry — by design, not merely by policy. The telemetry subsystem physically cannot access them because content data is never passed to the record construction code.

• Raw content of any kind — no diffs, patches, JSON documents, text bodies, or code snippets
• LLM prompts and outputs — no system prompts, user messages, completions, or conversation history
• File paths or filenames — nothing from your local filesystem or repository
• IP addresses — the Cloudflare Worker receiving telemetry does not log source IPs
• User identities — no usernames, email addresses, GitHub handles, or account information
• Credentials — no API keys, tokens, secrets, passwords, or auth headers
• Organization names — no company, team, project, or repository identifiers
• Environment variables — no env var names or values (except the opt-out flag status)
• Exact content lengths — byte counts are replaced with coarse buckets (tiny/small/medium/large)
• Exact timestamps — times are rounded to the nearest hour to prevent timing correlation

How to Opt Out

Disable telemetry upload at any time using either method below. Both take effect immediately — no restart is required in most configurations. When disabled, FORGE will not make any network requests related to telemetry.

export FORGE_TELEMETRY_UPLOAD_ENABLED=false

telemetry_upload_enabled: false

Data Flow Overview

From failure detection to improvement — every step of the telemetry pipeline at a glance. For detailed explanations of each stage, see the Transparency Report.

Open Source

The entire telemetry system — data collection, record construction, worker endpoint, and analysis tooling — is open source. You can audit every line of code that touches telemetry data. We believe verifiable privacy is more trustworthy than promised privacy.

Questions or Concerns?

We believe transparency builds trust. If you have questions about FORGE telemetry, want to report a concern, or need to discuss a specific deployment scenario, there are several ways to reach the maintainers:

• Issue tracker — Open an issue at github.com/RainTechRepos/FORGE/issues for questions, bug reports, or feature requests related to telemetry
• Source code — Review the telemetry implementation at forge/telemetry/ to verify exactly what is collected and transmitted
• Privacy Policy — Read the full privacy policy for field-by-field details, anonymization methods, and legal basis
• Transparency Report — Read the transparency report for the complete data lifecycle, from collection to public disclosure