GPTable / Case study

Keep working with what you make.

GPTable puts an AI assistant, a file directory and an editor in one workspace. I wanted to take a response apart, work on a section myself and ask for a change without losing that work. The walkthrough follows one note from generation to review and back to its saved version.

Try the demo Follow the current workflow Read the story

The application / at a glance

What I built

Starting point

A request
Selected saved files

Workspace design

Create, edit, review, return

Keep the saved source
Preview and save linked notes
Save manual edits
Review before Apply

Application stack

Next.js / FastAPI / PostgreSQL

Working material

Editable files and saved database versions

Isolated development app · real sign-in · PostgreSQL · local Qwen3.5 9B. One fictional workflow; production qualification remains separate.

Project state: In development · authenticated workflow verified
Built with: Next.jsTypeScriptFastAPIPostgreSQLPython

GPTable / Through the current interface

Files you can keep working with.

Follow a request through organized files, a manual edit, a reviewed revision and the same saved file reopened.

The example

A fictional design notebook becomes 5 linked topic notes. The operator saves a cost comparison, asks for one heading change, then reviews and reopens the saved result.

Recorded step / 01

Start with a brief

A real model run begins before any file is saved.

Saved files: 0
Next: Save the source

Execution started with no saved files. — The app shows execution in progress with zero saved files. Fictional design exercise.
Open full-size image

Checks for this step

A saved source is followed by topic notes saved together.
Creation and revision have separate completed model executions.

The saved result

3 versions of the same file.

v1v2v3

1 initial response · 1 revision response · 1 explicit Apply. The saved note returned after reload and an orderly restart.

Saved files

Saved model source Saved version 2 Saved version 3 Inspect the verification record

Earlier preview walkthroughTwo recorded runs, with separate evidence

The earlier run used a different model and local preview storage. Its captures and verification record remain available here.

What supports this walkthrough?Recorded checks, frozen source and limits

The checks behind the screenshots.

This recording covers one saved workflow. General model quality, production security and crash recovery remain outside this check. Raw HTTP/SSE replay was not performed. Browser download was not verified. The saved source includes the app's Draft provenance footer. Topic notes are previewed and saved in a separate, explicit commit.

The record follows actual sign-in, saved source, explicit topic-note organization, a reviewed candidate and the same file reopened from PostgreSQL. Terminal receipts support the model requests; raw HTTP/SSE replay was not performed.

Local model / recorded requests

Qwen3.5 9B

1 initial request · 1 revision request. Saved content and terminal receipts identify these requests.

Workflow checks passed: 13 / 13

An incorrect password was rejected.
Passed
A fresh password sign-in reached the current app.
Passed
A saved source is followed by topic notes saved together.
Passed
Only the requested heading changes; the manual note remains.
Passed
The saved review request matches its recorded incoming fingerprint.
Passed
A recorded automated operator decision precedes one explicit Apply.
Passed
The orderly restart preserves the same containers, images, settings and volumes.
Passed
Saved files and versions match after reload and restart.
Passed
Saved version 3 has identical content after Apply, reload and restart.
Passed
The saved note and other files remain unchanged until Apply.
Passed
Proposed content matches the exact pre-frozen heading change.
Passed
The retained proposal waits for an explicit Apply.
Passed
Creation and revision have separate completed model executions.
Passed

Recorded / verified: 2026-10-27 / 2026-10-27T13:59:16.665937+00:00
Application / storage: Current GPTable app with real sign-in / PostgreSQL with retained file versions
Local model: Qwen3.5 9B / Ollama 0.33.3
Evidence retained: Saved source with the app-added Draft provenance footer, candidate, version history and terminal receipt metadata. The downloadable record identifies the checks and content hashes.

Where this verification stops

Fictional design exercise; the advice and references have not been independently validated.
This run used an automated test operator for the recorded review and explicit Apply.
The proposal covered the whole document. Its verified output changes only the pre-frozen heading.
Saved source includes the application-added draft provenance footer; it is not a verbatim raw model-stream archive.
Completed model receipts and saved output are retained. Raw HTTP/SSE streams were not archived.
The checks cover an orderly local restart, not crash recovery, broad tenant isolation or production readiness.
Browser download was not verified. The Saved version 3 artifact is exact retained PostgreSQL content, not a downloaded file.

