AccessCrash

Eligibility is not access.

Comment

Inspiration

Education programs often focus on eligibility: who qualifies, which documents are required, and what deadline applies. But qualification does not guarantee a workable route through identity checks, devices, communication channels, documents, office hours, and dependent steps.

This gap has real consequences. The U.S. Government Accountability Office reported that technical and identity-verification problems prevented some families from accessing FAFSA during the 2024–25 rollout, while nearly three-quarters of calls to the support center went unanswered during its first five months. GAO-24-107407

We built AccessCrash around one idea: eligibility is not access. Before an institution publishes a process, it should be able to test whether an otherwise eligible person has any valid path to completion under bounded, functional constraints.

What it does

AccessCrash begins with fictional education-application instructions. For the demo, we use Pineglass Institute · Access Grant, a synthetic emergency-aid process.

  1. GPT-5.6 compiles the instructions into a strict process graph. Extracted rules retain inspectable candidate source citations and the result remains unconfirmed. V1 byte-matches normalized quotes for text sources; PDF excerpts remain explicitly review-bound. It does not attest document authenticity or semantic support. For the exact bundled Pineglass source only, validated grounded live extraction is then deterministically normalized to the documented fixture topology with a visible warning; general sources are not normalized.
  2. A human inspects citations plus each rule's prerequisites, capability routes, duration, and availability, then either confirms the displayed draft as-is or rejects it and recompiles. V1 has no graph editor and does not claim to correct a rule. Ambiguity remains visible rather than becoming model certainty.
  3. Deterministic code compares a standard synthetic profile with a capability-constrained twin. Only access conditions differ.
  4. The engine returns REACHABLE, BLOCKED, or UNKNOWN and shows the valid route, exact blocker, relevant cycle, or unresolved evidence that produced it.
  5. For the bundled default constrained twin, the demo applies a three-change repair set of bounded in-memory alternatives — email verification, mobile upload, and evening review — and runs the same profile again, producing a clear BEFORE / AFTER recovery. If a judge selects another constraint that the set does not address, the UI reports the actual remaining BLOCKED or UNKNOWN result instead of claiming recovery.

The language model cannot decide reachability or eligibility because those fields are absent from its output contract. A graph is not eligible for authoritative evaluation until a human confirms it. Equal eligibility is a synthetic test assumption held outside AccessCrash; the product neither verifies it nor receives applicant eligibility data.

How we built it

AccessCrash is a TypeScript web application built with React, vinext, strict Zod contracts, the OpenAI Responses API, and a pure deterministic graph engine.

The compile endpoint accepts public or organization-owned non-personal process text from 40 characters through 96 KiB, UTF-8 TXT/Markdown up to 96 KiB, or one PDF up to 4 MiB. Student/applicant records, PII, and confidential case data are prohibited. PDF file name, allowed MIME type, and %PDF- signature are checked; the bytes remain in memory and are sent to the OpenAI Responses API as an input_file data URL at detail: "low" for provider-side extraction. The app does not crawl embedded links, execute document content, or persist the file. The model call uses exact gpt-5.6-sol with low reasoning, low text verbosity, structured output, store: false, one call per accepted request, a 10,000-token output cap, zero automatic retries, and a 60-second timeout.

Production fails closed to the explicit synthetic fallback unless the server-side live-model flag is enabled. That flag is not authentication or a quota; it must remain false until server-side identity and persistent per-user quota/rate controls are implemented and verified.

The result is validated twice: first for strict structure, then for authority and graph invariants. The compile envelope is always confirmed: false, every step begins unconfirmed, and the model contract contains no verdict. Missing key, refusal, timeout, API failure, exact-Pineglass identifier/route-contract drift, or invalid output produces a visibly labeled synthetic fallback instead of pretending a live compile succeeded.

Graph invariants require the declared outcome to reference a step with kind: "outcome" and every declared step to belong to that outcome's dependency closure. Any unconfirmed declared step makes the deterministic result UNKNOWN; it cannot be ignored because an apparent path does not traverse it.

After confirmation, a side-effect-free engine performs graph reachability, cycle and blocker analysis, capability-twin comparison, and before/after regression. The prototype has no application persistence. The public demo and fixtures are synthetic; runtime intake is limited to authorized, non-personal process documents.

