Skip to content

docs(planner): specify certified guided search - #434

Draft
quangvdao wants to merge 4 commits into
mainfrom
codex/certified-planner-spec
Draft

docs(planner): specify certified guided search#434
quangvdao wants to merge 4 commits into
mainfrom
codex/certified-planner-spec

Conversation

@quangvdao

@quangvdao quangvdao commented Aug 22, 2026

Copy link
Copy Markdown

Summary

This draft PR specifies one exact offline planner with a fast guided normal
path and a diagnostic oracle path.

  • Both executions use the same decision domain, materializer, feasibility
    rules, complete objective, frontier rules, descriptor order, and validator.
  • Guidance may order work and seed a validated completed incumbent.
  • Guidance may remove work only through a checked certificate.
  • A stale or unprovable exclusion retains the affected work in the same
    search. It does not start an exhaustive fallback planner.

The design is split into one lifecycle specification and two normative support
files:

The support files inherit the root specification's status and retirement.
They do not count as separate live specifications.

Diff metadata

  • Base: 6918a2018da6061d6399c74b542017027a7b74b8 (main)
  • Head: d7261d9167667ce71a38152a2f5d7d3867cdb621
  • Commits: 4
  • Files changed: 6
  • Diff: 2,541 insertions and 16 deletions
  • Status: proposed specification

Motivation

The current planner still mixes the semantic search domain with traversal
shortcuts. Three gaps are central.

  1. BoundedBalancedExtremesV1 omits recursive splits outside a fixed radius
    without a complete objective proof.
  2. Selective L2 is derived only at the split chosen by the best modeled Linf
    candidate.
  3. Setup first planning keeps one local slice choice before it prices every
    successor witness and suffix.

The current exact suffix frontier is useful after candidates have been built,
but it does not prove that these earlier omissions are safe. The target
architecture keeps one complete audited domain and requires a checked theorem
for every omission.

The existing grouped commitment API also exposes a compiled Akita shape as if
it were the protocol model. Protocols such as Aerie need semantic objects,
challenge separated commitment epochs, and a shared opening batch to be
planned together before they can be lowered to frozen profiles plus one final
group.

Planner architecture

Concern Target contract
Search path One engine for oracle and guided execution
Domain Explicit independent decisions with a stable domain identity
Guidance Ordering, incumbent seeding, and checked certificate replay
Local pruning Exact feasibility, progress, or consumer specific bounds
Global pruning Exact prefix plus an admissible relaxed suffix bound
Numeric equality Retain the region for canonical descriptor comparison
Unknown bound Retain the candidate or region
Runtime Consume a validated catalog artifact and never run planner search

The oracle is a diagnostic execution setting. It enumerates every audited
decision that has not been removed by mandatory equivalences or independently
audited certificates. The guided setting is the normal catalog generation
path. It uses empirical results for search order and validated incumbents, but
it has no additional semantic authority.

Certified pruning results

The proof support file states five concrete results.

  1. The canonical witness layout gives the exact mandatory current group body

    [
    F(p)=a\left\lceil\frac{N}{2^p}\right\rceil+b2^p
    ]

    inside every cell where security ranks, digit depths, relation geometry,
    source encoding, and compression choices are fixed.

  2. The body is discrete convex inside a cell. Every strict contraction or
    strict incumbent sublevel is therefore one integer interval.

  3. A completed incumbent gives a closed interval around the analytic balance
    point. When the incumbent is close to the lower minimum, only a few integer
    splits can still win. This replaces a fixed split radius with a proved
    range.

  4. A relaxed suffix search is admissible when it includes every real
    transition, charges no more than the real transition, and combines costs
    monotonically. Induction over the remaining fold depth proves that its
    value is no greater than the true suffix optimum.

  5. A transition may dominate another only when it admits every consumer, has
    the same sufficient child state or a proved child mapping, is no worse on
    every parent visible projection, and handles descriptor ties.

The support file also proves the interchangeable group symmetry quotient and
defines stable certificate names, conservative unknown behavior, diagnostics,
and oracle comparison tests.

