◈ UNITIQX FRONTIER-12 / ENGINEERING DOSSIER

UNITIQX ORIGINAL / GEMINI · CREATIVE EXPLORATION AND MULTIMODAL ASSISTANCE

Multimodal Experience Studio

concept exploration, UX critique and alternatives. Built on the existing UNITIQX local provider-inspired UI; this is not a reproduction of the official Gemini by Google product or model.

OPEN LIVE UNITIQX WORKSPACE ↗All comparison contracts ↗

Truth: The public text broker currently maps this workflow to gemma3:4b. Official provider backend connected: NO. Previous direct backend test: passed. Previous public proxy test: failed_or_interrupted. These are dated observations, not proof of complete provider parity.

Default reference vs UNITIQX implementation

01 · Official/default research

Google assistant app, content creation and multimodal features under official availability. Creative ideation, document/image support and multimodal assistant workflows.

Source/reference: Official documentation ↗ · Provider app ↗

Official default features are research targets and may be plan-dependent. They are not already present in UNITIQX.

02 · Working original UI

Original themed public composer, browser-only message history, bounded context replay, local prompt persona, JSON import/export, real model and fallback receipt when capacity permits, honest quota display, and separate Workpad notes.

Read-only approved public JSON or documentation can be inspected in the Workpad. No public server filesystem writes.

03 · Missing / unverified

  • Official provider account or hosted proprietary model
  • Native provider code/files/search/toolchain
  • Exact commercial UI replication
  • Public administrative controls
  • Full workflow parity and independent provider acceptance
  • Live model token streaming; currently complete-response JSON.
  • Independent measured human and accessibility parity with official UI.

04 · Original extension plan

Original graphics/video/design prototypes, multimodal input under explicit scope and accessible previews.

This is an implementation specification, not a claim the extension already works.

Inputs, outputs and verification

Input: design objective. Output: alternative concepts, source-labeled media and production test criteria.

Acceptance gates before claiming native provider parity

  1. Register authorized provider model and credentials through a separate owner-controlled route; verify actual tool receipt and permission scope.
  2. Prove the baseline works in independent desktop, mobile and keyboard tests.
  3. Implement original extension features as separately audited modules with source, licenses and test evidence.
  4. For any read/write tool, show exact target, diff/preview, isolation, authorization, bounded execution, audit and rollback.
  5. Record direct HTTPS E2E real inference under quota and never substitute mocked browser replies for vendor responses.
  6. Validate performance and accessibility against the current public product, not an imagined competitor.

What every visitor can inspect now

Recorded public Frontier test statuses · Private and unfinished project states as sanitized metadata · Machine-readable feature contract · Approved public service catalog.

Data-handling boundary: drafts, personal messages, credentials, private backups, real admin control, private APIs and arbitrary server files are not part of the anonymous public site.