Because each profile represents one person, a REACHABLE path must have a proven non-overlapping serialized schedule inside its windows and deadline. If bounded ordering remains ambiguous, the engine returns UNKNOWN rather than assuming parallel work or declaring a false block. allOf is unordered and canonicalized; cycle evidence uses a canonical representative. Deterministic aggregate work budgets fail fast to analysis-limit UNKNOWN.

Report generation re-evaluates the exact process/profile and rejects a stale or forged caller-supplied assessment whose complete result differs. Before/after comparison requires the same declared outcome and identical capability-ID vocabulary, is capped at 64 profiles, and exposes blocker/unknown-reason IDs plus canonical assessment-evidence fingerprints on both sides, including content changes between two equal verdicts.

How Codex and GPT-5.6 were used

Codex was the build partner across product and engineering. It helped us:

  • challenge several ordinary concepts and narrow the product to a real education-service failure mode;
  • establish the critical model → human → deterministic authority boundary;
  • design the graph contract, reachability and regression cases, and safe fallback behavior;
  • implement the API, engine, responsive interface, fixtures, tests, and documentation in parallel;
  • audit privacy, prompt injection, stale confirmation, model-failure, and overclaim risks;
  • review the final build against the four equally weighted judging criteria.

Key product decisions remained explicit: we selected Education, prohibited real student data, kept eligibility and fairness outside the product, and required UNKNOWN whenever the graph cannot support a proof.

GPT-5.6 has a separate runtime role. It converts messy instructions into a source-grounded draft graph and surfaces ambiguity. It does not confirm the graph and cannot return the deterministic verdict.

Primary /feedback Codex Session ID: 019f7221-2421-78e3-b12e-f6082da1ed87

Challenges

Useful model reasoning without model authority

Process instructions are semantic, but a reachability verdict must be repeatable. We solved that by giving GPT-5.6 no verdict field, keeping every compile unconfirmed, requiring human review, and moving all path decisions into pure code.

Making uncertainty a real state

A binary pass/fail interface would force missing evidence into false confidence. UNKNOWN is therefore a first-class deterministic outcome for any unconfirmed declared step, unknown capability, unresolved timing/dependency, or bounded exact-analysis limit.

Demonstrating impact without sensitive data

Education support can involve highly sensitive records. The Build Week version uses one fictional institution, program, source document, and capability set; it stores none of them. The product demonstrates process mechanics without claiming to evaluate a real student.

Keeping the fix honest

The Test 3-change repair set action swaps to a bounded in-memory state of the fictional process with three alternatives applied together. It does not edit an institution's policy. It opens the bundled default twin's route, but may leave a different selected twin blocked or unknown; the UI follows the actual engine result. A reachable graph does not certify that a real change is safe, fair, legal, or complete.

Accomplishments

  • A complete source → draft → confirmation → crash-test → regression loop.
  • An explicit three-part authority model: GPT compiles, a human confirms, deterministic code decides.
  • Source-linked rules instead of opaque model prose.
  • Capability twins that isolate operational access conditions without creating demographic personas.
  • Three honest deterministic outcomes: REACHABLE, BLOCKED, and UNKNOWN.
  • A reproducible Pineglass Institute · Access Grant baseline, repair, and regression.
  • Transparent fallback behavior for every controlled model failure.
  • Bounded PDF/TXT/Markdown intake with provider-side PDF extraction, no URL crawling, and no application persistence.
  • Security, privacy, product, architecture, testing, and demo contracts in the public repository.

What we learned

The strongest use of a reasoning model was not the final decision. It was turning unstructured instructions into an inspectable candidate representation that a person and deterministic engine could challenge.

We also learned that “accessible page” and “reachable service” are different questions. A flow can have individually usable screens and still fail as a system because its channels, dependencies, or timing remove every route.

Finally, uncertainty deserves product treatment. UNKNOWN is not a weak answer; it is the correct answer when the source cannot support a proof.

What's next

  • pilot the workflow with education service designers using fully synthetic or approved de-identified process material;
  • measure reviewer agreement, time to identify a dead end, and false positive/negative blocker findings;
  • add versioned source and graph provenance without collecting applicant data;
  • support collaborative review with an explicit retention and access model;
  • expand capability predicates only through participatory research and safety review;
  • validate proposed service changes through usability and accessibility testing, not graph analysis alone.

Built by Evaldas Vigelis at EV1 Labs · Explore the OpenAI Build Week collection.

Built With

Share this project:

Updates