Design-partner pilot

Furnace on one of your repositories, set up with you.

The pilot is free. It takes one working session of about two hours, plus a follow-up a week later to see what Guard caught on your real pull requests. Setup is hands-on: Furnace does not yet configure an arbitrary app by itself, and this page lists exactly what it needs.

Ask about a pilot See a recorded run first

System status: recorded-only site

Control APINOT HERE
Not deployed on this site. Every page shows recorded results.
Guard runnerNOT HERE
Not connected to this site. Live Guard runs happen on the runner machine during a pilot.

This deployment’s own runner. During a pilot, the runner is a machine of yours, and this panel shows yours.

Is it a fit?

Needed: A Python application that builds its prompts in codeScan reads Python with the standard ast module. Other languages are not analyzed.
Needed: A model you serve behind an OpenAI-compatible endpointMeasured on vLLM. SGLang and Ollama adapters exist but have never been run.
Needed: One machine with Docker and an NVIDIA GPU for the runnerDependencies install in one container step; your tests then run with no network, as a non-root user, with a time limit.
Needed: A GitHub repository you can install an App onOne repository per pilot; you choose which.
Not supported: Latency on a hosted API (OpenAI, Anthropic, Groq)Not measured yet. Prompt-prefix stability matters there too, but Furnace has no evidence for it.

Before the call: see what Furnace reads

Scan a public repository, or upload a zip, to get the map Furnace starts from: LLM call sites, prompts, models, serving settings and routes, each tied to a file and line. Nothing is executed during a scan.

Treat the findings as a starting point. On five apps the scanner had never seen, 39 of its 77 findings were right. In the pilot, we check the findings together before Guard relies on any of them.

Scanning is not available on this site.

This deployment shows recorded results only and runs nothing a visitor submits. In a pilot, the scan runs on a connected runner, and we go through the map together.

What you leave the first session with

Baseline

main's rendered prompts measured on your endpoint: geometric-mean and p95 time to first token, prefix-cache hit rate, with the GPU clock recorded.

A real pull request, checked

One recent PR replayed through Guard: which checks it could affect, which ran, and the gate's verdict with its interval.

A repair, only if one applies

If a PR puts per-request values at the start of a prompt, a draft fix that passed the tests and the gate. Otherwise you get a clear statement that nothing supported was found.

A written summary

What was measured, what was inconclusive, and what Furnace could not see in your app.

Setup, step by step

The commands are the real ones. Full detail is in the pilot guide and the GitHub App guide.

