◈ UNITIQX FRONTIER-12 / ENGINEERING DOSSIER

UNITIQX ORIGINAL / CHATGPT · GENERAL ASSISTANT AND TOOL WORKFLOWS

General Agent Workbench

general local chat, task analysis and browser-local saved sessions. Built on the existing UNITIQX local provider-inspired UI; this is not a reproduction of the official ChatGPT by OpenAI product or model.

OPEN LIVE UNITIQX WORKSPACE ↗All comparison contracts ↗

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

OpenAI ChatGPT platform supports projects, tools and other capabilities depending on plan/settings. General assistance, files, projects, external tools and structured tasks where permitted.

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

Consent-checked tool broker, project modules, rich editable outputs, status dashboards and isolated execution tests.

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

Inputs, outputs and verification

Input: human-approved goal. Output: task plan, optional reviewed tool actions and auditable work receipts.

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.