JQ Form Filler — "Bro, you still fill out forms?"

Status: Paths A + C v1 BUILT (2026-07-15, not yet deployed); Path B = idea. Product task 5e88c164 (Product Ideas, P2).

The pitch, in the voice it was born in: a guy on a couch, AR glasses on, hands behind his head — "Bro, you still fill out forms? Give it to JQ, he lives for that sh*t." JQ reads the form in front of you, consults what it already knows about you, and fills it in. You review; you submit.

The joke sells the glasses. The product is the Chrome extension, and the core of it is built today.

The one-line strategy: the extension owns every form that's a screen; the glasses own every form that isn't (paper, kiosk, someone else's display). They're not two ways to do the same job — they cover disjoint worlds. And the bridge between those worlds (Path C) is the most defensible piece of all: the glasses ingest a paper form into a hosted web form, where the extension's auto-fill already wins.

Why this matters

Everything JQ does today is reflective — reframe an article, nudge you in your own voice, hold your memories. Valuable, but none of it is the thing that makes a normal person install the extension and keep it. Form-filling is utility: it saves time on a chore everyone hates, it improves the more you use it, and it gives the glasses program a concrete answer to "why would an ordinary person wear these." It turns JQ from a companion into an assistant.

It also composes with the existing JQ presence thread — see MOBILE_JQ_PRESENCE.md and the glasses builds (docs/product/DREAMPRO_GLASSES_VOICE_PROGRAM.md, the JQ-on-Mentra memory).

Three paths — screens, off-screen, and the bridge between them

Path A — extension fills screen forms (BUILT v1, no hardware)

The Chrome extension (apps/chrome-extension/) already had ~80% of the plumbing: <all_urls> host permissions, a content script injected on every page (content.js), a side panel, and storage. Form-fill is a new capability on the same content-script surface, not a new extension.

The loop, as built 2026-07-15:

1. Scan the form. content.js walks the page for <input> / <select> / <textarea>, resolving each field's label (<label for>, wrapping label, aria-label/aria-labelledby, placeholder), name, type, autocomplete, and (for selects) its options into a compact descriptor. Only the shape leaves the page — never values.
2. Map against the notebook. The background worker builds availableKeys from the user's on-device notebook (chrome.storage.local, keys only, values never sent) and POSTs { fields, availableKeys } to POST /api/jq/form-fill/map (jq-form-fill.ts). The model returns fieldId → notebookKey; values are resolved locally.
3. Propose, never submit. content.js fills only empty fields, highlights them, and shows a review bar ("JQ never submits for you") with Undo. The user reviews and submits themselves. The whole trust story lives here.

The notebook lives entirely in the browser; the couch guy is aspirational framing — this is what goes in the store. Notebook v1 is low-sensitivity identity/contact only (notebook-schema.js); password / SSN / payment fields are hard-excluded on both sides.

Path B — glasses read off-screen forms (idea, phase 2)

First, the framing that matters: the glasses are not a camera you wear to read forms. They're a coach in your ear. The reason anyone puts them on is the in-ear voice — JQ (and the DreamPro Glasses Voice Program) speaking coaching, nudges, and a teammate's cheer, hands-free, mid-day. Form-reading is a bonus capability that rides on hardware already justified by the voice; it is never the reason to wear them. Lead every glasses story with the ear, not the lens — see docs/product/DREAMPRO_GLASSES_VOICE_PROGRAM.md.

With that established: paper forms, a PDF in a kiosk, a form on someone else's screen — the DOM can't see any of those. The Mentra Live camera + OCR can. Two sub-modes: answer-in-place (JQ speaks the value or hands it to your phone to type, hands-free) and — more powerfully — ingest (feed the scan into Path C). Plugs into the JQ-on-glasses build (Mentra @mentra/sdk AppServer; session.audio.playAudio an HTTPS MP3 = POST /api/jq/voice/say).

Note the honest limit: for a web form at a laptop, the glasses buy nothing — the extension already has the DOM losslessly, and a camera reading pixels is strictly worse. The glasses only earn their place where there is no DOM.

Privacy & security — the whole reason to lead with the ear. Audio-in-ear is inherently private: only the wearer hears it, and nothing about the world is recorded to deliver it. The camera is the opposite — a lens on your face is the exact thing people fear about smart glasses. So the camera is explicit-capture only: the wearer deliberately triggers a scan of a document in front of them; there is no ambient, always-on, or passive recording, ever. A captured form image is processed for its fields and not retained beyond that, and — like Path A — the form is filled from the on-device notebook, so the wearer's stored PII never rides along with the scan. This is the same bright-line consent discipline as the rest of the Living Voice / glasses work: the audio layer is private by construction; the camera is opt-in, per-capture, and non-ambient by rule.

Path C — Scan-to-Form: the bridge, and the real moat (v1 BUILT)

The sharpest version of the glasses story, and arguably the most defensible piece of the whole idea. Instead of filling a paper form in place (awkward), a camera (a phone today, glasses later) ingests it and reconstructs it as a structured, hosted, fillable web form. Once it's a web form, you're back in Path A's world.

The loop closes:

Scan a paper form → reconstruct as a hosted web form → fill it (JQ auto-fills from your notebook) → review → submit; the owner sees responses.

The elegant part — the two halves connect for free. A hosted JQ form is a normal web form, so the Path A extension auto-fills it with zero extra work: the "Fill this page's form" button works on /forms/:id exactly like on any other page. We didn't have to build a second autofill path; the platform is one pipeline because the output of C is the input of A.

This turns the glasses + extension from two disjoint tools into one pipeline: the camera is the on-ramp from analog to our form platform, and a one-time scan becomes a reusable digital asset (a link you fill many times, share, or hand to someone else to fill). Document recreation alone is a commodity (Microsoft Lens, Adobe Scan do scan→static-doc for free) — the moat is scan → fillable + auto-filled-from-you + hosted, which nothing on the market combines:

What's built (v1, 2026-07-15): a phone-photo upload (glasses camera is the same input later) → a vision model (gpt-4o) reconstructs the field schema → you review/edit → save → a hosted fillable form at /forms/:id → responses land back in a dashboard. See the Status section for files.

Deliberately scoped v1 / hard parts still open: reconstruction fidelity on tables / checkbox grids / multi-column legal forms is the real engineering — v1 targets simple single-column field forms, and same as Path A it refuses to reconstruct password / SSN / payment fields. Hosting forms that collect PII makes the response-retention + encrypted-channel story (below) load-bearing, not optional — that hardening is the enterprise phase.

The two things that actually gate this

1. PII + consent is the whole ballgame

Forms are exactly where SSNs, addresses, DOB, and payment details live. An LLM auto-filling those is a different risk tier than reframing an article. Non-negotiable v1 rules:

• Never fill type="password", or any field detected as payment (card number / CVV / bank) — hard-coded exclusion, not a heuristic the model can override.
• Per-field user confirmation before any value is committed; never auto-submit the form.
• Values stay on the device. Built v1 keeps the notebook in chrome.storage.local and sends only field shape + notebook keys for mapping; values are resolved and filled client-side, never transmitted. (Encryption-at-rest is a phase-2 hardening for the hosted / enterprise editions, where the notebook becomes a server-side record.)
• Reuse the bright-line consent discipline already established in the Living Voice / Legacy Channel work — this is the same muscle.

2. "Notebooks" needs to be a real data model

"Consult our AI LLM notebooks" is the magic — but it only works if the user has told JQ things. The wedge: JQ learns from every form you let it fill ("save these answers for next time?"), so it gets better the more you use it. First form is semi-manual; the tenth is one tap. This is the retention flywheel and the reason to build the notebook store as its own first-class model, not a scratch cache.

Enterprise angle — the encrypted closed system, sold to companies

The consumer couch-guy version and the enterprise version are the same engine with a different trust wrapper. The thing we sell up-market is not "autofill" — it's the encrypted closed system for moving the data: the user's answers live in an encrypted notebook, the field mapping happens inside a closed loop, and nothing is retained or exposed outside it. That's a feature consumers appreciate and enterprises require.

• Positioning: JQ Form Filler for individuals; a company edition where the notebook is an org's structured record and the closed encrypted channel is the compliance story (data never leaves the tenant, no third-party model retention, auditable per-field provenance).
• Insurance adjusters are a natural early buyer. Claims work is form-filling at industrial scale — intake, FNOL, disability/claims forms — exactly the chore this kills, and exactly the buyer who cares most about a provably-closed data path. Path C sharpens the wedge: an adjuster photographs a paper FNOL / intake form → instant hosted digital version the claimant fills on their phone, pre-populated from known policy data, moved over the encrypted channel. This is a warm channel through the Crosstie day job (disability/claims insurtech; the user now leads its Loss Control product and has line-of-sight to insurer/payer buyers). Same caveat as every Crosstie-adjacent play: clear IP / conflict-of-interest before pursuing it.
• The enterprise wrapper is a later phase — it rides on the same Path A loop. Prove the consumer flow + the encrypted notebook model first; the company edition is a packaging + compliance-hardening exercise on top, not a rebuild.

Status & what's next

Path A v1 built (2026-07-15) + Path C v1 built (2026-07-15). Not yet shipped/deployed. What landed:

Path A (extension autofill):

• Backend: jq-form-fill.ts (mapping brain) + route at POST /api/jq/form-fill/map, registered in index.ts. Guardrails covered by jq-form-fill.test.ts.
• Extension: on-device notebook + editor, form scanner + fill-applier with a review bar (never submits), background orchestration — notebook-schema.js, formfill.js, content.js, background.js.

Path C (Scan-to-Form):

• Migration 480_jq_forms.sql — jq_forms + jq_form_responses.
• Backend: jq-form-creator.ts (gpt-4o vision extract + normalizeFormSchema + CRUD) + route at /api/jq/forms (extract / create / list / public get / patch / submit / responses). Normalizer covered by jq-form-creator.test.ts.
• Frontend: creator flow at /dashboard/forms (upload → extract → review/edit → save → share link + responses) and the public hosted fill page at /forms/[id] — which the Path A extension autofills for free.

Next, in priority order:

1. Deploy + validate both — apply migration 480; load the unpacked extension; exercise Path A on real forms and Path C end-to-end (photo → hosted form → fill → response). Consider a store-copy update (the manifest description still says "Reframe the Narrative" only).
2. Notebook as a real data model + learn-from-fills — the retention flywheel. Today the notebook is a manual on-device form; the wedge is "save these answers for next time" so the tenth form is one tap.
3. Path C fidelity + polish — multi-column / table / checkbox-grid reconstruction, form editing after save, image storage (v1 sends the scan as a data URI and doesn't retain it), export of responses (CSV).
4. Path B glasses ingest — feed the glasses camera scan into the Path C /extract endpoint; rides the hosted-form surface that now exists.
5. Enterprise edition — the encrypted closed-channel packaging + response retention/compliance hardening on top.

Related

• MOBILE_JQ_PRESENCE.md — the native-mobile JQ companion; same presence thread.
• apps/chrome-extension/ — the existing "Reframe the Narrative" extension this builds on.
• DreamPro glasses voice program + JQ-on-Mentra builds — the hardware layer Path B rides on.