Behind the Work

Yes. I’ve organized this into a concrete implementation plan, using Behind the Work as the working name. The product promise is: “Show the thinking behind your work.” It records your research, creative choices, instructions and judgment, while describing AI’s contribution openly. How it would work Each user has a private workspace containing projects for articles or fiction. Within a project, you can record: - Starting idea: your thesis, question, premise or characters. - Sources: links, relevant passages, who found them and why they mattered. - AI guidance: instructions, questions and selected exchanges. - Decisions: what you accepted, rejected or corrected, and your reasons. - Versions: how the argument or story developed. A Copy research brief button prepares selected material for your existing AI tool. You can bring relevant responses back into the project. When ready, you select what readers can see, preview the page and publish it. What you link from Substack An illustrative public address would be: https://www.sopheons.com/behind/giorgio/dollar-safe-haven Readers would need no account. The page would show the starting thesis, your contribution, AI’s role, sources and selected decisions. Your article could include: Behind this article: See the sources, research decisions, and how I used AI. Publishing creates a dated snapshot. Subsequent private work stays private until you publish another edition. You can link to the latest edition or a specific version. For fiction, you choose which details to disclose without revealing spoilers. The page distinguishes material recorded in the app, imported conversations and retrospective explanations. That makes the evidence useful without claiming to prove where an idea originated. Hosting and database plan I recommend a separate /behind/ directory on the existing Sopheons host: - Public files: /home/ku9udpsmximo/public_html/sopheons.com/behind/ - Private application and data: /home/ku9udpsmximo/sopheons-behind/ - New database: storage/behind.sqlite inside that private directory. The first version would have separate accounts and require no changes to the existing Sopheons or Notes databases. Public pages would remain available without your Mac being online. These paths follow the local deployment files I inspected. The current remote configuration still needs verification before deployment. Implementation order 1. Separate accounts, storage and private projects. 2. Sources, decisions, attribution and revision history. 3. Public previews, publication snapshots and shareable links. 4. AI briefs, conversation import and portable export. 5. A real article pilot, verification and deployment. I saved the detailed work in: - [Implementation plan](/Users/favring/Documents/ChatGPT/The AI Developer/behind-the-work/IMPLEMENTATION-PLAN.md) - [Build milestones and acceptance checks](/Users/favring/Documents/ChatGPT/The AI Developer/behind-the-work/DELIVERY-BACKLOG.md) - [Server upload and database plan](/Users/favring/Documents/ChatGPT/The AI Developer/behind-the-work/SERVER-DEPLOYMENT-PLAN.md) This turn produced the plan only. Nothing has been deployed. The deployment document specifies the proposed files, database creation, backups and rollback; the implemented release will include the exact upload manifest and tested commands.

I’ll build the five milestones locally in order and leave deployment untouched. I’ll first inspect the workspace and runtime, then implement the app, test the private and public flows, and have Astra review the finished change set. The workspace has only the planning documents so far. I’ll build this as a separate PHP/SQLite app so it fits the server layout in the plan. Local PHP is not installed, so I’ll validate the schema and browser code here and keep PHP execution checks clearly marked for the later server preflight. The core data model is in place: projects, versioned evidence entries, links between entries, publication snapshots, and separate invitation/passkey tables. Next I’m connecting those records to the screens and reader pages so the full capture-to-Substack flow works. The private workspace and public reader pages are connected locally, including source links, edition URLs, exports, and withdrawal. I’m checking the edges now: account isolation, how imported material is labeled after revision, and whether the preview matches the published page. The end-to-end flow is now implemented locally: invite and passkey routes, private projects and revisions, selected public editions, conversation import, AI briefs, and JSON/Markdown export. I’ve added a local test harness and an exact upload-manifest generator. I’m finishing the release notes and checking the code before Astra reviews it. The local Behind the Work app is implemented through steps 1–4: private passkey accounts, research and fiction records, revision history, selected public pages for Substack links, AI briefs, imports, and exports. Step 5 passed with synthetic data; a real article record still needs your sources and decisions. Nothing was deployed. Astra reviewed the implementation. I fixed the login/recovery race, preserved drafts after failed saves, and completed the private revision details. The PHP and SQLite tests, browser pilot, and separate backup-restore rehearsal pass. See the [review result] For a later server release: the [14-file manifest] lists every file and checksum. Upload the four public/ files to the proposed .../sopheons.com/behind/ directory; upload the five private/app/ files, three private/bin/ PHP files, configuration template, and initial SQL migration to the proposed private .../sopheons-behind/ directory. The [deployment plan] gives the exact paths and commands. Server preflight must confirm those paths and its PHP setup first. The only planned database change is one new private SQLite database created by the migration. Existing Sopheons and Notes databases need no changes. For now, upload no files and run no remote migration.

