ClearBrief

Inspiration ClearBrief started with a simple barrier: a dense assignment brief can take longer to decode than the assignment itself. For Maya, our fictional composite persona, the hard part is not a lack of motivation or intelligence. It is finding the actual deliverables, deadlines, grading criteria, and unanswered questions hidden inside a wall of text. By the time she understands what the brief is asking, the energy needed to begin may already be gone.

We wanted to build something calmer than a generic task generator. ClearBrief is designed for Maya, a fictional 20-year-old student with ADHD and dyslexia. She is not a real person or a medical case study, and ClearBrief is not a therapeutic or diagnostic tool.

What we built ClearBrief lets a student paste or upload a synthetic assignment brief and receive a Brief Card with:

deliverables deadlines what counts for grading questions to ask a professor a small plan fitted to the time the student actually has The first action is deliberately small: the plan starts with a step that can fit in five minutes. The interface also includes readable type and spacing settings, light/dark/high-contrast themes, reduced motion, visible focus styles, keyboard-first navigation, and live status announcements.

Our differentiator is trust. Every displayed extracted item carries a verbatim source_quote from the input brief. The backend checks that the exact quote exists before the item is shown as grounded. If a quote cannot be verified, the item is dropped or displayed as a visible verification issue; it is never silently treated as fact. Ambiguous dates are marked unclear instead of guessed, and unclear requirements become suggested questions for the instructor.

How we built it The app is a small FastAPI project with Jinja templates and vanilla JavaScript. Pydantic models define the Brief Card contract. The decoding boundary supports an offline record/replay mode, so the demo can run with synthetic fixtures and no API key. TXT and PDF uploads are extracted in memory and are not stored or logged.

The core flow is:

accept pasted text or an in-memory TXT/PDF upload; decode it into a structured Brief Card; normalize dates conservatively; verify each quote against the original source text; render only grounded results plus explicit verification warnings; fit the returned plan to the available minutes. We used automated tests as part of the product design, not just as a final check. The project has unit/API tests, Playwright browser tests, local axe-core checks, keyboard-flow coverage, and a 200% zoom/no-horizontal-scroll check. The final local check is 19 passing tests, including 7 browser checks.

What we learned The biggest lesson was that structured output is not the same as trustworthy output. A model can return valid JSON and still invent a requirement. The exact-quote verifier became a small, understandable safety contract between the source document and the UI.

We also learned that accessibility details change the product itself. A status announcement, predictable focus movement, readable spacing, and a plan that respects the user's available time are not decorative features. They determine whether the student can actually move from reading to starting.

Finally, offline replay records made privacy and reproducibility easier. We could build and test the experience with synthetic briefs without storing user text or requiring a live model call during the demo.

Challenges The hardest technical edge cases were ambiguous dates, conflicting or missing requirements, exact quote matching, and keeping the upload path consistent with the paste path. We also had to make the result state accessible after an asynchronous request, preserve keyboard flow when controls were added, and keep the page usable at 200% zoom.

This submission does not claim full WCAG compliance. It reports automated axe results and manual keyboard-oriented checks, but those are not a substitute for testing with people who use assistive technology. We also have not yet run a formal time-to-first-action study with 2–3 volunteers; that is the next validation step after the hackathon prototype.

Built With

• axe-core
• dateparser
• fastapi
• github
• html/css
• javascript
• jinja
• localstorage
• openai-compatible
• output
• playwright
• pydantic
• pypdf
• pytest
• python
• ruff
• structured
• uv
• vanilla