BridgeLine

From Paper to Practise !!

Comment

Inspiration

We didn't start with an idea. We started by reading what special education teachers actually complain about.

The same things kept coming up. A single IEP - the legal document that spells out what a student with a disability is owed... takes over seven hours to write. Then it gets filed, and the teachers who are legally required to follow it often never really see it. One teacher put it bluntly: "in some classes I've never even met the sped teacher listed on the doc." Another described getting a stack of ten forms and no idea how to actually act on any of them.

Federal law is not vague about this. 34 CFR §300.323(d) says every teacher responsible for implementing an IEP must have access to it and be told exactly what they're supposed to do. That's not a suggestion, it's a requirement, and it fails constantly.

So the gap isn't writing IEPs. Teachers are good at that, and honestly they should be the ones doing it. The gap is everything after the document is signed. That's what we built for.

What it does

BridgeLine turns a finalized IEP into tracked obligations for every teacher responsible for it.

You upload the document — even a bad scan with handwriting in the margins and a stamp across the text. Five agents process it in a pipeline you can watch stage by stage. The model extracts the accommodations, services, and goals, and for every single value it records the exact sentence and page it came from.

Then it stops. Anything the model isn't confident about gets flagged, and a case manager reviews it. The review screen puts the scanned page next to the extracted data — click a field and the page jumps to the exact quote it was pulled from, highlighted. You never have to take the model's word for anything.

Once a human approves, a deterministic rules engine derives each teacher's legal obligations. No LLM involved in that step at all. Ten rules, each carrying its actual federal citation, each one you can click through to the regulation text on Cornell's site.

And then the part that made us want to build this: the dashboard catches gaps. One student's extended-time accommodation showed as confirmed in three classes. There are six. For three periods a day that kid wasn't getting something they're legally entitled to, and nobody had noticed.

How we built it

Every line of BridgeLine was written with Codex running GPT-5.6, and it did things we genuinely didn't expect.

The compliance rules engine is the clearest example. We didn't hand it code to fix or a function to complete. We handed it a specification we'd written ourselves from the text of federal regulation — ten rules, each with its citation and a plain-English statement of what it requires — and asked for a deterministic engine. It came back with a rule registry where every rule carries its citation, a generator that emits documentation straight from the registry so the docs can never drift from the code, and property-based tests asserting that deriving obligations from the same input twice produces byte-identical output. We didn't ask for that last part. It understood why determinism mattered in a legal context and tested for it.

It also caught a bug in service-minute accounting that our own tests missed, involving partial weeks around school holidays.

The other thing that surprised us was architectural. We're two people and we needed to build a backend and a frontend at the same time without stepping on each other. GPT-5.6 designed the JSON schema contract that made that possible — six schemas, every field documented, generating Pydantic models on one side and TypeScript types on the other. When one of us changed the schema mid-build, the other side's type check failed immediately instead of silently breaking at runtime a day later.

It pushed back on us, too. At one point we asked it to register a legal citation we hadn't finished verifying, and it refused, because the source file still had an "unverified" marker on it. That was the right call and we hadn't thought of it.

One honest note on the stack: Codex on GPT-5.6 built the entire system, but the runtime inference calls in the shipped app go to Gemini, because we ran out of API budget partway through the hackathon window. The LLM gateway is a single module with the model pinned in one place, so it's a config change, not an architecture change.

Challenges we ran into

We destroyed a chunk of our own work about halfway through. A git reset --hard wiped uncommitted changes that hadn't been pushed — the schema, the model definitions, several config files. Nothing on the branch was broken; it just wasn't saved. We rebuilt it in about forty minutes because the specification was written down, but it cost us an evening and taught us to push constantly.

Schema changes mid-build hurt more than we expected. We discovered partway through that our accommodation scope model was incomplete — we recorded that an accommodation applied to a subject, but not which subject. Fixing it meant changing the schema, the extraction prompt, the confidence gate, the rules engine, and regenerating all 100 documents in our dataset. That one gap took a full cycle to close properly.

Free-tier rate limits shaped real product decisions. At roughly fifteen requests a minute, a live extraction takes a while, and we had to design around that instead of pretending it wasn't true.

And keeping two AI coding sessions working in the same repository at once required actual discipline. We split ownership by directory and never crossed the line. It worked, but only because we were strict about it.

Accomplishments that we're proud of

The source-grounded review screen. Every extracted value points back to the sentence and page it came from, and you can see it highlighted on the original scan. We think this is the honest way to put an AI anywhere near a legal document.

The rules engine has zero LLM calls, and there's a test that reads the module's imports and fails if anyone ever adds one. The boundary isn't a promise in a comment, it's enforced.

All ten citations are verified against the actual federal regulation text on Cornell LII and eCFR, not from memory. We checked each one by hand.

And our validation harness reports the metric we actually care about: not raw accuracy, but the rate of fields the model got wrong and marked as high-confidence. A wrong answer that gets flagged is the system working. A wrong answer stated confidently is the failure we were building against.

What we learned

The most useful thing we figured out was where to draw the line between what the model decides and what it doesn't. The model reads documents and extracts facts. It never decides what the law requires — that's deterministic code with a citation attached. Once we drew that line clearly, a lot of design questions answered themselves.

We also learned that GPT-5.6 is much better as an architect than we assumed going in. The instinct is to hand it small, well-defined tasks. The better results came from handing it a real specification and a real constraint and letting it design the solution.

And verification beats trust, for AI and for us. Almost every real bug we found came from someone actually running the thing and reading the output, rather than reading a summary that said it worked.

What's next for BridgeLine

Live brief generation is architected but currently runs on representative data — that's the next thing to finish. After that, progress reconciliation: pulling in gradebook and service-log data to flag when a teacher's narrative contradicts the numbers before an IEP meeting rather than during it.

Longer term this needs to talk to real student information systems, and it needs a proper FERPA review before it touches a single real student record. Everything in this demo is synthetic, deliberately.

But the core is real, and the problem is real. There are teachers right now who don't know what a document requires of them, and students whose accommodations are quietly not happening. That's a solvable problem.

Built With

Share this project:

Updates