The Taskmaster · Deployed on Google Cloud
A deadline keeper, not an appeal decider.
Sixty Days reads a synthetic disaster-assistance decision letter, preserves the exact stated reason, organizes supporting evidence, prepares applicant-controlled requests, tracks the deadline, and builds a reviewable draft packet. It never sends or submits.
Public proof: the shared-substrate exit test passes 10/10, separately from the product-specific 24-step flow. Open the live product or inspect the public repository.
If you have sixty seconds
Start the guided preset, inspect its eight registered wakes, compare the close and wide evidence fixtures, then advance time and watch the scheduled safeguard build a visibly partial packet automatically. Open the conformance map for the official-source-to-code-to-test chain.
Evaluation map
Where each scoring claim is proven
Claims below point to executable behavior, measured recordings, or an explicit boundary.
| Criterion | What is distinctive | Evidence |
|---|---|---|
| Innovation | A standing 60-day watch converts one letter into an eight-wake plan and evidence routes. When the packet safeguard becomes due, it executes PacketBuilder against current accepted evidence and stores a partial-safe snapshot without sending it. | Run the four-stage console; inspect sixty_days/wake_actions.py, deadline.py, and packet.py. |
| Taskmaster fit | The workflow completes connected work: understand, gather, track, and review, while preserving applicant control. | The public acceptance script verifies 23 linked behaviors. |
| Architecture | Gemini readers and evidence checks sit behind typed routes, deterministic clocks, durable Firestore state, redaction, and independent verification. | Architecture below, conformance report, and standalone test suite. |
| Production readiness | Deployed service, bounded autoscaling, health endpoint, structured observability, measured fixtures, accessibility gate, and replayable demo. | Live URL, Cloud Run facts, recording reports, and reproduction commands. |
Mandatory technology
Requirements are visible in the execution path
Gemini 3.5 Flash
Vertex AI powers decision-letter transcription and observable evidence-photo checks. Four letter calls and two evidence calls are recorded and graded against adjacent truth.
Google GenAI SDK
The reader and recording scripts use the Google GenAI SDK with structured outputs. Deterministic fixture replay keeps public judging repeatable.
Google Cloud
Cloud Run serves the application; Firestore holds structured cases and wakes; Cloud Scheduler drives the shared due-wake worker; Cloud Trace receives spans.
Three additional Google models: Gemma 4 reviews already-pattern-redacted text for remaining person names; Gemini 3.1 Flash Image creates the non-data-bearing first-use illustration; and Veo 3.1 Fast creates the optional four-second motion briefing. Media prompts, model IDs, byte counts, and hashes are public in the provenance manifest. Generated media never becomes case evidence, enters a packet, or predicts an outcome.
Deployment proof
What is live, and what is shared
The product service and the scheduler worker are named separately to avoid implying a boundary that does not exist.
- Service:
sixty-daysinus-central1, bounded to three instances and running assa-reason. - Scheduler:
spine-scan-dueinvokes the shared spine worker, which claims due wakes from the same Firestore substrate. It is not represented as a second Sixty Days service. - Acceptance:
scripts/sixty_days_demo_flow.pyperforms 23 public HTTP checks;/exit-testexercises the shared 10-stage substrate. - Measured fixtures: truth sits next to every synthetic input. Reports record 20/20 extracted fields and 6/6 evidence decisions.
Reproducibility
Run the same gates locally
cd app
python -m venv .venv
.venv/bin/pip install -e ".[dev]"
python -m pytest -q
python scripts/check_a11y.py
python scripts/sixty_days_demo_flow.py --url https://SERVICE_URL
curl -X POST -H "Content-Type: application/json" -d '{}' https://SERVICE_URL/exit-testThe expected standalone baseline is 205 tests. Deployment and credentials are documented in the repository README and deploy.sh.
Findings and learnings
The hard parts were trust boundaries, not prose generation
Quote before reasoning
Keeping the exact decision reason beside every action prevents a polished packet from drifting away from what the letter actually said.
Audit the redaction artifact
An audit found all-caps applicant names and FEMA registration references missing from an older pattern set. Regression tests now enforce PERSON and CASE_REF coverage.
Partial is safer than false-complete
A packet may be generated with missing items visibly listed. The verifier refuses to turn absence into a confident claim.
Test the two demos together
A parallel rehearsal exposed a shared simulation clock: one submission could move the other's timeline. Demo clocks are now namespaced, simulated wake claims check run ownership, and the production wall-clock worker remains shared.
Research-to-design trace
Each source changes a guardrail
Official examples are treated as routing options, never as a promise that one document will change an outcome.
| Official finding | Implemented decision | Boundary |
|---|---|---|
| The decision letter identifies the documents relevant to that determination. | Every requirement begins with an exact quoted reason; unknown reasons stop for caseworker review. | The catalogue cannot override the applicant's letter. |
| FEMA lists several ownership and occupancy records, including alternatives when public-record matching fails. | The planner names multiple accepted examples and their date context instead of prescribing one rigid document. | No listed record is called sufficient or outcome-determinative. |
| FEMA's insurance guide distinguishes settlements, denials, and policy evidence of exclusions or missing coverage. | The insurer route requests those records and no longer treats an unsupported signed statement as equivalent. | The applicant sends the request; no insurer is contacted by the service. |
| A September 2025 FEMA IHP explainer tells applicants to put application and disaster numbers on every submitted page. | The PDF repeats synthetic application and disaster references in every page footer and asks the applicant to verify them. | The PDF remains optional, unofficial, and not submitted. |
FEMA ownership and occupancy fact sheet · FEMA insurance quick reference · FEMA IHP application, eligibility, registration, and appeals explainer
Limits
Deliberate non-capabilities
- Synthetic, unbranded fixtures only; no real survivor data is used.
- No legal advice, eligibility prediction, appeal strategy, or outcome forecast.
- No insurer, agency, records office, or other third party is contacted.
- No send or submission endpoint exists. The applicant reviews and controls every external action.
- Photo checks are limited to observable framing and legibility, never damage valuation.
- The generated PDF is an organizing draft, explicitly marked not submitted.
Policy basis: FEMA appeal quick reference and GAO-20-503.
Validation without invented testimonials
No practitioner or applicant study is claimed. Public research establishes the workflow context; executable tests, recorded fixtures, adversarial probes, live acceptance, and explicit limitations establish what this build actually does. Legal accuracy, eligibility, and applicant usability remain unproven.