Selective L2 routes and setup first slices remain explicit later
implementation work. The target keeps every route and slice until a complete
transition dominance certificate removes it. A lower A rank, local setup
winner, or smaller next witness is not enough by itself.

Aerie Falcon version 1 workload

The workload support file is pinned to Aerie commit
e102ee371d08770b6fdfcebc33abe169e60e2756, merged PR #52, and the executable
manifest, transcript state machine, and PCS integration at that commit.

The adopted commitment sequence is:

  1. Commit and absorb S1, Epsilon, S2SourcesFour, BudgetTwo, and
    BudgetOne in manifest order.
  2. Derive the JL seed and the joint projection from S1 | V | Epsilon.
  3. Commit JlTwo and JlOne, which may be computed in parallel, and absorb
    them in that order.
  4. Commit and absorb JlFour as the Akita final group with the first seven
    profiles frozen.
  5. Open all eight physical commitments through one multi-group PCS proof, with
    one complete point owned by each group.

The JL names describe contents, not position. JlTwo packs D4,D5, JlOne
packs D6, and JlFour packs D0 through D3. JlFour is the closing group
because the JL4-final lowering produced the better measured recursive ladder.
It is not Aerie's semantic main witness and its bound 6 extraction family does
not own the opening policy.

For padded batches with N* >= 8, the logical commitment total is 2679 N*.
For smaller padded batches, the exact total is
2567 N* + 896 N* / min(8, N*). The fixture also records the physical
power-of-two shape, the 2^13 PCS floor, and the zero extension opening rule.

Aerie source reconciliation

Some inventory and transcript prose in the pinned Aerie protocol document
still prints the older JlFour, JlTwo, JlOne order. The manifest,
transcript state machine, composition, PCS implementation, and merged PR #52
all enforce JlTwo, JlOne, JlFour. This fixture follows that adopted
executable order and records the discrepancy instead of treating both orders
as supported.

Open Aerie PR #53 adds adversarial coverage for this order, the digit
alphabets, shard lengths, and minimum batch zero extension. Open PR #54 adds
timing spans without changing the protocol layout.

Performance contract

The proposed routine path is guided catalog generation. The initial
implementation targets are:

  • at most 60 seconds for each named guided row after compilation;
  • at most 10 minutes for the full stock catalog;
  • at most 4 GiB peak resident memory; and
  • at most 20 percent of the median oracle wall time for each high pressure
    fixture when the oracle completes within the audit window.

The absolute limits become blocking when the repository names a reference
runner. Until then, the same host relative limit is the blocking comparison.
Neither target may be met by shrinking the audited decision domain.

Change surface

Path Change
specs/certified-planner-architecture.md Defines the root architecture, performance contract, acceptance criteria, and 12 migration slices.
specs/certified-planner/pruning-proofs.md Holds the exact split, suffix, dominance, symmetry, L2, and setup slice proof contracts.
specs/certified-planner/aerie-workload.md Defines the pinned two-epoch, eight-group Aerie workload and JL4-final lowering.
specs/PRUNING.md Records support-file lifecycle and keeps the root live-spec count at 15.
book/src/foundations/spec-index.md Exposes the root specification and notes its owned support files.
scripts/check-spec-references.sh Includes both support files in the default dead symbol scan.

Safety and compatibility

This PR changes documentation and a documentation check file only. It does not
change planner code, generated schedules, public APIs, wire formats,
transcripts, setup artifacts, or runtime behavior.

The target contract requires canonical shared security and witness sizing
functions, checked arithmetic, conservative unknown behavior, strict numeric
pruning before descriptor comparison, and expansion through
akita-schedules. Runtime proving and verification cannot depend on
akita-planner.

Akita makes no backward compatibility guarantee. The implementation plan uses
one direct cutover and permits one policy-free lowering adapter while runtime
catalog shapes migrate.

Commit map

  • 66b5790c2 specifies certified guided search and phased commitment
    workloads.
  • 137f9cd08 links draft PR docs(planner): specify certified guided search #434 from the specification header.
  • 53538b91d adds the formal pruning proofs and the complete L2 and slice
    migration contracts.
  • d7261d916 splits the document and updates Aerie to the adopted JL4-final
    protocol.

