Transparency

The most expensive thing a frontier laboratory can ship is a system whose behavior is opaque to the people deploying it. The asymmetry between what a developer knows about a model — its training data, its evaluation results, its known failure modes, the conditions under which it was red-teamed — and what an operator or end user knows is large by default and grows as capability scales. That asymmetry is not primarily a research-stage problem. Researchers can read their own logs. It is a deployment-stage problem, and it compounds: an operator who cannot tell where a system is brittle deploys it past its envelope; an end user who cannot tell where a system is confident treats hedged outputs as hedged and confident outputs as fact, exactly when the relationship should invert.

Public transparency artifacts — model cards, system cards, evaluation reports, and incident disclosures — are the engineering response to that asymmetry. They do not solve the underlying alignment problem; they make the alignment problem legible to the parties who have to absorb its consequences. The discipline traces to the Model Cards proposal of Mitchell et al. (2019) and the Datasheets-for-Datasets work of Gebru et al. (2018); it has since converged on a small set of conventions across the frontier laboratories — Anthropic's system cards under the Responsible Scaling Policy, OpenAI's preparedness reports under the Preparedness Framework, and DeepMind's evaluation reports under the Frontier Safety Framework.

The Apik framework documented here is in dialogue with that body of practice. We adopt the eight-field system-card schema described below; we tier disclosure against the capability thresholds of our Responsible Development Policy; we publish evaluation methodology before the first artifact lands, on the view that the methodology is itself a load-bearing claim. The Foundation Model Transparency Index ( Bommasani et al., 2023) provides the external benchmark against which we calibrate.

The schedule below maps each capability tier in our Responsible Development Policy to the artifacts we commit to publishing alongside a release at that tier. The tiers run from AS-1 (research-only systems with no external deployment) through AS-4 (frontier-capability systems for which the residual-risk surface is actively contested). Disclosure obligations grow with tier; the strongest obligation is at AS-3 and above, where independent assessment and a pre-release window become non-optional.

The schedule is conservative on purpose. Pre-release windows for AS-4 systems are longer than industry norms; the tradeoff (slower deployment, more external review) is the one we want. The schedule is part of the policy and changes only by amendment to the RDP, which itself changes under the procedure documented there.

An Apik system card is a fixed-shape document. The schema below is the union of the conventions that have stabilized across the frontier-laboratory cohort, read against Mitchell et al. (2019) and the practical structures published in Anthropic's and OpenAI's recent system cards. We commit to all eight fields for any AS-2-or-above release; the depth of each field scales with tier.

1. Decision summary. The release decision in two paragraphs: what is being deployed, on what surface, to whom, under what limits, and the residual risks the decision-makers explicitly accepted. Authored by the safety council; signed.
2. Capability evaluations. Benchmark suite, sample sizes, sampling temperature, harness version, and results. We report performance on the public benchmarks we used and on the internal benchmarks we built — with the second set described in enough detail for an external party to replicate the design even if not the exact items. METR's task suite is one of the public reference points; longitudinal capability measurement follows Kwa et al. (2025).
3. Alignment evaluations. Adherence-to-constitution measurements where applicable (Bai et al., 2022), adversarial probes for in-context deception (Meinke et al., 2024), refusal calibration on dual-use queries, and the gap between behavior under evaluation and behavior under deployment-like conditions where we can measure it.
4. Safeguard tests. Red-team uplift on a fixed protocol; jailbreak-resistance numbers; agentic-task containment tests; tool-use envelope adherence. Reported as point estimates with bootstrapped confidence intervals where the sample size makes that meaningful, and as descriptive results with caveats where it does not.
5. Residual risks. The risks the safeguards do not bound. Stated explicitly, not minimized. This is the field that distinguishes a serious system card from a marketing document; the discipline is to write it as if a future incident will be read against it.
6. Deployment limits. Eligible population, throughput ceiling, monitored vs unmonitored channels, geographic limits where regulatory regimes require, and the time horizon of the limit. Limits are part of the release; relaxing them is a decision, not a default.
7. Reversal criteria. The conditions under which we pull the release back. A small number of named, falsifiable triggers (for example, a specific safeguard-failure rate exceeding a stated threshold over a stated window) plus a discretionary clause for cases the named triggers do not cover.
8. Independent assessment. Who reviewed the release before it shipped, what they had access to, what they concluded, and what they could not conclude. Where confidentiality constraints prevent full publication, the constraint is named.

