# Forge Property Management — 100,000 Work Order Automation Impact Study

> **FICTIONAL / SYNTHETIC DEPLOYMENT MODEL.** "Forge Property Management" is an
> invented enterprise customer. No real customer, property, tenant, vendor, or
> work-order data was used. Every figure here comes from a deterministic synthetic
> corpus and stated illustrative assumptions — not from a real production system.
> This is a synthetic deployment model, not a real customer deployment, and no real
> production results are claimed.

## What this is

A scaled enterprise simulation of the [Work Order Agent Ecosystem](../work-order-agents/)
for a fictional 42,000-unit property manager handling 100,000 work orders a year.
It runs the **real, unmodified ecosystem** — four agents (classify → route →
validate → action) over a real PostgreSQL engine (PGlite) and a real gRPC dispatch
service — against 100,000 synthetic, labeled work orders, then measures operational
performance and models the financial impact versus a fully-manual baseline.

## Why it exists

To answer one question honestly: *if* an enterprise the size of the fictional Forge
PM routed its entire annual work-order volume through this ecosystem, how much of it
could be actioned automatically, how safely, and what would the labor economics look
like — with every number reproducible by a stranger.

## Headline results (synthetic, illustrative)

Run on the full 100,000-order synthetic corpus over live infrastructure (exact
numbers are emitted to `verification-report.json` / `verification-report.md`):

- More than half of all work orders are actioned automatically, with the remainder
  routed to humans as exceptions.
- Zero false auto-actions on the synthetic answer key (the safety-critical metric).
- 100% of work orders carry a complete, append-only audit trail.
- An illustrative annual labor saving in the mid-six figures, with a sub-12-month
  modeled payback, under the stated assumptions in `assumptions.json`.

## Quick start

```bash
# from this folder (runtime deps are resolved from ../work-order-agents)
node verify.mjs                 # full 100,000-order simulation + checks (~15-20 min)
WO_SIM_N=2500 node verify.mjs   # fast development run

node publish.mjs                # build the public case-study page
```

`verify.mjs` regenerates the synthetic dataset, runs the ecosystem end-to-end,
writes `verification-report.json/.md`, and emits machine-readable evidence to
`evidence/` (`simulation-results.json`, `roi.json`, `audit-trace-sample.json`).

## Contents

| Path | What |
| --- | --- |
| `src/enterprise-synth.mjs` | Deterministic 100k synthetic work-order generator |
| `src/roi.mjs` | Transparent manual-vs-agent ROI model |
| `assumptions.json` | All stated operational + financial assumptions |
| `verify.mjs` | Enterprise simulation runner + MUST_PASS verification |
| `build-deliverables.mjs` | Generates the executive report + certification report from results |
| `report/impact-study.md` | Executive impact study (PDF-ready) |
| `datasets/` | Dataset card, sample rows, and dataset manifest |
| `social/` | Social media package (clearly labeled fictional) |
| `proof/` | Full IRS_AUDITOR proof package |
| `publish.mjs` | Static public case-study page generator |

## Honesty & certification

The Proof Layer (IRS_AUDITOR) assigns the authoritative certification state
independently. Because the customer and data are fictional — a disclosed outcome
seam — the state is intentionally not `PRODUCTION_VALIDATED`. The simulation-tier
label is `FICTIONAL_DEPLOYMENT_MODEL_CERTIFIED`, meaning "the simulation itself is
validated and reproducible," which is explicitly distinct from any production
certification. See `proof/LIMITATIONS.md`.