Validation completed at d7261d916

  • git diff --check
  • scripts/generate-schedule-tables.sh, all 13 families with no generated
    drift
  • cargo fmt --all --check
  • taplo fmt --check
  • scripts/check-spec-references.sh
  • scripts/check-spec-references.sh --all
  • ./scripts/check-doc-guardrails.sh, including mdbook build
  • targeted typos over every changed file
  • python3 -m unittest discover -s scripts/tests -p "test_*.py" with 75 tests
  • dependency hygiene checks for akita-verifier, akita-prover,
    akita-config, akita-planner, and akita-setup
  • cargo machete --with-metadata
  • Rust line-cap self-tests and the repository Rust line-cap scan

The earlier 20,000 case randomized audit of split convexity and incumbent
interval containment remains applicable. A direct before and after comparison
confirmed that the split moved every proof statement and obligation intact.

Specification status and remaining work

This PR completes the proposed architecture and proof contract. It does not
implement the planner migration.

The 12 implementation slices cover the domain census, canonical decisions,
shared oracle, exact split cells, relaxed suffix bounds, selective L2 route
frontier, setup first slice frontier, guide artifacts, workload planning,
Aerie integration, runtime catalog cutover, and performance gates.

Reviewer map

Suggested review order:

  1. Read the root Summary, Intent, and Formal planning model for the
    semantic contract.
  2. Read Candidate domains and One search engine for totality.
  3. Review specs/certified-planner/pruning-proofs.md for the mathematical
    authority behind each exclusion.
  4. Review its Selective L2 route completeness and Setup first slice
    completeness
    sections for the deferred gaps.
  5. Review specs/certified-planner/aerie-workload.md for the exact challenge
    boundary, manifest order, logical and physical geometry, and Akita lowering.
  6. Return to the root Performance contract, Evaluation, and Execution
    plan
    for acceptance and migration.

Define one exact planner whose oracle and guided modes differ only in admissible search strategy.

Specify phased commitment workloads, proof-carrying pruning, performance budgets, diagnostics, and a staged migration plan.
@cursor

cursor Bot commented Aug 22, 2026

Copy link
Copy Markdown

PR Summary

Low Risk
Documentation-only: no planner code, catalogs, APIs, or runtime behavior change. Risk is limited to locking in a large target architecture that later implementation PRs must follow.

Overview
Adds a proposed certified planner architecture: one audited search domain, with oracle and guided runs sharing the same engine. Guidance may order work and seed an incumbent; it may drop candidates only via checked certificates. Unknown or stale bounds keep the work.

Replaces the main/precommit group model with epochs, source contracts, and an explicit closing group. Pins Aerie Falcon v1 as two epochs and one eight-group opening batch (JlTwo, JlOne, then JlFour as closer, not the semantic main route).

Normative pruning proofs cover the exact Z/E/T body, discrete convex split intervals, incumbent intervals, relaxed suffix bounds, transition dominance, and group symmetry. Current L2-from-Linf-split and local setup-first slice shortcuts are called out as unproved and deferred to later slices.

Registers the spec in the live set (15 records) and scans supporting files certified-planner/pruning-proofs.md and aerie-workload.md. No implementation in this PR.

Reviewed by Cursor Bugbot for commit d7261d9. Bugbot is set up for automated code reviews on this repo. Configure here.

@github-actions github-actions Bot added the spec PR contains a spec label Aug 22, 2026
@github-actions

github-actions Bot commented Aug 22, 2026

Copy link
Copy Markdown

Documentation blast radius (advisory)

These regions may need doc/spec/book updates based on changed paths.
This is not a merge gate. See docs/documentation.md.

Changed files in this PR: 6

ci-tooling

CI workflows and repo scripts

Code paths touched:

  • scripts/check-spec-references.sh

Consider updating:

  • docs/ci-test-timing.md
  • docs/documentation.md
  • specs/archive/2026-Q3/ci-test-timing.md

book-tooling

Book structure and guardrails

Code paths touched:

  • book/src/foundations/spec-index.md

Consider updating:

  • book/README.md
  • docs/documentation.md
  • specs/PRUNING.md

Per-PR checklist: spec Status / acceptance criteria; book owning page; AGENTS.md if contracts changed; archive spec after fold.

