
Got old stuff you don't know the price of, that you want to list but don't want to do the research for? Snap Seller does it for you: take one photo and a vision-language model looks at it directly, then writes a buyer-ready title, category, condition, description, and a suggested price -- all in a few seconds, no typing and no manual pricing. It doesn't fake certainty it doesn't have. Every price comes with a confidence rating (High/Medium/Low), and when confidence isn't High, the app tells you exactly what would raise it -- a clearer shot of a brand label, a size tag, a close-up of a specific detail. It's showing its work instead of guessing and hiding the guess. Built for three real use cases: people clearing out a pile of stuff who don't want to write ten listings by hand, flippers doing rapid price-triage at an estate sale (ten items, ten checks, before deciding what's worth buying), and anyone staring at something they genuinely can't identify -- inherited junk, a garage clean-out mystery item -- who just wants to point a camera and find out. It runs on AMD Instinct GPUs via Fireworks AI's managed inference. The honest case for AMD here isn't "always cheaper" -- published benchmarks are workload-dependent -- but this is single-photo, one-at-a-time inference, not a batch job, and that's exactly the regime where AMD Instinct's larger memory per chip has shown a real per-token cost edge over the equivalent Nvidia setup in published benchmarks (RunPod's 2024 Mixtral 8x7B test: $22.22 vs $28.11 per million tokens at batch size 1). For a flipper checking ten items instead of one, that adds up.
18 Oct 2026

In this hackathon most graded tests are hidden: for stage 3 you see about 9% of them, so passing the visible checks proves little. Our factory is built around that. It is four Claude Code seats in Band Desktop, each with a generic mandate. The lead turns the whole specification into a numbered requirements ledger: every "must", limit, error, ordering rule and example, plus a recorded ruling for every sentence that could be read two ways. The builder writes the code in small commits tied to ledger entries and never reads the shipped tests. The verifier builds its own evidence from the spec alone: a tiny reference model, one check per requirement, and thousands of random operations replayed against both the product and the model, with invariants (money conserved, no negative balances, history unchanged) checked after every step, plus the official checks in host and isolated mode. The customer uses the app in a real browser at desktop and phone widths and screenshots every state the spec names. Every verdict names an exact commit, and a check that errored counts as a failure. In the submitted run the factory built all four stages from one dispatch in 4 h 36 min with no human input: 328 of 328 requirements with passing evidence, and every stage folder claims its stage on the official checks in isolated mode. The review changed the work three times. For example, the verifier found that an amount of 1000.00000000000000001 was rounded by the JSON parser and accepted as a whole number; the lead rejected the build, the builder moved integrality checks onto the exact number as typed, and the verifier re-proved everything. FACTORY.md reports measured time per stage and token usage per seat. The verifier is the most expensive seat: the factory spends more proving the product than writing it. Every seat runs in a Docker Sandbox: full permissions inside, no access to the host.
6 Oct 2026

**The problem.** COBOL still runs much of the world's banking. In 2020, New Jersey's governor went on TV asking for COBOL volunteers, because the state's unemployment system still ran on it. Banks want to move off, and AI can now rewrite the code. But moving is dangerous: in 2018 a botched migration at the UK bank TSB locked customers out for weeks and ended in a £48.65m regulatory fine. The slow, error-prone step is **verification**. Teams run the old and new systems side by side for weeks and compare the results by hand, and a single wrong cent, repeated across millions of accounts, is a regulatory incident. **The workflow Parity improves:** verifying a legacy-code migration. It turns that step from weeks of manual comparison into one command that answers in seconds, with the exact field that differs when something is wrong. **How it works, on a real system.** We used AWS CardDemo, an open-source mainframe banking app with 31 programs and 20,650 lines of COBOL, and migrated its monthly interest job (CBACT04C). 1. **Map:** parse the JCL and COBOL into a system map: 31 programs, 11 business jobs, 26 data files, and which program reads or writes which file. 2. **Rules:** plain-English business rules, each tied to the exact COBOL lines, with every citation checked automatically. They flag a real bug in the original: the last account's interest is never posted to its balance. 3. **Rewrite:** IBM Bob, in a custom mode called COBOL Migrator, writes the Java. Its one rule is to change the language, never the behaviour, so known bugs are reproduced on purpose and marked FAITHFUL. 4. **Proof:** the original COBOL, compiled unmodified with GnuCOBOL, and Bob's Java run on the same 2,000 generated accounts, with edge cases on purpose (negative balances, one cent, missing rate groups, near-maximum amounts). Every output record is compared field by field. Result: 5,321 of 5,321 records identical, and identical again on three fresh data sets. On the live site, anyone can press "Run proof" on brand-new data and get the answer in about 2 seconds. 5. **Planted bugs:** a checker that always says yes is worthless, so Parity breaks Bob's program six realistic ways and checks each one is caught: 6 of 6. Using floating point for money changed only 2 of 3,321 transactions, by one cent, and it was caught. The planted bugs also exposed a gap in our own test data (cycle credits were always zero), which we fixed. 6. **Report:** a migration report written for a bank's risk team: translation decisions, results, behaviour kept on purpose, and limitations. **Why it scales.** The map is deterministic parsing, not AI. Bob only ever sees one program and its record layouts at a time. The proof compares the files a program reads and writes, so it works for any target language. **Limits (honestly).** One batch program today. Online (CICS) screens and DB2 come next. Generated data can miss rare branches, so coverage-guided generation is the next step.
27 Sep 2026

An audiobook has one big limitation: you can't ask it anything. When an idea doesn't make sense, you rewind and hope. For people who learn by ear (blind and low-vision listeners, people with dyslexia, anyone learning on the move), that's where understanding stops. Playhead lets you talk over the book. Say "wait, what did that mean?" and it answers about the passage you just heard, then carries on. That question contains no topic, so ordinary retrieval, which searches the whole book for words like the question, grabs passages from anywhere. In our side-by-side run, three of the four it returned were ahead of the listener. Playhead doesn't search: the listener's position is the query. It reads the last 90 seconds they heard (up to 5 minutes, their choice) and never searches ahead, so it can't spoil the book. Vague questions work ("Sorry, I'm lost" gets a recap). Named ones search everything already heard, nothing after ("Who's Lord Henry again?"). "Take me back to when he was thrown into the sea" jumps across a 54-hour, 117-file audiobook. Any audiobook works: paste a link, AssemblyAI transcribes it, and every passage is indexed by timestamp. Built on the AssemblyAI Voice Agent API: the browser streams audio to the agent, which calls Playhead's HTTP tools. Tool calls arrive anonymously, so each listener gets their own agent with their session pinned in the tool URLs, verified with simultaneous listeners. Who pays: listeners (free player, asking by subscription), audiobook and podcast apps, universities with lecture recordings, and libraries serving readers who can't use print. Indexing a ten-hour book costs about $2, once, then it's free for every future listener.
30 Sep 2026