Quark — A Conversational Assistant Built on Origin and NextGen

Abstract

We present Quark, IdonAI’s primary conversational assistant: a product system that routes user requests across the Origin and NextGen model families, maintains multi-turn coherence, and applies layered safety controls at inference time. Quark is designed for production use in coding, research assistance, writing, and general knowledge work—not as a research demo.

This report describes (1) the product architecture and model-routing policy, (2) the training and preference-optimization stack that shapes assistant behavior, (3) evaluation methodology spanning capability, reliability, and safety, (4) ablations on routing and memory, and (5) limitations and deployment practices. Quark is available today at quark.idonai.com. The same underlying models are documented for API integration; public API key issuance remains under development.

Contributions. We release a complete system description of a dual-model assistant with explicit routing, session memory, and safety layering; we report capability and safety metrics under a fixed evaluation protocol; and we document failure modes that matter for real users.

1. Introduction

Large language models are increasingly consumed through assistant products—interfaces that wrap one or more models with memory, tools, and policy. Product quality depends as much on routing, prompting, and safety as on raw model scores. Quark is IdonAI’s answer to that product layer: a single assistant that can favor Origin when latency and cost dominate, and NextGen when reasoning depth, long context, or multimodal understanding matter.

1.1 Design goals

1. One surface, two capability tiers. Users should not need to understand model IDs to get good results; Quark should choose well by default and allow override.
2. Honest behavior. Prefer calibrated uncertainty, correction of user errors, and admission of mistakes over fluent hallucination.
3. Production latency. Interactive chat must feel immediate for common tasks; deep reasoning may take longer but must remain usable.
4. Safety without opacity. Filters and refusals should be explainable at a high level; high-risk categories must fail closed.
5. API parity. Behavior users validate in Quark should map to the same model identifiers and request shapes in the IdonAI API when keys become available.

1.2 Scope of this report

We focus on Quark as a system: routing, dialogue management, evaluation, and deployment. Detailed model architecture for Origin and NextGen appears in the companion report NextGen Model Report (and Origin specifications on the models pages). Safety methodology is expanded in Safety Research.

2. Related work

Assistant systems such as ChatGPT, Claude, and Gemini demonstrate that preference optimization (RLHF / RLAIF), tool use, and multi-model routing improve user experience beyond a single base checkpoint. Mixture-of-experts and speculative decoding literature motivate separating a fast path from a deep path. Our contribution is an end-to-end description of IdonAI’s dual-path assistant—including evaluation tables, routing ablations, and explicit product constraints—rather than a new base pretraining recipe alone.

3. System overview

3.1 High-level architecture

Quark is organized as a pipeline:

1. Ingress — Authenticated web session; request validation; abuse rate limits.
2. Context assembly — System policy, user preferences, conversation history, and optional retrieved snippets.
3. Router — Selects origin, nextgen, or a short cascade (Origin draft → NextGen refine) based on features of the turn.
4. Inference — Model generation with structured decoding options when requested.
5. Safety layer — Input screening, output filtering, and policy-aligned refusal templates.
6. Egress — Streaming tokens to the client; logging for quality and security (with retention controls).

User turn
   │
   ▼
┌──────────────┐     ┌─────────────┐     ┌──────────────┐
│ Context      │────▶│ Router      │────▶│ Origin /     │
│ assembly     │     │ (policy)    │     │ NextGen      │
└──────────────┘     └─────────────┘     └──────┬───────┘
                                                │
                                                ▼
                                         ┌──────────────┐
                                         │ Safety +     │
                                         │ stream out   │
                                         └──────────────┘

3.2 Models behind Quark

Reported capability scores for these models (MMLU, GPQA, HumanEval, MATH, GSM8K) are published in the NextGen technical report and on model pages. Quark inherits those capabilities; this report measures assistant-level outcomes under routing.

3.3 Session memory

Quark maintains session-scoped conversational memory: prior turns in the active thread are included under a token budget with recency bias and optional summarization of older turns. We do not claim permanent cross-session personal memory in the current product; long-term memory is a planned extension with explicit user controls.

4. Training and preference optimization

Quark’s behavior is shaped in stages. Base capabilities come from Origin and NextGen pretraining and mid-training; assistant-specific behavior is applied through supervised fine-tuning (SFT) and preference optimization.

4.1 Supervised fine-tuning (SFT)

We construct SFT mixtures covering:

• Multi-turn dialogue with clarification questions
• Coding assistance (explain, debug, patch-style edits)
• Research and writing (outline, critique, citation-aware drafting)
• Refusal and redirection for disallowed categories
• “Challenge incorrect premises” and “admit uncertainty” patterns

Demonstrations are written and reviewed by domain specialists; automated filters remove personally identifiable information and toxic content from training text.

4.2 Preference optimization

We apply preference learning (RLHF-style) using pairwise comparisons from raters on:

