DEV Community: prabhakar srivastava

Afterlight: tiny objects, improbable afterlives, and a human final say

prabhakar srivastava — Fri, 02 Oct 2026 15:28:57 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.

What I Built

A museum from 2126. Everyday objects, imagined stories, and a curator’s final say.

What would a museum a hundred years from now make of a cassette, a house key, or a light bulb?

In Afterlight, a cassette can become a pocket-sized time machine. A key is permission to come home. A light bulb is borrowed sunrise. Visitors explore ordinary objects with improbable afterlives, while curators decide which stories belong in the exhibition.

The app opens directly into the collection. You can rotate eight original 3D reconstructions, filter collections, inspect objects, and export catalogue records. You can also upload an image of your own object and take it through a complete curator workflow:

Intake → Draft → Review → Exhibition → Withdrawal

The central rule is simple: AI can propose a story. A human decides whether to exhibit it.

Observed details and fictional interpretations have separate fields. Uploaded images remain images; the app does not pretend to reconstruct them in 3D. Gemini’s suggested catalogue details are labelled unverified, and they only enter the form when a curator explicitly selects Use these details.

Demo

Open Afterlight
Watch the 1 minute 38 second demo — English narration and captions, no login required.
Direct video · Transcript

The recording uses the deployed app with real Sanity and Gemini. The sample upload is a render of an original cup model. Authentication and provider waits were edited out; the narration uses a synthetic Microsoft Ava voice. The temporary exhibit was withdrawn and cleaned up after recording.

Try the curator workflow

Visitors can browse without signing in. To test editing, open Curator desk and enter this shared application curator code:

88100113c855c22b561f2af754a350f8c69f88b9dcabd61f

This is the app’s curator access code, not a Sanity or AI-provider API key. It enables changes in the shared demonstration collection.

Inspect the cassette. Rotate it and compare the observed details with its fictional interpretation.
In Curator desk, choose New object → Your photo. Use an image you own or have permission to upload publicly.
Give consent, request Gemini suggestions, review them, and select Use these details if appropriate.
Save the intake record, draft a fictional interpretation with AI, edit the exhibition label, and submit it for review.
Approve the exhibit. Open the public collection in another tab to see it appear, then inspect From object to exhibit for its recorded decisions.
Return your test exhibit to draft with a reason when finished. It disappears from the public gallery while its workflow history remains.

Please create your own test object and leave the starter exhibits intact. Uploaded images can remain accessible by their CDN URLs after withdrawal, so use a non-sensitive image.

Code

Public GitHub repository: prabhakarcs786/afterlight

The repository includes setup instructions, Sanity schemas, workflow logic, tests, and the demo assets.

The stack is Next.js, TypeScript, Sanity Content Lake, Three.js, Gemini, and Vercel.

Sanity Project Details

Project ID: solj2ppn
Dataset: production — private
Public access: approved exhibits through the application
Curator access: the application code above

How Sanity shapes the experience

The schema models collections, artifacts, and embedded workflow events. Each artifact references a collection and separates observed material and details from fictional interpretation, exhibition copy, and a strangeness rating.

Photo exhibits use native Sanity image assets with alternative text. Images are validated, resized, and stripped of metadata before upload.

A workflow transition writes its new state and event together, guarded by Sanity’s revision precondition. If another curator changes the record, an outdated editor receives a conflict instead of silently overwriting it. The UI preserves the unsaved text so the curator can recover their work.

A server-side Sanity listener notifies browsers of changes. Each browser then refetches its public or protected view. This lets a visitor see an approval or withdrawal without manually reloading, while Sanity credentials stay on the server.

This is a custom application workflow built on Content Lake. I did not use the early-access Workflows engine or App SDK.

Starter exhibits are explicitly identified as seed snapshots. The app does not manufacture approval events for them; newly processed objects show their actual retained events.

My Build Process

I used GitHub Copilot in VS Code for the initial build and Codex for release review, verification, and the narrated showcase. The concept, implementation, models, and tests were developed with AI assistance. These are retrospective build notes rather than a verbatim prompt transcript.

