La Linterna

La Linterna reveals how messages are constructed—claims, framing, context, and sources—so people can think for themselves.

Comment

Inspiration

La Linterna started from a question I had been carrying for a long time: Can technology help people understand how a message is constructed without telling them what to think?

While building other AI products, I kept seeing the same pattern. Most tools focused on generating more content, summarizing it, classifying it, or judging whether it was true. Very few helped users slow down and observe the message itself: what it emphasizes, how it frames events, what context it includes, and whose voices it relies on.

That became the foundation of La Linterna.

Its purpose is not to replace people’s judgment, but to give them more visible information to form their own.

What it does

La Linterna analyzes a Spanish-language message across four observable dimensions:

  • What it claims
  • How it frames those claims
  • What context helps interpret it
  • Which sources are visible and how traceable they are

The result begins with a short general reading and three high-value observations.

Users can then expand each observation to inspect:

  • the exact quotation that supports it;
  • the analytical criterion applied;
  • the level of textual support;
  • the visible traceability of the source;
  • the limitations of the analysis.

Every finding must be connected to literal evidence present in the submitted text.

La Linterna does not:

  • declare statements true or false;
  • classify content as propaganda;
  • assign ideological labels;
  • infer hidden intentions;
  • tell users what they should think.

Its purpose is narrower and more transparent: to help people observe how a message is constructed.

How I built it

La Linterna is a full-stack Next.js application built with:

  • Next.js App Router
  • React
  • TypeScript
  • Zod
  • OpenAI Responses API
  • GPT-5.6
  • Structured Outputs
  • Vitest
  • Vercel

The analysis engine is separated from the interface and organized around a versioned methodology:

LIN-METH-0.1.1

The server requests a structured response from GPT-5.6 and validates it against strict schemas.

It then independently verifies that every quoted piece of evidence exists literally in the original text.

The application also validates:

  • output limits;
  • methodology version;
  • highlight references;
  • unique finding identifiers;
  • source-traceability values;
  • evidence-support values;
  • category-specific schema requirements;
  • duplicated observations.

Invalid evidence is filtered deterministically, and analyses that no longer satisfy the final contract are rejected rather than silently repaired.

The current public version does not require an account and does not store a history of submitted messages.

How I used GPT-5.6

GPT-5.6 is the analysis engine behind La Linterna.

It receives the submitted message together with the versioned methodology and produces a structured result containing:

  • a concise general reading;
  • claims;
  • framing observations;
  • contextual observations;
  • sourcing observations;
  • three global highlights;
  • explicit limitations.

I use Structured Outputs so the model returns a predictable and machine-validatable result instead of free-form commentary.

After controlled testing, GPT-5.6 was configured with low reasoning effort.

This preserved the methodological quality while substantially improving speed and token usage.

In one representative test:

  • analysis time fell from approximately 65.8 seconds to 26.3 seconds;
  • output usage fell from 3,249 tokens to 1,572 tokens;
  • internal reasoning used 270 tokens.

GPT-5.6 proposes the observations, but the application independently validates the structure, references, output limits, and every literal quotation before displaying the result.

How I used Codex

Codex acted as my main engineering collaborator throughout Build Week. I used it to scaffold the Next.js application, integrate the Responses API, evolve the Zod schemas, implement literal-evidence validation, diagnose API and timeout failures, build the editorial interface, expand the automated tests, and prepare the deployment on Vercel.

The product and methodological decisions remained human-led. I defined the four analytical dimensions, rejected truth scoring and ideological classification, required literal evidence, reviewed every real output, and decided each iteration based on quality, latency, cost, and methodological consistency.

Challenges I ran into

Making the analysis useful without making it overwhelming

The first successful result was methodologically promising but contained around thirty observations.

It took too long to read and produced too much output.

I evolved the methodology to:

  • prioritize only the most relevant findings;
  • limit each analytical category;
  • reduce duplicated evidence;
  • introduce three global highlights;
  • separate the quick reading from expandable detail.

Separating textual support from source traceability

An observation can be directly supported by the submitted text even when the original source named inside that text is vague.

I therefore separated two concepts:

  • evidenceStrength: how clearly the submitted text supports La Linterna’s observation;
  • sourceTraceability: how identifiable the original source is within the message.

This avoids treating a vague source as if the observation itself were unsupported.

Improving latency and token usage

A strong analysis initially took more than one minute.

Instrumentation revealed that output usage included internal reasoning tokens.

By configuring GPT-5.6 with low reasoning effort, I reduced the representative execution to 26.3 seconds and 1,572 output tokens without materially reducing quality.

Preventing invented evidence

I did not want the interface to display invented, paraphrased, or mismatched quotations.

The server therefore verifies every evidence quotation against the exact submitted text.

If a quotation cannot be located literally, it is removed. A finding is removed when none of its evidence remains, and the complete analysis is rejected if filtering breaks the final validated contract.

Designing trust into the interface

La Linterna must not resemble a chatbot, political scorecard, or truth detector.

The interface was designed as a calm editorial reading experience with:

  • concise summaries;
  • expandable evidence;
  • citizen-friendly labels;
  • explicit limitations;
  • no red/green truth signals;
  • no ideological scoring;
  • no hidden confidence percentages.

Accomplishments I'm proud of

  • A working public product built during Build Week.
  • A versioned and documented methodology.
  • Structured analysis with literal evidence.
  • Clear separation between textual support and source traceability.
  • Three global findings for fast reading.
  • Server-side validation beyond the model response.
  • Honest limitations that remain visible to the user.
  • 66 automated tests covering the engine and product experience.
  • A responsive editorial interface.
  • Public deployment on Vercel.
  • No authentication, analytics, tracking, or stored message history in this first release.

What I learned

Learning to remove, not only add

I learned that the hardest product decision was not what to add, but what to leave out. A technically richer analysis was not necessarily a better user experience. The most valuable result was the one that revealed the essential construction of the message first, while keeping the deeper evidence available for anyone who wanted to inspect it.

I also learned that building La Linterna was very different from carrying the idea. Working under a real deadline forced me to decide what its first useful version should actually be.

What's next

The current release is a focused first vertical.

Future development may include:

  • testing consistency across more message types;
  • support for additional languages;
  • quick and deep analysis modes;
  • external methodological review;
  • evaluations using annotated message sets;
  • optional privacy-controlled deployment;
  • accessibility improvements;
  • educational workflows for media and information literacy;
  • comparisons of how different messages frame the same event;
  • analysis of AI-generated answers and observable AI behavior.

The methodology will remain versioned, inspectable, and separate from any specific model.

Why it matters

People do not need another system that tells them what to think.

They need better tools to understand the information they receive.

La Linterna does not aim to become an authority over reality.

It aims to make its own observations transparent, traceable, and open to scrutiny.

Built With

  • artificialintelligence
  • codex
  • generativeai
  • github
  • gpt-5.6
  • informationliteracy
  • javascript
  • jsonschema
  • medialiteracy
  • next.js
  • node.js
  • openai
  • openaiapi
  • openairesponsesapi
  • promptengineering
  • react
  • responsibleai
  • structuredoutputs
  • tailwindcss
  • typescript
  • uxdesign
  • vercel
  • vitest
  • webapplication
  • zod
Share this project:

Updates