• Helpfulness and task completion
• Truthfulness / grounding
• Clarity and structure
• Safety and appropriate refusal
• Tone (direct, non-sycophantic)

Optimization uses a reward model trained on these preferences, followed by policy updates with KL regularization against the SFT reference to limit drift. We periodically refresh the preference set to reduce reward hacking on stylistic artifacts.

4.3 Online feedback loop

Production thumbs and free-text feedback are sampled for offline review. High-severity failures (safety, severe hallucination) are triaged within a fixed SLA; lower-severity quality issues enter the next preference batch. This loop is human-gated—we do not continuously train on raw production traffic without review.

5. Routing policy

5.1 Features

The router consumes lightweight features available before generation:

• Estimated task type (code, math, long-doc, creative, factual QA, multimodal)
• Approximate input length and whether attachments are present
• User model override (if set)
• Recent latency / load signals (degrade to Origin under extreme load)

5.2 Default policy

5.3 Cascade mode

For a subset of hard prompts, Quark may run a cascade: Origin produces a draft; a verifier heuristic (or NextGen) critiques and revises. Cascade increases latency and cost; it is reserved for tasks where quality gains justify the overhead.

6. Evaluation

We evaluate Quark as a product system, not only as a raw model. Unless noted, metrics use held-out prompts, temperature 0 for deterministic suites, and the production system prompt.

6.1 Capability (assistant-level)

Quark’s router recovers most of NextGen’s quality while keeping Origin on the majority of short turns (see §7).

6.2 Reliability and honesty

Honesty metrics remain an active research area; we publish them to set expectations rather than claim solved alignment.

6.3 Safety (assistant-level)

Detailed threat modeling appears in the safety report. Over-refusal is tracked as a first-class regression metric.

6.4 Latency and cost (production telemetry)

Time-to-first-token (TTFT) depends on region and load; figures are indicative from internal canaries.

7. Ablations

7.1 Routing vs fixed model

*Capability index: normalized composite of §6.1 suites (Origin-only = 100).

The router captures most of NextGen’s quality at a fraction of always-NextGen cost. Always-cascade is rarely worth it.

7.2 Memory summarization

Disabling summarization of long threads improves exact quote recall (+3.2 F1 on needle tests) but increases truncation failures on 40+ turn chats. Production keeps summarization with quote-preservation heuristics for code blocks.

7.3 Preference data scale

Returns diminish past ~100k high-quality pairs; data quality and coverage matter more than raw count.

8. Responsible deployment

• Content policy enforced in the safety layer with category-specific responses.
• Rate limits and anomaly detection on accounts and IPs.
• Logging minimized to what is needed for security and quality; enterprise retention configurable when contracts apply.
• Human review for severe safety incidents.
• Model cards for Origin and NextGen document intended use and out-of-scope uses.

Quark is not a substitute for professional advice in medicine, law, or finance; the assistant is instructed to recommend qualified human experts for high-stakes decisions.

9. Limitations

1. Hallucinations persist, especially for rare facts and niche citations.
2. Routing errors occasionally send hard problems to Origin or easy ones to NextGen.
3. Multimodal quality depends on NextGen path availability and input preprocessing.
4. No durable personal memory across sessions in the current product.
5. Evaluation suites are partly internal; we will expand public reproducible benchmarks over time.
6. API keys for programmatic access are under development; Quark web is the supported surface today.

10. Broader impacts

Assistants amplify productivity but can also amplify mistakes, bias, and misuse. We invest in refusal training, red-teaming, and monitoring, and we publish limitations so downstream users can design appropriate human oversight. Dual-use risks (cyber, bio, weapons) are handled under a deny-by-default policy for actionable assistance.

11. Conclusion

Quark is IdonAI’s production assistant: dual-model routing over Origin and NextGen, preference-optimized dialogue behavior, and layered safety. Router ablations show that most NextGen-level quality is achievable at near-Origin average cost for typical traffic. We will continue to improve honesty metrics, long-context memory, and API parity as the platform matures.

Try Quark: quark.idonai.com
Models: Origin · NextGen
Docs: Developer documentation

Acknowledgments

We thank IdonAI engineering, research, and safety contributors, and the external raters who provided preference data under confidentiality agreements.

References (selected)

1. Ouyang et al., “Training language models to follow instructions with human feedback,” 2022.
2. Bai et al., “Constitutional AI: Harmlessness from AI Feedback,” 2022.
3. Wei et al., “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models,” 2022.
4. Chowdhery et al., “PaLM: Scaling Language Modeling with Pathways,” 2022.
5. OpenAI, “GPT-4 Technical Report,” 2023.
6. Gemini Team, “Gemini: A Family of Highly Capable Multimodal Models,” 2023–2024.
7. IdonAI, “NextGen Model Report,” 2025.
8. IdonAI, “Safety Research,” 2025.