The numbers in a system card are only as informative as the methodology that produced them. Apik commits to publishing the methodology alongside the numbers; where we cannot publish a specific test (for safeguard reasons — publishing a jailbreak corpus is a capability uplift), we publish the design of the test in enough detail that an external evaluator can replicate the construction.

On capability, we run the public benchmarks expected of frontier releases and we run the agentic and long-horizon evaluations developed in dialogue with METR and the broader evaluation community. The longitudinal claim that matters most — the time-horizon at which models reach a fifty-percent task-success rate, doubling roughly every seven months in recent years (Kwa et al., 2025) — is the trajectory against which our internal capability claims are calibrated.

On alignment, the central technique is constitutional adherence under adversarial framing (Bai et al., 2022), augmented by Apollo-style probes for in-context scheming (Meinke et al., 2024) and by mechanistic-interpretability signals (Templeton et al., 2024) where we can extract them at the relevant scale. We treat the gap between evaluated and deployed behavior as a first-class measurement target, not a footnote.

On safeguards, red-team protocol design follows the practice that has stabilized across the frontier cohort — adversarial sampling, capability-elicit prompts on dual-use surfaces, and uplift measurement against a control workflow. Sample sizes are reported. Effect sizes are reported with intervals. A safeguard claim without a reported sample size and an interval is not a claim we will publish.

A release does not reach the system-card stage until it has cleared a fixed sequence of internal gates. Each gate has an owner, an artifact, and a defined promotion criterion; promotion past a gate without the artifact is a process violation and is itself an incident.

1. Capability eval. Owned by the research team. Artifact: capability-evaluation report on the standard suite plus the agentic-tasks suite. Promotion criterion: results within the envelope expected by the release proposal; surprises trigger a re-scope.
2. Alignment eval. Owned by the alignment lead. Artifact: alignment-evaluation report including adversarial-probe results. Promotion criterion: no novel deceptive-alignment signals; refusal calibration within the band documented in the RDP.
3. Red-team. Owned by the red-team lead, conducted by an independent rotation. Artifact: red-team summary including uplift estimates and any unmitigated jailbreak chains. Promotion criterion: no unmitigated chains on the gating surfaces.
4. Safety-council review. Owned by the safety council, which includes at minimum the CTO, the alignment lead, and one external reviewer. Artifact: signed decision summary. Promotion criterion: unanimous sign-off on the decision summary or an explicitly recorded dissent and rationale.
5. Staged release. Owned by the deployment lead. Artifact: live monitoring with rollback capability and the published deployment limits. Promotion to broader release happens only if the early-stage telemetry is within the envelope predicted by the evaluation phase.
6. Public system card. Published at the same moment broader release goes live. Updated on a quarterly cadence and on any material change.

Not every safety event is a public incident, and not every public incident is a material one. The taxonomy below names the three classes of event we treat as material — the ones that trigger a public disclosure under the Responsible Development Policy. Less serious events are logged internally and summarized in the quarterly transparency update; the line between the two is defined here so it can be argued with rather than guessed at.

1. Capability surprise. A post-release demonstration of a capability that was not present in the pre-release evaluation. The disclosure window is 30 days from internal triage. The disclosure includes: what the capability is, how we measured that it is real, why our evaluation missed it, and what we changed in the evaluation suite as a result.
2. Behavioral failure. A deployed system exhibited the behavior its safeguards were designed to block, in conditions the deployment limits were supposed to cover. The disclosure window is 30 days from internal triage. The disclosure includes: the failure mode, the user-impact estimate, the rollback or mitigation action taken, and the safeguard change.
3. Confidentiality breach. A deployed model returned material it should not have — training-time secrets, user data from another session, or content under confidentiality. The disclosure window is shorter (7 days) because the downstream remediation depends on user notification. Disclosure follows the responsible-disclosure pattern documented at RDP §incident-response.

Internal triage starts the clock; the clock does not pause for legal review. We coordinate with regulators where required and with affected parties where feasible, but the public-disclosure window is fixed.

For every frontier-capability release that crosses the AS-2 threshold or above, we ship a system card alongside the release on the schema described above. The first cards will publish as the corresponding releases reach the public-deployment phase of our Responsible Development Policy. This index will update at that point. Earlier-tier work (AS-1) does not publish system cards by default; methodology and evaluation suites are available on request to research@apiksystems.com.