Working notes

The work continues after the answer.

Making a useful response was only part of the problem. I wanted to keep working with the result: find a section, add something of my own and ask for a small change without losing the rest.

The files needed a home.

I kept the model’s saved source alongside the topic notes. Splitting a response into smaller files should make it easier to work with without losing the context it came from.

An automated test operator recorded this example using a fictional design brief and a local model. The app saved one source with its Draft provenance footer, then previewed 5 linked notes. Saving that preview was a separate choice, leaving 6 files in the workspace.

Follow the source into linked notes

A follow-up should leave room for my edit.

I kept saving an edit separate from applying a model’s proposal. The saved note remains the reference while the proposed change is available to inspect.

The recording adds a cost comparison and saves version 2, then asks for a new heading. The model receives the whole document; the check is deliberately small enough to compare exactly. Only the heading changes, the comparison and all other content stay intact, and the automated operator approves and applies the proposal once to create version 3.

See the review before Apply

Saved needed to mean I could come back.

I wanted to sign back in and pick up the same work. GPTable keeps the saved files and their earlier versions in PostgreSQL.

After a page reload and an orderly restart of the database, API and interface, the automated operator reopened version 3. Its content and saved history matched, including the manual comparison.

Inspect the saved result

View my résumé

How the workflow is built and testedImplementation notes, checks and limits for a closer technical review.

Authenticated workspace flow

Keep the response, the edit and the saved result distinct.

One saved model source becomes linked notes through an explicit commit. A manual edit is saved first; a later proposal waits for review and Apply. The same version returns after an orderly restart.

Create
Sign in and retain one saved model source
Organize
Preview and explicitly commit 5 linked notes
Review
Manual save, exact base, approval and one Apply
Return
PostgreSQL versions and reopening after an orderly restart

An isolated development run with real sign-in, PostgreSQL and Qwen3.5 9B. Fictional brief; automated operator. The earlier preview remains available separately. This is not production or crash-recovery qualification.

This pass: Real sign-in, PostgreSQL and a local Qwen3.5 9B model in an isolated development app. A fictional design brief and an automated operator.
Checks: 13 recorded checks cover the source, explicit topic-note commit, manual edit, reviewed proposal and saved versions reopened after an orderly restart.
Evidence: Saved source with the app-added Draft provenance footer, candidate content, version history and terminal receipt metadata. Raw HTTP/SSE replay was not performed.

Checks and limits

What I checked.

Recorded workflow

One saved model source and an explicit commit of 5 linked notes (6 files), a manual version-2 save, a whole-document proposal with a heading-only change, approval by an automated test operator and one Apply. The same version 3 returned after reload and an orderly database, API and interface restart.

Saved versions

All 13 recorded checks pass. The complete source, unselected files and manual addition remain intact; earlier versions stay available. Artifacts include the saved model source, the note with the manual edit, the saved database version 3 and the verification record.

Sign-in integration

Connecting Keycloak exposed a sign-in bug: credentials were accepted, but the app could fail while opening the session. The initial login and session activation parsed the provider’s metadata differently. I aligned those parsers while retaining identity and permission checks.

Limits

The design brief is fictional sample content, not validated research or a description of completed GPTable features. This pass checks one authenticated development workflow with an automated operator. General model quality, production security and tenant isolation, crash recovery and unsaved drafts after restart remain outside its scope.

Looking ahead

What I’d verify next.

Try broader requests and more demanding revisions, assessing usefulness separately from exact preservation.
Extend authentication, authorization and tenant-isolation checks beyond this one development workflow.
Test interrupted writes, crashes and unsaved drafts with the same exact-version checks.

The small behaviors matter.

A note that stays editable. A change I can inspect before applying it. A saved result I can reopen and take with me. Those are the details I’m working through in GPTable.

Get in touch More work