When I submitted SkillSpring Quantum to OpenAI Build Week, the main workflow was already working:
Imports -> Readable Archive -> Datasets -> Find Imports
The submitted 0.1.0-beta.1 Windows build could take the synthetic ChatGPT demo export, check it before processing, build a readable local archive and structured datasets, and make the imported history searchable again.
After submission, I moved from demo preparation into private-beta preparation. That meant using current exports from several AI platforms, trying less convenient paths, and paying attention to places where Quantum could technically continue but should instead stop and explain what was wrong.
Most of the changes since Build Week are small in isolation. Together, they make the product more honest and safer to test.
Better compatibility with real vendor exports
A current Microsoft Copilot activity export exposed a tiny format difference with a large practical effect: its CSV header began with a UTF-8 byte-order mark. Quantum's strict header check did not recognise the otherwise valid file.
The importer now handles that BOM explicitly, with regression coverage based on the real export shape. I then tested Copilot alongside ChatGPT, Claude, and Grok in one local workspace. Across that rehearsal, Find Imports showed four vendors, 1,000 conversations, and 27,017 messages together.
Refusing misleading Gemini imports
A Google Takeout package created a different kind of problem. It contained Gemini-related attachments but no usable Gemini conversation history. Auto Detect could previously fall through to generic document processing and make the package look more importable than it really was.
Quantum now recognises attachment-only Gemini Takeout folders and stops at Export Check. It explains that Gemini chat activity is missing and does not offer the Import action. This is an important product principle for Quantum: a clear refusal is better than producing output that misrepresents what was imported.
Protecting the original export folder
Testing also exposed a confusing source/output configuration. If the selected output workspace was the export folder itself—or a folder inside it—Quantum could write its own workspace files beside the raw source material.
The current candidate blocks that configuration in both the Imports screen and the underlying import runner. The user is asked to choose a separate sibling folder, the import actions stay hidden while the conflict exists, and Export Check no longer recommends importing while import is blocked.
Nothing is deleted or moved. The safeguard is about keeping original exports and generated Quantum workspaces clearly separated.
More honest ChatGPT package handling
Current ChatGPT exports can arrive as multiple conversation shards with additional companion files. Quantum now keeps the shard-first conversation path clear, identifies unsupported companions such as a separate codex.json history without treating them as failed conversations, and preserves local attachment references with readable labels where the package provides them.
The current sharded export remains the recommended ChatGPT path. Legacy chat.html support still exists as a compatibility route, but I am keeping its progress behaviour on the beta observation list rather than overstating it.
Testing the workflow, not just the parser
The post-submission work has included packaged walkthroughs as well as automated tests.
In the latest quick laptop test:
- Activity History captured every action I observed
- Readable Archive and Datasets became viewable after the first source file completed
- both screens loaded within a minute on that laptop
- Find Imports remained unavailable until the full import completed
Those timings are observations, not performance promises. I will repeat them with explicit machine and export-size evidence during the clean-machine rehearsal.
The repository's full regression gate currently covers vendor intake, import history and metadata, sharded imports, retrieval, archive and dataset readers, pipeline behaviour, the optional assistant boundary, and governance rules.
Keeping the Build Week submission frozen
The original Build Week artifact has not been replaced by this later work. The submitted source remains pinned to commit 465ebb5 with the annotated build-week-2026-submission tag and the v0.1.0-beta.1 release tag. The installer, checksum, synthetic demo, screenshots, and video remain recorded as the historical submission set.
The current repository identifies as 0.1.0-beta.6, but beta.6 is a private-beta candidate, not a new public release. Keeping that boundary explicit makes it possible to continue improving Quantum without rewriting what judges originally received.
What comes next
The next phase is evidence rather than feature expansion:
- complete the beta.6 clean-machine rehearsal
- gather smaller, current, privacy-safe test exports for each supported vendor
- verify the vendor export guides against their live interfaces
- rehearse the privacy-safe support and feedback process
- run the first external user session without step-by-step developer guidance
Build Week helped me get Quantum into a coherent, demonstrable shape. The work afterward has been about something less visible but just as important: making sure the app tells the truth about what it sees, protects the user's source material, and fails safely when an export is not what it appears to be.
That is the version of Quantum I want to put in front of beta testers.
Log in or sign up for Devpost to join the conversation.