@github-actions github-actions Bot added the implementation PR contains implementation of a spec label Aug 22, 2026
@github-actions

github-actions Bot commented Aug 22, 2026

Copy link
Copy Markdown

PCS Profile Benchmark

13 of 13 profiles passed.

Times are medians of 3 measured runs after 1 discarded warmup run. Peak RSS is the largest measured value.

Each sample verifies the same proof first with the configured multi-threaded pool and then with one thread. Both timings reuse the same verifier setup.

Merge-base comparisons are available for 13 of 13 profiles. For matching profiles, the head and merge-base binaries ran interleaved on the same runner.

Benchmark shards

CI shard Profiles
1-fp32-base Fp32 dense nv26, direct setup check
Fp32 one-hot nv30, direct setup check
2-fp64-base Fp64 dense nv26, direct setup check
Fp64 one-hot nv30, direct setup check
3-fp128-base Fp128 dense nv28, direct setup check
Fp128 one-hot nv36, direct setup check
Fp128 one-hot nv36, recursive setup check
4-multi-group-direct Fp128 multi-group, direct setup check
5-multi-group-recursive Fp128 multi-group, recursive setup check
6-multi-group-recursive-w8r2 Fp128 multi-group W8R2, recursive setup check
7-distributed Fp128 one-hot nv32 W2R2, direct setup check
Fp128 one-hot nv32 W4R2, direct setup check
Fp128 one-hot nv32 W8R2, direct setup check

Public opening statements

Public opening statement Profiles
Over Fp32, one committed 26 variable multilinear polynomial with 2^26 coefficients is opened at one 26 coordinate point. Fp32 dense nv26, direct setup check
Over Fp32, one committed 30 variable multilinear polynomial with 2^30 coefficients is opened at one 30 coordinate point. Fp32 one-hot nv30, direct setup check
Over Fp64, one committed 26 variable multilinear polynomial with 2^26 coefficients is opened at one 26 coordinate point. Fp64 dense nv26, direct setup check
Over Fp64, one committed 30 variable multilinear polynomial with 2^30 coefficients is opened at one 30 coordinate point. Fp64 one-hot nv30, direct setup check
Over Fp128, one committed 28 variable multilinear polynomial with 2^28 coefficients is opened at one 28 coordinate point. Fp128 dense nv28, direct setup check
Over Fp128, one committed 36 variable multilinear polynomial with 2^36 coefficients is opened at one 36 coordinate point. Fp128 one-hot nv36, direct setup check
Fp128 one-hot nv36, recursive setup check
Over Fp128, 4 polynomials in 3 groups: one 16 variable polynomial at its own point, one 16 variable polynomial at its own point, and 2 32 variable polynomials at one shared point. Fp128 multi-group, direct setup check
Fp128 multi-group, recursive setup check
Fp128 multi-group W8R2, recursive setup check
Over Fp128, one committed 32 variable multilinear polynomial with 2^32 coefficients is opened at one 32 coordinate point. Fp128 one-hot nv32 W2R2, direct setup check
Fp128 one-hot nv32 W4R2, direct setup check
Fp128 one-hot nv32 W8R2, direct setup check

One-hot profiles generate deterministic witnesses with one 1 in every consecutive chunk of 256 coefficients. This witness shape is not a separate public claim.

Direct evaluates the public setup contribution during Stage 2. Recursive carries the same check through a Stage 3 setup-product sumcheck. Both modes execute the complete fold schedule and terminal verification.

The chunked profiles W2R2, W4R2, W8R2 divide the witness relation into the stated number of exact chunks for the first two fold levels.

Generated profiles may select different A, B, and D ring dimensions at different fold levels. The short profile names omit those dimensions.

Each sample generates deterministic witnesses and opening points, prepares setup, commits, proves, serializes the proof, checks its size, prepares verifier setup, and verifies the claimed openings. It does not test malformed proofs.

Phase time

