69 Candidates, 38 Dossiers: Research Without Marketing Claims

Research can create a misleading sense of readiness when every interesting idea is described as a feature. Mowazi's agentic-system research program was designed to resist that temptation.

The program reviewed 69 candidates across 23 cycles and produced 38 bounded feature dossiers. That is not a claim that 38 capabilities are available in the product. It is a record of research and implementation planning that must still pass activation gates.

What the research program was designed to prevent

Mowazi's agentic-system research program starts from a constraint that is easy to lose in a feature backlog: a promising idea is not a capability merely because it has a paper, a benchmark, or a compelling vendor demo. The program turns external work into repository-aware, evidence-backed dossiers. It does not authorize activation.

The completed program ran 23 cycles of three materially new candidates. It recorded 69 candidates, approved 38 bounded dossiers, and stopped after six consecutive cycles with no new approvals. The stop condition matters. It makes “we kept looking” distinguishable from “we kept adding features.”

01 / evidence

Claim class

Separate production evidence, research results, and marketing assertions.

02 / hard gate

Boundary fit

Reject anything that exposes signing, bypasses policy, or creates new authority.

03 / dossier

Bounded next step

Specify a falsifiable evaluation before any activation discussion.

Hard gates come before a weighted score

The current research documentation rejects or requires a material reframe for any candidate that would expose signing, credentials, wallet actions, or execution tools to a model; bypass strict output validation or deterministic policy; create a conflicting source of truth; revive polling; lose idempotency through retries; form an unbounded autonomous loop; or treat a quote, simulation, or model output as authority.

Only candidates that survive those gates are scored. The rubric weighs architectural fit, evidence quality, safety and failure behavior, execution-boundary compatibility, projected benefit, evaluation feasibility, data availability, cost, and latency. A hard-gate failure rejects the candidate regardless of its numerical score.

type Candidate = {
  givesModelExecutionAuthority: boolean;
  preservesIdempotency: boolean;
  canRunShadowFirst: boolean;
  score: number;
};

function researchDecision(candidate: Candidate) {
  if (candidate.givesModelExecutionAuthority) return "reject";
  if (!candidate.preservesIdempotency) return "reject";
  if (!candidate.canRunShadowFirst) return "reject";
  if (candidate.score >= 75) return "bounded_dossier";
  if (candidate.score >= 60) return "evaluation_only";
  return "reject_or_defer";
}

The example is intentionally simpler than the real rubric. Its purpose is to show the order of operations: safety constraints decide whether scoring is meaningful, and scoring decides the narrowest next step—not public availability.

An approved dossier is not a product launch

The implementation-status record is explicit. A feature can be implemented only in observe mode or in an isolated local Test Center; it can remain activation-gated, local-only, or product-unavailable. Current records state that product enforcement, signer ownership, authoritative risk and reconciliation, certification, and live execution all remain gated.

research candidate
  -> evidence audit
  -> hard-gate check
  -> bounded dossier
  -> local validation / shadow or observe mode
  -> independent activation decision

That last transition cannot be inferred from code existing in the repository. It needs the required dependencies, validation, product readiness, and explicit approval. The distinction protects users from a familiar failure mode in technical communication: describing the strongest thing that has been prototyped rather than the strongest thing that is currently available.

Evidence types are not interchangeable

The program separates production evidence, research or backtest evidence, and platform or marketing claims. A paper can support a hypothesis. A backtest can justify a falsifiable experiment. A vendor's product page can help locate a capability. None of those establish that Mowazi's execution boundary can safely adopt the feature.

Every projected benefit must identify its metric, range or invariant, assumptions, confidence, and falsifying experiment. The program does not claim PnL, Sharpe, or drawdown improvements until Mowazi produces held-out, cost-adjusted replay and Shadow evidence. Runtime observability, calibration, safety, cost, and latency can still be legitimate benefits when performance claims are not justified.

type BenefitClaim = {
  metric: "latency" | "cost" | "calibration" | "safety";
  assumption: string;
  falsifier: string;
  activationStatus: "research" | "observe" | "gated";
};

Why the repository audit matters

The research program does not evaluate ideas in the abstract. It audits them against the current Mowazi architecture: Arbitrum is the active strategy chain; Particle and Magic remain owner signers; Convex holds product state; Timescale holds evidence; Redis is ephemeral; Temporal is durable; model output remains structured and bounded; and replay/shadow-first evaluation remains required.

This turns research into a maintenance discipline. A candidate that is impressive in isolation may be wrong for the system if it creates a second authority path or makes the control plane less legible. The right result is sometimes a rejection, a narrowed local experiment, or a dossier that remains dormant until a prerequisite is complete.

Mowazi's Closed Beta status is consistent with this approach. The research corpus is valuable because it makes the next boundaries explicit, not because it creates an excuse to represent gated work as public capability.

Hard gates before scoring

Candidates were rejected or reframed when they would expose signing or venue credentials to a model, bypass strict output validation, create a conflicting source of truth, introduce unbounded automation, or skip replay and shadow evaluation.

Only then were candidates assessed for architectural fit, safety, evidence quality, evaluation feasibility, data availability, cost, and latency. A paper or backtest can support a hypothesis; it cannot establish production performance on its own.

A useful separation

The current public status distinguishes implemented behavior from activation-gated behavior. Some early safety features are implemented in tightly bounded local or Test Center modes. Product enforcement, certified venue execution, and live execution require additional validation and explicit approval.

That separation matters. It keeps the work auditable for engineers and legible for users. It also creates permission to say "not yet" without treating restraint as a failure.