◈ UNITIQX FRONTIER-12 / ENGINEERING DOSSIER

UNITIQX ORIGINAL / KIMI · LONG CONTEXT AND RESEARCH

Long-Context Continuity Atlas

summaries and state tracking within bounded chat history. Built on the existing UNITIQX local provider-inspired UI; this is not a reproduction of the official Kimi by Moonshot product or model.

OPEN LIVE UNITIQX WORKSPACE ↗All comparison contracts ↗

Truth: The public text broker currently maps this workflow to qwen3:1.7b. 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

official chat, context and document work depending on app/account. Long-document assistance, context organization, reasoning and reference navigation.

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

Chunk-aware public archive viewer, provenance-linked memory index and user-authorized context reassembly.

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

Inputs, outputs and verification

Input: approved source collection. Output: structured context map and quotation/provenance references.

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.