Profile Setup Commit Prove Verify, multi-threaded Verify, single-threaded
Fp32 dense nv26, direct setup check 0.025 s
-0.0%
0.202 s
-2.8%
0.930 s
+0.3%
14.0 ms
+6.5%
20.9 ms
-0.2%
Fp32 one-hot nv30, direct setup check 0.025 s
+1.6%
0.221 s
+0.4%
1.218 s
+0.7%
15.1 ms
-0.9%
27.9 ms
-0.3%
Fp64 dense nv26, direct setup check 0.031 s
+1.5%
0.815 s
-1.9%
1.087 s
+0.7%
14.1 ms
-3.3%
26.7 ms
-0.7%
Fp64 one-hot nv30, direct setup check 0.041 s
-1.0%
0.083 s
-7.5%
0.791 s
+0.3%
14.1 ms
+0.9%
25.4 ms
-0.0%
Fp128 dense nv28, direct setup check 0.086 s
-0.3%
7.657 s
+1.2%
2.242 s
-0.4%
16.1 ms
-1.6%
54.1 ms
+0.2%
Fp128 one-hot nv36, direct setup check 0.216 s
-0.7%
6.336 s
+0.1%
3.499 s
-3.6%
23.4 ms
+1.0%
124.0 ms
+0.0%
Fp128 one-hot nv36, recursive setup check 0.768 s
-2.8%
6.321 s
+0.2%
3.946 s
+1.3%
17.4 ms
-0.7%
41.1 ms
+0.1%
Fp128 multi-group, direct setup check 0.130 s
+1.1%
2.069 s
+0.3%
1.674 s
+2.1%
16.6 ms
-4.5%
68.5 ms
+0.5%
Fp128 multi-group, recursive setup check 0.476 s
+4.5%
2.083 s
+2.0%
1.973 s
-0.3%
15.2 ms
+2.2%
30.1 ms
-0.5%
Fp128 multi-group W8R2, recursive setup check 0.514 s
+0.0%
2.151 s
-0.3%
4.449 s
-0.2%
25.4 ms
-1.3%
68.3 ms
+0.3%
Fp128 one-hot nv32 W2R2, direct setup check 0.068 s
-0.7%
0.735 s
+2.1%
1.619 s
-0.4%
17.3 ms
-2.0%
48.8 ms
-0.5%
Fp128 one-hot nv32 W4R2, direct setup check 0.076 s
-1.1%
0.723 s
-1.0%
2.204 s
+0.5%
19.0 ms
-6.3%
65.1 ms
+0.4%
Fp128 one-hot nv32 W8R2, direct setup check 0.068 s
+0.6%
0.717 s
+0.3%
3.119 s
+0.8%
22.8 ms
+3.6%
69.1 ms
-0.1%

Proof size and protocol shape

