IdonAI Research Charter — Capability, Safety, and Longevity

Abstract

IdonAI was founded to build intelligence that expands human capability without replacing human judgment. This charter records the research commitments of the first year: prefer measurable engineering over narrative hype; treat safety as a first-class constraint equal in priority to capability; and design every experiment so that successful results can become production systems. The charter is not a model paper—it is the normative frame for every technical decision that follows.

1. Motivation and Context

In 2022 the industry was accelerating toward larger models with unclear deployment discipline. Scaling laws had revealed that capable models were achievable with more compute and data, but the leap from "capable" to "deployed responsibly" was left as an afterthought. Public discourse oscillated between apocalyptic risk framing and competitive dismissal of safety concerns. Neither posture was useful.

We believed the winning organizations would couple three things simultaneously: capability research grounded in actual serving constraints, safety work treated as a hard engineering requirement rather than a PR consideration, and deployment realism that asked whether a model could actually be used at scale before committing to train it.

This document is the normative frame for subsequent technical work. Later papers—Early Scaling Observations, Data Quality Filtering v1, Origin Technical Report, NextGen, and the Safety Research paper—instantiate these principles with concrete architectures, datasets, and evaluations.

2. Research Pillars

2.1 Capability with serving constraints

Every architecture proposal must answer three questions before it is taken seriously:

1. Can this be batched? A model that cannot run under continuous batching is a research toy, not a product component.
2. What is the KV-cache cost? KV memory dominates accelerator utilization at serving time. Attention variants, context lengths, and batch sizes must be evaluated in terms of memory footprint, not only FLOPs.
3. What is the p95 latency under interactive load? p50 numbers are insufficient for user-facing evaluation. The tail latency—p95 or p99—determines whether the product feels broken.

Papers that skip serving analysis are incomplete in our evaluation framework. This posture led directly to the adoption of grouped-query attention in Origin and the separate capacity planning requirements for MoE layers in NextGen.

2.2 Data quality over data volume

The scaling law literature of 2020–2022 primarily reported results on raw token counts. We observed early that data quality had multiplicative effects that were underreported: filtering pipelines routinely yielded equivalent or better downstream performance at lower token budgets. The implications:

• Deduplication is not optional. Near-duplicate text inflates token counts without adding information; it can also amplify memorization and bias.
• Provenance documentation must be maintained. Auditing a data mixture three months after training is impossible without it.
• Domain balance requires active management. Scraped web over-represents certain domains (e.g., news, legal, social) and under-represents others (e.g., technical documentation, scientific reasoning). Left unmanaged, this bias becomes model bias.

Data Quality Filtering v1 is the first concrete implementation of this principle. Scaling curves that ignore data quality are misleading as research artifacts and dangerous as engineering guidance.

2.3 Safety as regression testing

Safety metrics must ship beside capability metrics. This is the core operational commitment. A launch that improves MMLU by 2 points while increasing jailbreak success rate by 5 points is a failed launch by our standards—full stop.

This requires:

• Pre-specified safety test suites run on every candidate build before promotion
• Hard stop gates for disallowed-category full failures
• Dual dashboards tracking both jailbreak performance and over-refusal, because safety training that collapses into maximum refusal is also a failure

The Red-Team Pack v1 and subsequent safety evaluation cards instantiate this principle operationally. The Responsible AI & Safety Research paper is the comprehensive statement of methodology.

2.4 Honesty over sycophancy

Assistants must challenge false premises and express calibrated uncertainty. This is an alignment commitment, not a product nicety. A model that agrees with every user claim is not helpful—it is a more sophisticated version of a search autocomplete that returns results matching the query rather than results that are correct.

Preference optimization pipelines face a structural pressure toward sycophancy: human raters often prefer agreeable answers in short-horizon evaluations, even when agreement is epistemically incorrect. We counter this with:

• Explicit anti-sycophancy preference examples in training mixes
• Honesty axes in rater guidelines separate from helpfulness axes
• Preference diversity requirements to prevent collapse to a single approved style

Preference Optimization v1 describes the first implementation. The Calibration and Abstention note measures gaps that remain.

2.5 Engineering discipline in experiments

Research credibility depends on reproducibility. We adopt the following practices:

• Pre-register eval suites for major training runs when practical—before seeing results
• Keep held-out sets truly held out—no cherry-picking benchmark prompts for SFT mixes without disclosure
• Log seeds, harness versions, and prompt templates—the Eval Harness Standardization note is the procedural document
• Prefer ablations over single-number claims—every major architectural choice should have at least a matched-FLOP comparison

These are table-stakes for credible ML research. We state them explicitly because industry pressures routinely erode them.

3. Non-Goals (2022)

3.1 Parameter count press releases

Announcing model size as a proxy for capability is a failure mode. We track FLOPs, downstream benchmark performance, and serving cost. Parameter counts may be disclosed when they are informative; they are not a success metric.

3.2 Training on private user data without consent

Quark conversations are not used in training pipelines without explicit opt-in programs, legal review, and user-visible notification. This is a firm boundary, not a default preference.

3.3 AGI timelines as a research output

Predictions about artificial general intelligence timelines are not a research contribution IdonAI makes. We build and evaluate systems; claims about transformative capability thresholds belong in forecasting contexts, not our technical reports.

3.4 Open-sourcing weights before safety and product readiness

Model weight release is a product decision with safety implications. We do not release weights as a marketing move. If and when weights are released, safety evaluation and deployment guidance precede the release.

4. Path to Products

The research charter envisions convergence on two production systems:

1. A fast model for interactive work — realized as Origin: strong everyday coding and reasoning, interactive latency, cost-efficient at scale
2. A deep model for hard reasoning — realized as NextGen: maximum capability, multimodal, longer context, higher compute budget

Both models connect through a shared tokenizer (enabling distillation and routing transparency) and surface through Quark, the assistant layer that routes requests between them based on complexity, latency requirements, and cost.

This two-tier architecture was not inevitable—it was a charter-level decision made in 2022 before either model existed. The Quark routing prototype validates the economic logic: routing approaches NextGen quality at approximately 1.6× Origin average cost, compared to always-NextGen at much higher cost.

5. Charter Governance

This document is versioned. Substantive changes require research leadership review and a dated amendment. The core commitments—capability with serving constraints, data quality, safety as regression testing, honesty over sycophancy—are not expected to change. Operational details (specific eval suites, data sources, serving targets) are expected to evolve.

Research teams are expected to cite this charter when making architecture and deployment decisions that touch on these principles.

6. Conclusion

This charter is the north star for IdonAI Research. It is deliberately not a technical paper—it contains no novel algorithms, no benchmark tables, no architecture diagrams. Its function is to record, before results exist, what we are trying to build and what constraints govern acceptable paths. Every paper in the IdonAI Research corpus should be traceable to one or more of these principles.

The test of a research charter is not how it reads at founding, but whether it holds under pressure. We expect to be tested.

Archit Tyagi, April 2022. Updated references added as papers were published.