1. Start with the rules

Before polishing the screens, I established three constraints: automation cannot approve, incomplete labels cannot enter review, and an exhibited object must return to draft before editing.

Those rules became a shared transition function used by the local demo and the live persistence path. That made the behavior easier to check than rules scattered across buttons.

2. Give the museum real objects

Eight original models were assembled in Three.js. A rendering script generated their thumbnails, and the detail view kept them interactive. Browser checks verified that the scene contained visible pixels and changed when rotation was enabled.

One release issue was surprisingly mundane: development UI badges had been captured in thumbnail screenshots. Exporting the canvas directly fixed the images.

3. Make participation personal

Choosing from eight objects was a useful beginning, but contributing your own object made the idea more compelling. Photo intake added that possibility.

It also introduced another decision: should AI fill the form automatically? I chose reviewable suggestions with explicit acceptance. The curator can distinguish what they entered from what the model inferred before saving anything.

4. Let testing challenge the implementation

Type-checking caught overly broad Sanity create types and, later, a renderer that incorrectly accepted the new photo kind. The renderer now accepts only the eight actual model kinds.

Browser accessibility checks caught low-contrast workflow counters. Reusing the existing muted text color fixed the measured issue. The first Vercel deployment also used the wrong framework preset; explicitly configuring Next.js resolved it.

5. Verify the live loop before recording

Local checks were followed by real Sanity and Gemini exercises on the deployed application: image suggestions, asset storage, AI drafting, review, approval, withdrawal, and stale-write rejection.

Separate curator and visitor browser sessions confirmed that public exhibits appeared and disappeared through live updates. Temporary verification objects and their newly uploaded assets were removed afterward.

Verification

On 2 October 2026, the release passed:

57 unit tests and 12 desktop/mobile browser tests.
Lint, TypeScript checking, production build, and Sanity schema extraction.
Automated accessibility checks and a dependency audit with zero reported vulnerabilities.
Hosted photo and curator workflows using real Sanity and Gemini.
GitHub CI, plus checks of the recording, captions, screenshots, and public media links.

The demo uses a shared curator code and retains the latest 100 workflow events per object. It does not provide individual curator identities or an immutable audit log. Those are clear next steps for a larger museum deployment.

What I Learned

The most useful part of this experiment was turning a strange premise into precise content rules.

Sanity’s schema helped define what had been observed, what had been invented, and what a human had approved. AI made the museum imaginative; those boundaries made it understandable.

Visit Afterlight · Watch the walkthrough · Explore the code

TruthGraph: the right rule depends on when—and for whom

prabhakar srivastava — Fri, 02 Oct 2026 11:11:18 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

What I Built

Ask what happens when a goalkeeper holds the ball too long. Then ask the same question about a match on 1 March 2025.

The wording barely changes. The applicable rule does.

TruthGraph is an evidence agent that works out which rule applies to your situation. It uses Sanity Context to retrieve evidence, then checks dates, match conditions, and relationships between claims before composing an answer with sources.

I built three sports collections: football, cricket, and chess. They contain short, structured claims linked to official rulebooks and announcements. These domains make the problem tangible: the newest rule can be wrong for an older match, and a rule for international play may not apply to a club game.

Every result includes a comparison with a simple keyword baseline over the same claims. When that baseline agrees, the app says so. When it disagrees, you can inspect the condition or relationship that changes the answer.

Demo

Open TruthGraph · Watch the 1 minute 42 second walkthrough

The walkthrough includes English narration and captions. Download the MP4 or read the transcript.

How judges can try it

Open the app and choose Start the guided tour. No account or access code is needed.
Try the historical goalkeeper question, then the substitutes question. Inspect the answer, keyword comparison, and supporting claims.
For a custom question, choose a collection and paste this application access code into Access code:

   989d7decc7cf43958bbad8e3eca301c8c8fce67dc3eb09ec