01
Fit check (15 minutes)
together
We confirm the items above, and you pick the repository, the endpoint and one recent pull request that changed prompts or serving settings.
02
Install the GitHub App on one repository
you
Created from a manifest that you review before clicking Create. Permissions: read code, write only to new furnace/* branches, open draft PRs, report check runs. No organization permissions.
```
uv run furnace gh-setup --name furnace-<your-org>
uv run furnace gh-check
```
03
Start the runner on your GPU machine
you, with us on a call
The runner pulls jobs from the queue. Your code and keys stay on that machine.
```
docker compose up -d postgres
uv run poe migrate
uv run poe runner
```
04
Describe your app to Guard
we write it, you review it
A suite file that ties your checks to the parts of the app they cover, plus a questions file with real user inputs for the benchmark. This is the setup work Furnace cannot yet do on its own.
```
FURNACE_GUARD_SUITE_PATH=path/to/suite.py
FURNACE_GUARD_QUESTIONS_PATH=path/to/questions.json
FURNACE_GITHUB_ALLOWED_REPOS=your-org/your-repo
```
05
Run Guard on a pull request
Furnace
On each push to a pull request, Guard posts a check run on its head commit: PASS, FAIL or INCONCLUSIVE, with the interval and the evidence. Shown once on a public repository (2026-10-14); see the Demo page.
```
uv run poe gh-poll        # or a webhook to a hosted API
uv run furnace gh-guard your-org/your-repo <PR> --suite $FURNACE_GUARD_SUITE_PATH
```
06
Allow draft repairs (optional)
you decide
Off by default. When on, a supported regression gets a draft PR into the pull request's branch. It is never merged and never pushed to main.
```
FURNACE_GUARD_AUTO_REPAIR=true
```

Configuration

Guard is configured on the runner machine, in its .env file. These settings are the whole configuration; nothing is read from your repository except the code under test. The perf gate itself is fixed: geometric-mean TTFT, 3 interleaved runs per revision, a 90% interval, PASS at or below +10%, BLOCK above +25%.

FURNACE_GUARD_SUITE_PATH	required	Python file listing your checks and the graph nodes each one covers
FURNACE_GUARD_QUESTIONS_PATH	required	Real inputs used to render prompts for the perf gate
FURNACE_GUARD_MAX_PROMPT_TOKENS	optional	Context budget the context check enforces
FURNACE_GITHUB_ALLOWED_REPOS	recommended	Repositories the runner will act on; events from anything else are refused
FURNACE_GUARD_AUTO_REPAIR	default false	Your consent for draft repair PRs
FURNACE_GITHUB_APP_ID, …_PRIVATE_KEY_PATH, …_WEBHOOK_SECRET	written by gh-setup	Kept in .env and ~/.furnace on the runner; never printed or uploaded

What each result means

Every check reports one of these. A skipped check is never counted as passed.

pass: Measured, and the whole interval is inside the tolerance (or the check passed).
fail: A check failed, or a regression was measured beyond the tolerance.
block: Perf gate: slower than the block threshold (25%) with the whole interval above 10%.
inconclusive: Measured, but the interval is too wide to decide. Not a pass and not a fail.
skip: Deliberately not run, with the reason shown (for example: no judge key). Not a pass.
not run: Never attempted: the precondition was missing (no runner, no GitHub App).
unsupported: Outside what Furnace can repair; it says so instead of guessing.

Where your data goes

Your code: Downloaded by the runner with a token scoped to that one repository, and copied into a disposable container. Dependencies install with network access (their install scripts run there, away from your secrets); your code then runs with no network, read-only, with all capabilities dropped.
Your prompts and answers: Sent only to your own endpoint. The database keeps results, logs, diffs and the short code excerpts cited as evidence, not a copy of the repository.
Secrets: Model keys and the App's private key stay on the runner machine. Error messages are scrubbed of credentials.
Webhooks: Accepted only with a valid HMAC signature. Each delivery is processed once, payloads are capped at 5 MB, and pull requests from forks are refused.

Security controls and their tests →

Pilot terms

Free. There is no billing, and nothing to cancel.
What we ask: a 30-minute follow-up and permission to describe the result without naming you, unless you agree to be named.
Pricing later: not set. The pilots exist partly to learn whether teams would pay, and for what.

Design-partner pilot

Furnace on one of your repositories, set up with you.

Ask about a pilot See a recorded run first

System status: recorded-only site

Control APINOT HERE
Not deployed on this site. Every page shows recorded results.
Guard runnerNOT HERE
Not connected to this site. Live Guard runs happen on the runner machine during a pilot.

This deployment’s own runner. During a pilot, the runner is a machine of yours, and this panel shows yours.

Is it a fit?

Needed: A Python application that builds its prompts in codeScan reads Python with the standard ast module. Other languages are not analyzed.
Needed: A model you serve behind an OpenAI-compatible endpointMeasured on vLLM. SGLang and Ollama adapters exist but have never been run.
Needed: One machine with Docker and an NVIDIA GPU for the runnerDependencies install in one container step; your tests then run with no network, as a non-root user, with a time limit.
Needed: A GitHub repository you can install an App onOne repository per pilot; you choose which.
Not supported: Latency on a hosted API (OpenAI, Anthropic, Groq)Not measured yet. Prompt-prefix stability matters there too, but Furnace has no evidence for it.

Before the call: see what Furnace reads

Treat the findings as a starting point. On five apps the scanner had never seen, 39 of its 77 findings were right. In the pilot, we check the findings together before Guard relies on any of them.

Scanning is not available on this site.

This deployment shows recorded results only and runs nothing a visitor submits. In a pilot, the scan runs on a connected runner, and we go through the map together.

What you leave the first session with

Baseline

main's rendered prompts measured on your endpoint: geometric-mean and p95 time to first token, prefix-cache hit rate, with the GPU clock recorded.

A real pull request, checked

One recent PR replayed through Guard: which checks it could affect, which ran, and the gate's verdict with its interval.

A repair, only if one applies

If a PR puts per-request values at the start of a prompt, a draft fix that passed the tests and the gate. Otherwise you get a clear statement that nothing supported was found.

A written summary

What was measured, what was inconclusive, and what Furnace could not see in your app.

Setup, step by step

The commands are the real ones. Full detail is in the pilot guide and the GitHub App guide.

01
Fit check (15 minutes)
together
We confirm the items above, and you pick the repository, the endpoint and one recent pull request that changed prompts or serving settings.
02
Install the GitHub App on one repository
you
Created from a manifest that you review before clicking Create. Permissions: read code, write only to new furnace/* branches, open draft PRs, report check runs. No organization permissions.
```
uv run furnace gh-setup --name furnace-<your-org>
uv run furnace gh-check
```
03
Start the runner on your GPU machine
you, with us on a call
The runner pulls jobs from the queue. Your code and keys stay on that machine.
```
docker compose up -d postgres
uv run poe migrate
uv run poe runner
```
04
Describe your app to Guard
we write it, you review it
A suite file that ties your checks to the parts of the app they cover, plus a questions file with real user inputs for the benchmark. This is the setup work Furnace cannot yet do on its own.
```
FURNACE_GUARD_SUITE_PATH=path/to/suite.py
FURNACE_GUARD_QUESTIONS_PATH=path/to/questions.json
FURNACE_GITHUB_ALLOWED_REPOS=your-org/your-repo
```
05
Run Guard on a pull request
Furnace
On each push to a pull request, Guard posts a check run on its head commit: PASS, FAIL or INCONCLUSIVE, with the interval and the evidence. Shown once on a public repository (2026-10-14); see the Demo page.
```
uv run poe gh-poll        # or a webhook to a hosted API
uv run furnace gh-guard your-org/your-repo <PR> --suite $FURNACE_GUARD_SUITE_PATH
```
06
Allow draft repairs (optional)
you decide
Off by default. When on, a supported regression gets a draft PR into the pull request's branch. It is never merged and never pushed to main.
```
FURNACE_GUARD_AUTO_REPAIR=true
```

Configuration

FURNACE_GUARD_SUITE_PATH	required	Python file listing your checks and the graph nodes each one covers
FURNACE_GUARD_QUESTIONS_PATH	required	Real inputs used to render prompts for the perf gate
FURNACE_GUARD_MAX_PROMPT_TOKENS	optional	Context budget the context check enforces
FURNACE_GITHUB_ALLOWED_REPOS	recommended	Repositories the runner will act on; events from anything else are refused
FURNACE_GUARD_AUTO_REPAIR	default false	Your consent for draft repair PRs
FURNACE_GITHUB_APP_ID, …_PRIVATE_KEY_PATH, …_WEBHOOK_SECRET	written by gh-setup	Kept in .env and ~/.furnace on the runner; never printed or uploaded

What each result means

Every check reports one of these. A skipped check is never counted as passed.

pass: Measured, and the whole interval is inside the tolerance (or the check passed).
fail: A check failed, or a regression was measured beyond the tolerance.
block: Perf gate: slower than the block threshold (25%) with the whole interval above 10%.
inconclusive: Measured, but the interval is too wide to decide. Not a pass and not a fail.
skip: Deliberately not run, with the reason shown (for example: no judge key). Not a pass.
not run: Never attempted: the precondition was missing (no runner, no GitHub App).
unsupported: Outside what Furnace can repair; it says so instead of guessing.

Where your data goes

Your code: Downloaded by the runner with a token scoped to that one repository, and copied into a disposable container. Dependencies install with network access (their install scripts run there, away from your secrets); your code then runs with no network, read-only, with all capabilities dropped.
Your prompts and answers: Sent only to your own endpoint. The database keeps results, logs, diffs and the short code excerpts cited as evidence, not a copy of the repository.
Secrets: Model keys and the App's private key stay on the runner machine. Error messages are scrubbed of credentials.
Webhooks: Accepted only with a valid HMAC signature. Each delivery is processed once, payloads are capped at 5 MB, and pull requests from forks are refused.

Security controls and their tests →

Pilot terms

Free. There is no billing, and nothing to cancel.
What we ask: a 30-minute follow-up and permission to describe the result without naming you, unless you agree to be named.
Pricing later: not set. The pilots exist partly to learn whether teams would pay, and for what.

Furnace on one of your repositories, set up with you.

Is it a fit?

Before the call: see what Furnace reads

What you leave the first session with

Baseline

A real pull request, checked

A repair, only if one applies

A written summary

Setup, step by step

Fit check (15 minutes)

Install the GitHub App on one repository

Start the runner on your GPU machine

Describe your app to Guard

Run Guard on a pull request

Allow draft repairs (optional)

Configuration

What each result means

Where your data goes

Pilot terms

Furnace on one of your repositories, set up with you.

Is it a fit?

Before the call: see what Furnace reads

What you leave the first session with

Baseline

A real pull request, checked

A repair, only if one applies

A written summary

Setup, step by step

Fit check (15 minutes)

Install the GitHub App on one repository

Start the runner on your GPU machine

Describe your app to Guard

Run Guard on a pull request

Allow draft repairs (optional)

Configuration

What each result means

Where your data goes

Pilot terms