It is a good foundation for a small pilot, but I would not deploy the current version yet. I found two issues during this review: 1. Deployment blocker: PHP compatibility. Both live sites run PHP 8.3.32, while the local tests used 8.5. The app’s database transaction pattern fails on the server with “There is no active transaction.” This affects passkey sign-in, revisions, imports and publishing. I reproduced it entirely in server memory, without touching existing databases. 2. Public downloads need the indexing restriction. HTML pages tell search engines not to index them; JSON and Markdown downloads omit that instruction. What is good The main workflow is implemented and works locally: private research records, decisions and revisions, explicit public selection, contribution summaries, source links, and Substack footers. Fresh tests also confirmed that: - Another account cannot read or change your records. - Private notes and unselected entries stay out of public exports. - Withdrawal disables the reader page and both download formats. - All 14 release-file checksums match. My recommendation: fix those two issues, test against PHP 8.3, then deploy an invitation-only pilot. The existing sites do not need a PHP upgrade to accommodate this app. I saved the evidence and repair steps in the [readiness review](/Users//Documents/ChatGPT/The AI Developer/behind-the-work/READINESS-REVIEW.md). The [deployment instructions](/Users//Documents/ChatGPT/The AI Developer/behind-the-work/SERVER-DEPLOYMENT-PLAN.md) identify the files and the one new SQLite database required. Nothing was deployed or changed remotely. Application code remains unchanged by this review.

Deployed—reload your project page. - Simple entry form: title, date, full notes/AI conversation, and source URL. - Edit entries: click “Edit entry” beneath a saved entry. - Delete entries or projects: open the item’s delete section, then “Move to Trash.” - Restore: open “Trash” from the Projects page. Existing records are preserved. Deletion also withdraws the project’s public pages. I saved your preference for starting simple. Three PHP files and one database migration were deployed; no manual action is needed. [Deployment details](/Users//Documents/ChatGPT/The AI Developer/behind-the-work/SIMPLE-WORKSPACE-RELEASE.md).

Deployed. Reload your project, then: 1. Click Share project. 2. Paste your Substack article URL. 3. Select the entries to share. 4. Preview and publish. 5. Copy the Public project link into your Substack article. Readers won’t need an account. The public page links back to Substack. Later edits stay private until you publish again. Three PHP files updated; no database migration or manual upload needed. [Deployment details](/Users//Documents/ChatGPT/The AI Developer/behind-the-work/SHARING-RELEASE.md).

Deployed. Reload your entry, then: 1. Select the AI passage. 2. Click Mark selected text as AI. 3. Check the preview and save. AI passages appear in green monospace text on black, including on public pages after republishing. Human text keeps its normal appearance. Updated render.php, app.js and style.css; no database changes or manual uploads needed.

The thinking behind the words Why I’m building a simple place to keep the ideas, sources and conversations that shape an article When someone reads an article, they usually see the finished result. They don’t see the question that started it, the sources that complicated the argument, or the conversation that made the writer change their mind. They don’t see the paragraph that was abandoned because the evidence didn’t support it. That has always been true. But AI makes the distance between the finished text and the work behind it more difficult to interpret. An article can be beautifully written by AI and contain a substantial amount of human thought. It can also be written entirely by a person and contain very little original investigation. Looking at the language alone tells us surprisingly little about how the argument developed. This is the problem I want to explore with Behind the Work, a small project I’ve started building: a place where writers can keep the material that shaped their work and choose what to share with readers. What I want to make visible For this project, my main concern is the human contribution to the thinking. Who framed the question? Who developed the thesis? Who chose the sources and decided which ones deserved closer attention? Who noticed that an explanation was too convenient, or that two apparently contradictory findings might both be true? AI can help with all of these activities. Using it doesn’t automatically remove the human contribution. But the contribution becomes easier to understand when we can see what the person actually did. There is a difference between asking an AI to write an article about the dollar as a safe currency and bringing it a question you have already begun to investigate: This is the thesis I want to explore. These are the sources I’ve found. This part of the argument worries me. Look for evidence against it, find additional sources, and help me explain where the claim holds and where it breaks down. The second instruction gives us a clearer starting point. Even then, the most interesting evidence may come later, when the writer evaluates the response, rejects a suggestion, corrects a mistake or changes the thesis. I want a place to keep that development. An example: following an argument Imagine that I’m researching why the dollar sometimes strengthens during periods of uncertainty. I might begin with a straightforward hypothesis: investors see it as a safe place to hold their money. Then I collect a few sources and ask AI to help me investigate other explanations. The conversation might bring up demand for liquidity, interest-rate expectations or the need to repay dollar-denominated debt. Some of those possibilities might be relevant to the period I’m studying; others might be distractions. The useful record would include my original question, the sources we considered, and the exchanges that changed my understanding. It might also include a note explaining why I dropped one explanation or narrowed the article’s scope. By the time the article is finished, AI might have helped organise the argument and draft much of the wording. A reader could still see the work I did to direct the investigation and decide what I was prepared to say. That is much closer to what I mean by documenting a human contribution. The same idea applies to fiction With fiction, the material would look different, but the underlying question is similar. A writer might develop a character’s motivation, a difficult relationship or a rule governing an imagined world. They might use AI to explore possible scenes, test dialogue or suggest ways to connect events. The important decisions could be quite small. A character refuses an apparently sensible offer because accepting it would contradict something established earlier. A scene is removed because it explains too much. A proposed ending is rejected because it resolves the plot while leaving the emotional problem untouched. Those choices shape the story. They are worth keeping, even if an AI later helps turn them into prose. Of course, a fiction writer may want most of this material to remain private. Research notes can contain spoilers, discarded endings and ideas intended for another book. The ability to select what becomes public is therefore central to the project. Starting with something simple My first version tried to capture too much. There were different entry types, descriptions of human and AI contributions, source-review fields, decision records and ways to connect evidence. Each had a reasonable purpose. Together, they made the workspace feel like another task to complete. I realised that I was asking a writer to organise the history of their thinking while they were still trying to think. So I simplified it. For now, you create a project and add entries. An entry has a title, a date, a large space for notes, evidence or a complete AI conversation, and an optional source URL. You can paste the human input and the AI response together. You can write a short observation, save a passage you want to investigate or keep a longer exchange that helped you find the direction of the article. The aim is to make keeping the material easy enough that it becomes useful during the work itself. Keeping conversations readable One small feature I wanted was a clear visual distinction between my words and an AI’s response. You can select an AI passage and mark it so that it appears as green text on a black background, with a monospace font. It has the feel of an old computer terminal. There is a practical reason for this. A long pasted conversation can become difficult to follow when every paragraph looks the same. Separating the AI passages makes it easier to see the question, the response and the writer’s next intervention. The marking is supplied by the author. It is a way of presenting the conversation clearly, rather than a system that detects who wrote each sentence. I also like the visual reminder: this passage came from an interaction with a computer, and it should be read with that context in mind. From a private project to a public link A project starts as a private workspace. You can add entries, update them and return to earlier revisions. Entries and projects can be moved to Trash and restored. Keeping a record shouldn’t require getting everything right on the first attempt. When you want to share some of the work, you choose the entries readers can see and preview the resulting page before publishing it. The project can include a link to the Substack article. In return, the article can link to the public project page, giving interested readers somewhere to explore the sources, notes and conversations behind it. Readers don’t need an account to open that public page. Publication is a deliberate step. Adding a new private note or changing an existing entry doesn’t immediately change what readers see. You publish again when you are ready to share an updated version. What a record can establish There are limits to what this can tell a reader, and I want those limits to remain clear. A saved note can show what was recorded in the application and when. A conversation can show the instructions and responses an author chose to preserve. A sequence of revisions can help explain how an argument developed. None of this proves that an idea first originated in a particular person’s mind. Someone could bring material from elsewhere and describe it as their own. They could publish a carefully selected history that leaves out inconvenient parts of the process. A detailed record can still be misleading. The application therefore distinguishes the date someone supplies for their material from the time the system records it. And the public page is a selection made by the author, rather than a promise that every step is present. The value lies in giving readers more evidence to consider. The record still needs to be read critically. Who I hope will find it useful I’m starting with writers and researchers who already have material scattered across documents, browser tabs, notes and AI conversations. Some may want a public companion to an article. Others may mainly want to remember why they reached a conclusion six months ago. That second use matters to me. Even if nobody opens a public project page, the private record should help its author. It should make it easier to return to a source, recover a useful exchange or understand why an earlier draft took a different direction. For readers, the benefit is optional depth. Most people will simply read the article. Someone who wants to investigate a claim or understand how the author used AI can follow the link. The article should remain readable on its own. What comes next Behind the Work is at an early stage. The current version is deliberately small, and I want to learn from using it before adding more structure. I want to find out what is actually worth saving, how much context readers need and whether people find the public records useful. I also want to understand where keeping evidence helps a writer and where it becomes an interruption. More elaborate features can wait until there is a clear need for them. For now, the aim is straightforward: keep the material that helps explain how a piece of work came into being, and make it possible to share that material openly. AI is becoming part of how many of us research, write and develop ideas. I want a better way to show the judgment we exercise within that process. Behind the Work is my first attempt to make that thinking visible.