Profile Fold A/B/D schedule Total proof Fold payload Terminal response Fold levels Grinding retries
Fp32 dense nv26, direct setup check 2048/256/256 → 512/256/256 → 128/128/128 66,584 bytes
+0.0%
28,060 bytes
+0.0%
38,524 bytes
+0.0%
z 20,604 · e 2,560 · t 15,360
7
+0.0%
None
Fp32 one-hot nv30, direct setup check 2048/256/256 → 256/256/256 → 128/128/128 67,273 bytes
+0.0%
28,700 bytes
+0.0%
38,573 bytes
+0.0%
z 20,653 · e 2,560 · t 15,360
7
+0.0%
None
Fp64 dense nv26, direct setup check 1024/128/128 → 128/64/64 → 64/64/64 70,028 bytes
+0.0%
24,156 bytes
+0.0%
45,872 bytes
+0.0%
z 20,784 · e 3,584 · t 21,504
7
+0.0%
None
Fp64 one-hot nv30, direct setup check 512/256/128 → 128/64/64 → 64/64/64 69,778 bytes
+0.0%
23,900 bytes
+0.0%
45,878 bytes
+0.0%
z 20,790 · e 3,584 · t 21,504
7
+0.0%
None
Fp128 dense nv28, direct setup check 512/64/64 → 64/64/64 72,951 bytes
+0.0%
19,916 bytes
+0.0%
53,035 bytes
+0.0%
z 20,267 · e 8,192 · t 24,576
7
+0.0%
None
Fp128 one-hot nv36, direct setup check 512/64/64 → 256/64/64 → 64/64/64 73,996 bytes
+0.0%
20,892 bytes
+0.0%
53,104 bytes
+0.0%
z 20,336 · e 8,192 · t 24,576
7
+0.0%
None
Fp128 one-hot nv36, recursive setup check 512/64/64 → 256/64/64 → 64/64/64 76,414 bytes
+0.0%
23,308 bytes
+0.0%
53,106 bytes
+0.0%
z 20,338 · e 8,192 · t 24,576
7
+0.0%
None
Fp128 multi-group, direct setup check 512/64/64 → 64/64/64 73,013 bytes
+0.0%
19,916 bytes
+0.0%
53,097 bytes
+0.0%
z 20,329 · e 8,192 · t 24,576
7
+0.0%
None
Fp128 multi-group, recursive setup check 512/64/64 → 256/64/64 → 64/64/64 76,166 bytes
+0.0%
23,052 bytes
+0.0%
53,114 bytes
+0.0%
z 20,346 · e 8,192 · t 24,576
7
+0.0%
None
Fp128 multi-group W8R2, recursive setup check 256/64/64 → 64/64/64 79,497 bytes
+0.0%
26,432 bytes
+0.0%
53,065 bytes
+0.0%
z 20,297 · e 8,192 · t 24,576
8
+0.0%
None
Fp128 one-hot nv32 W2R2, direct setup check 512/64/64 → 64/64/64 73,443 bytes
+0.0%
20,332 bytes
+0.0%
53,111 bytes
+0.0%
z 20,343 · e 8,192 · t 24,576
7
+0.0%
None
Fp128 one-hot nv32 W4R2, direct setup check 512/64/64 → 256/64/64 → 64/64/64 73,966 bytes
+0.0%
20,892 bytes
+0.0%
53,074 bytes
+0.0%
z 20,306 · e 8,192 · t 24,576
7
+0.0%
None
Fp128 one-hot nv32 W8R2, direct setup check 512/64/64 → 64/64/64 74,689 bytes
+0.0%
21,596 bytes
+0.0%
53,093 bytes
+0.0%
z 20,325 · e 8,192 · t 24,576
7
+0.0%
None

Grinding retries are rejected attempts at each fold, listed in measured-run order. Zero means the first sampled nonce was accepted.

Memory and setup size

Profile Setup vector Prepared NTT cache Verifier NTT cache Peak RSS
Fp32 dense nv26, direct setup check 4.0 MiB
+0.0%
53.9 MiB
+0.0%
0.9 MiB
+0.0%
758.4 MiB
-0.9%
Fp32 one-hot nv30, direct setup check 8.0 MiB
+0.0%
63.0 MiB
+0.0%
0.9 MiB
+0.0%
468.6 MiB
-0.7%
Fp64 dense nv26, direct setup check 11.0 MiB
+0.0%
93.8 MiB
+0.0%
1.3 MiB
+0.0%
950.6 MiB
-0.2%
Fp64 one-hot nv30, direct setup check 16.0 MiB
+0.0%
147.5 MiB
+0.0%
1.3 MiB
+0.0%
401.9 MiB
+2.9%
Fp128 dense nv28, direct setup check 86.0 MiB
+0.0%
424.0 MiB
+0.0%
1.2 MiB
+0.0%
5219.9 MiB
+0.0%
Fp128 one-hot nv36, direct setup check 256.0 MiB
+0.0%
1150.0 MiB
+0.0%
1.2 MiB
+0.0%
3821.6 MiB
+0.2%
Fp128 one-hot nv36, recursive setup check 256.0 MiB
+0.0%
1174.5 MiB
+0.0%
1.2 MiB
+0.0%
3835.5 MiB
+0.3%
Fp128 multi-group, direct setup check 128.0 MiB
+0.0%
535.6 MiB
+0.0%
1.0 MiB
+0.0%
1545.6 MiB
+0.7%
Fp128 multi-group, recursive setup check 128.0 MiB
+0.0%
623.0 MiB
+0.0%
1.0 MiB
+0.0%
1676.1 MiB
+0.2%
Fp128 multi-group W8R2, recursive setup check 128.0 MiB
+0.0%
542.9 MiB
+0.0%
1.0 MiB
+0.0%
2594.6 MiB
+0.5%
Fp128 one-hot nv32 W2R2, direct setup check 64.0 MiB
+0.0%
267.5 MiB
+0.0%
1.0 MiB
+0.0%
932.6 MiB
-0.9%
Fp128 one-hot nv32 W4R2, direct setup check 64.0 MiB
+0.0%
301.8 MiB
+0.0%
1.0 MiB
+0.0%
1237.5 MiB
+1.2%
Fp128 one-hot nv32 W8R2, direct setup check 64.0 MiB
+0.0%
267.5 MiB
+0.0%
1.0 MiB
+0.0%
1554.4 MiB
-0.0%