Try an everyday question about offside, LBW, or castling in the corresponding collection. Custom questions use the live model and Sanity Context; the code does not grant content-management access.

Three moments worth exploring

1. A relevant rule can be wrong for the date.

For the historical goalkeeper example, TruthGraph selects the six-second rule and indirect free kick that applied on 1 March 2025. The keyword baseline selects the newer eight-second rule and corner kick. The effective-date fields explain the difference.

2. Missing context should trigger a question.

“How many substitutes can a team use?” needs a match type. TruthGraph asks for that context instead of treating one match category's rule as universal.

3. You can inspect what changes the evidence.

The Evidence Lab lets you supply a hypothetical condition, such as “club friendly,” and see how it changes the applicability of retrieved claims. It operates on the retrieved snapshot without another model call. The comparison is labelled hypothetical, and the original answer stays visible.

Code

Public GitHub repository: prabhakarcs786/truthgraph

The README includes setup instructions, architecture notes, and commands for unit and browser checks.

Built with Next.js, React, TypeScript, Sanity, the Vercel AI SDK with Gemini, Zod, and semver. I used GitHub Copilot and Codex during development and submission preparation.

How I Used Sanity

I pointed a Sanity Knowledge Base at structured records in Content Lake: sources, claims, and collections. The agent accesses it through a Knowledge Base-only Sanity Context MCP endpoint.

The investigation flow is:

Read the Knowledge Base outline with initial_context.
Retrieve relevant entries with knowledge_base_read.
Extract the question's intent and select claim IDs. The server restricts retrieval to the configured Knowledge Base.
Check that each selected claim is cited by a retrieved entry.
Evaluate the canonical claims against dates, versions, named conditions, and explicit replacement or correction relationships.
Compose the answer from those canonical statements and source URLs, with an inspectable trace.

The model helps navigate and select evidence. Deterministic code evaluates applicability and unresolved conflicts. A generated paragraph alone is not accepted as evidence.

Why the structure matters

Record	Information the agent can use
`tgSource`	Official URL, publisher, authority, and publication/review dates
`tgClaim`	Statement, subject, property, value, effective dates, optional version range, named conditions, and `supersedes`/`corrects` references
`tgKnowledgeBase`	Collection purpose, Context Knowledge Base mapping, and guided examples

These fields let the application explain why a retrieved statement applies. It can retain an older rule for historical questions, ask for an absent match condition, and show conflicting evidence when there is no recorded resolution.

The optional Curate workflow stores precedence decisions as relationships on Sanity claims. Content management is disabled on the public deployment; the local setup supports it with separate administrator credentials.

Sanity Project Details

Project ID: d7k23z8r
Dataset: production (public)
Sanity Context Knowledge Base: TruthGraph (kb0JA1DdQw6D)
Sports corpus: three collections, 34 source records, and 91 claims
Current document count: 143 of the 150-document budget, including recorded tour data

Football sources include IFAB; cricket sources include MCC and ICC; chess sources include the FIDE Handbook. Each claim links to its source so readers can inspect the underlying publication.

What Is Live, What Is Recorded, and Current Limits

The guided tour replays labelled investigations previously run through Sanity Context to conserve the model's free-tier quota. Cached answers are reused only while the relevant question and content checks still match. The result and trace identify recorded runs. Custom questions run live.

The video demonstrates those recorded tour results and uses a synthetic Microsoft Ava voice.

The collections are deliberately small. They are not complete rulebooks. The system can return insufficient evidence, and different phrasings can affect what the model retrieves. Unsupported or uncited selections are rejected; that does not make retrieval infallible. Free-tier provider limits can also temporarily prevent a live response.

The repository includes unit checks for reasoning, grounding, and access controls, plus desktop/mobile browser checks. The deployed recording, screenshots, and public media links were checked on 2 October 2026.

My aim with TruthGraph is to make the path from question to applicable evidence visible: which claim was retrieved, which conditions mattered, and which source supports the answer.