ClearTerms

Discovery: from public frustration to a product hypothesis

This project did not begin with a request to “build something with AI.” I began with an exploratory scan, using Perplexity to widen the search across public discussions — including Reddit threads about unread terms, surprise fees, and financial language people could not confidently interpret. I used the linked discussions and consumer resources to form early patterns, while treating the scan as hypothesis generation rather than validated user research.

This was generative desk research, not a usability study, so I did not use individual posts as prevalence claims. I looked for situations that repeated across sources. Three became product hypotheses: readers could not tell which clauses deserved attention; costs and conditions were separated across a document; and a plain-language summary felt easier but made it hard to verify what the agreement actually said. Public examples of overlooked fees and the CFPB's large credit-card agreement database helped me frame the opportunity around comprehension and verification, not document shortening.

How might a reader see what matters without replacing the document they are agreeing to?

What I owned — and what AI accelerated

AI played three different roles: discovery assistant, prototyping partner, and the runtime annotation model. Keeping those roles separate was important. It made the speed visible without assigning product judgment to the tool.

Product opinion: annotate, don't translate

The instinctive answer — and many AI tools' default — is to rewrite the agreement in simpler language. I rejected that approach. Financial terms are precision instruments. When a clause says “the fund reserves the right to impose a deferred sales charge of up to 5.5%,” every phrase carries legal weight. “Reserves the right” means the issuer can act but does not have to; “up to” names a ceiling, not a fixed rate. Translating that into “you might pay 5.5% when you sell” strips away conditions that matter.

ClearTerms keeps every word of the original intact and adds a comprehension layer beside it. When users sign, they sign the real agreement — not an AI reinterpretation.

Turning a product principle into AI behaviour

I used model outputs as low-cost behaviour prototypes. Because I no longer have the early interface captures, I reconstructed the decision trail below from the shipped product and my written rationale rather than presenting a polished process that I cannot substantiate. The important artifact was never a “perfect prompt”; it was what I chose to reject, constrain, or expose in the interface.

These decisions changed the system's boundaries and priorities before I polished the screen. I reviewed outputs against four criteria: source preservation, selective prioritization, visible uncertainty, and no sign-or-don't-sign advice.

For this case-study review, I checked those rules against Google's People + AI Guidebook guidance that confidence should inform a user action and that people need control and a feedback path. The product decisions align: confidence is visible, low-confidence output redirects the reader, annotations can be challenged, and every AI layer can be removed.

The interface

The layout is a split view: the full original agreement on the left, untouched; annotations on the right. A summary card gives a plain-language overview with impact badges — red directly affects money, yellow is conditional, blue is standard boilerplate — so readers know where to focus before reading every clause. Annotations stay collapsed by default and expand on demand, keeping the interface quiet until detail is needed.

The linking is bidirectional. Selecting a highlighted clause opens its annotation; selecting an annotation scrolls the original clause into view and pulses it. The source and explanation do not lose each other.

Progressive disclosure controls the information density. The collapsed state carries only an impact level and a one-line explanation; the full rationale appears after the reader chooses to inspect it. That hierarchy supports two modes without creating two products: scanning for risk and reading a specific clause closely. The interface does not force every reader through every annotation before they can understand the document's structure.

Where AI must stop

When the model is not confident about a clause, ClearTerms does not hide that uncertainty. Low-confidence annotations use a dashed border and muted text, with a direct warning to consider consulting a financial advisor. In finance, a wrong interpretation can cost real money; saying “I'm not sure” is safer than presenting a guess as fact.

• A Show Original Only toggle removes every AI layer. The source remains the authority.
• Every annotation includes feedback controls, so the reader can contest the model's interpretation.
• The system never advises signing or not signing. That decision belongs to the person reading.

Beyond clause-by-clause reading

Two outputs turn the document into questions a reader can act on. Hidden Costs gathers fees that are scattered across pages into one view. Questions to Askgenerates questions from the agreement's actual clauses, and every question links back to the clause that produced it. The reader can arrive at a bank with specific questions instead of a generic summary.

Traceability remains the rule in both views. A hidden cost is useful only when a reader can return to the language that creates it; a suggested question is useful only when the bank employee and customer can inspect the same clause. ClearTerms therefore treats summaries as navigation into evidence, not as replacements for it.

Limits, and what's next

ClearTerms currently handles English only and works best with North American agreements. The discovery work identified hypotheses rather than validated needs, and the product has not yet been through a formal usability evaluation. The next step is task-based testing on whether readers can locate consequential clauses, explain uncertainty, and form better questions without over-trusting the model. A production version would also need a reviewed evaluation set, domain-expert calibration, refusal thresholds, and ongoing feedback review. The current React, Tailwind CSS, and Claude API product is a working solo build — evidence of the decisions so far, not proof that the high-stakes problem is solved.