Deltas are shown only for profiles with a matching merge-base case. Negative is smaller or faster.

The uploaded report.md benchmark artifact contains the detailed fold schedule, proof-size breakdown, terminal response segments, and Golomb diagnostics.

Derive the exact recursive witness body, the incumbent split interval, relaxed suffix admissibility, transition dominance, and group symmetry.

Define complete future contracts for selective L2 routes and setup-first slice choices.
@github-actions

Copy link
Copy Markdown

CI test timing

  • Report generated: 2026-08-22T02:49:09Z.
  • Source: 454bb71 on codex/certified-planner-spec.
  • Workflow run: 32545969276.
  • Main baseline: 6918a20.

Run summary

Wall s Main wall s Main Δ Ratio Tests Skipped Failed Status
433.0 357.0 +21.3% 1.21x 1694 0 0 ok

Wall time spans 2 parallel nextest slice shards.

Slowest tests

Rank Duration s Test
1 19.8 akita-planner::schedule_params::adaptive_search_tests::uniform_suffix_dp_matches_unpruned_exact_cutover_search
2 19.7 akita-pcs::akita_fp128_e2e::fp128_dense
3 13.9 akita-pcs::scheme::tests::onehot::selective_l2::selective_l2_proof_rejects_transcript_mutations
4 9.6 akita-pcs::scheme::tests::onehot::multi_group_root_allows_precommitted_arity_above_final_group
5 5.6 akita-planner::schedule_params::adaptive_search_tests::adaptive_nv36_minimizes_first_direct_setup_before_proof_bytes
6 5.5 akita-prover::kernels::linear::tests::chunking::q128_many_blocks_digits_chunk_instead_of_unsafe_block_parallel
7 4.8 akita-pcs::akita_small_field_e2e::fp32_dense
8 4.7 akita-pcs::akita_small_field_e2e::fp64_dense_pre
9 4.6 akita-pcs::akita_small_field_e2e::fp32_onehot_pre
10 4.5 akita-pcs::setup::adaptive_dense::large_setup_batch_passes
11 4.5 akita-pcs::akita_fp128_e2e::fp128_onehot_pre
12 4.5 akita-planner::schedule_params::adaptive_search_tests::production_suffix_selects_l2_with_the_typed_response_model
13 4.5 akita-pcs::akita_fp128_e2e::fp128_onehot_batched
14 4.4 akita-planner::schedule_params::adaptive_search_tests::mixed_domain_search_beats_or_ties_uniform_d64
15 4.2 akita-pcs::akita_small_field_e2e::selective_l2::fp32_nv20_shipped_terminal_route_roundtrip_and_rejections
16 4.1 akita-planner::planner::totality_tests::contractive_winner_remains_selected
17 4.0 akita-pcs::protocol_soundness::trace_internalization_rejects_tampered_root_fold_handle
18 3.9 akita-pcs::akita_small_field_e2e::selective_l2::fp32_ext4_multiblock_l2_pcs_roundtrip_and_stage2_rejections
19 3.9 akita-pcs::akita_fp128_e2e::fp128_dense_monomial_basis
20 3.7 akita-planner::schedule_params::adaptive_search_tests::adaptive_frontier_matches_unpruned_traversal_and_hand_priced_role_optima

Regressions vs main

No per-test regressions above the threshold.

New slow tests

No new tests ≥30s vs main baseline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

implementation PR contains implementation of a spec spec PR contains a spec

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant