You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
P1/P2 evaluation and release-engineering issue: Jacobian has strong component tests and many valuable model canaries, but no single suite verifies the complete agent journey from tool exposure through final evidence use across every supported host surface.
Current regressions are discovered in separate layers and separate experiments:
server starts
-> tools are exposed under the right identity
-> agent discovers an applicable capability
-> exact contract is understandable
-> first execution call is valid
-> error recovery succeeds when needed
-> primary output is readable and correctly labelled
-> complete resource is recoverable
-> verifier receives the exact candidate
-> assurance/scope are interpreted correctly
-> final answer preserves the verified/computed values
The repository tests many individual arrows, but not the whole path under one frozen contract.
Examples of failures that passed neighboring layers:
No single component is sufficient to score these trajectories. “Tool initialized,” “tool was called,” “operation completed,” and “final answer was correct” are different gates.
Audit baseline: current main, including:
tests/boundary/mcp/*
tests/e2e/*
tests/unit/tooling/test_codex_visibility.py
benchmarks/tooling/codex_visibility.py
benchmarks/tooling/codex_tool_context.py
src/jacobian/eval/telemetry.py
npm/cli-e2e.test.mjs
Current fragmentation
In-process conformance does not test installed surfaces
Boundary tests often use:
asyncwithClient(create_server(...)) asclient:
This is excellent for the canonical server object, but it cannot detect packaging aliases, stale managed Skills, launcher configuration, HTTP proxy behavior, or host-specific model-visible result projection.
Doctor certifies a narrow path
Doctor currently checks launch configuration, an older-protocol handshake, and tool names. It does not execute the full browse → inspect → invoke → invalid-retry → resource-read journey or compare schemas/results across hosts.
Visibility suites focus on adoption
The committed Codex visibility suites record discovery/invocation/verification/abstention signals. They are not a complete mathematical-output handoff suite and cannot prove that labels, ordering, candidate binding, resource consumption, or final claims are correct.
PR canaries are difficult to compare
Recent PRs use high-quality frozen theorem cases, but each defines its own prompt, model, output schema, telemetry summary, and success interpretation. One run per arm is often intentionally presented as a reproduction rather than a performance claim. The evidence is useful but does not form a stable release gate across contract changes.
Root cause
The test architecture mirrors implementation ownership rather than the agent’s actual workflow.
transport tests own transport
schema tests own schema
catalog tests own descriptors
capability tests own mathematics
evaluation tasks own final answers
packaging tests own installed files
An agent experiences all of them as one protocol. Without a cross-layer journey contract, a change can be locally correct while breaking the next handoff.
Proposed architecture
Build two complementary suites sharing one versioned journey schema.
1. Deterministic cross-surface protocol journey
No language model is required. Run canonical fixtures through:
in-process MCP;
stdio;
Streamable HTTP for every supported protocol version;
packaged Codex binding;
configured Claude/Cursor/Gemini/OpenCode launchers where automation is possible;
installed connector/host binding.
Each surface runs the same sequence:
list tools
browse
search
exact SUMMARY
exact CONTRACT
invoke returned example
submit one precise invalid request
apply returned recovery
read primary resource
invoke linked verifier when installed
inspect final result/record binding
Canonicalize and compare:
tool canonical identity/local symbol;
descriptions, annotations, execution metadata;
input/output/contract digests;
result discriminators and channel shapes;
error code/path/rule/recovery;
primary-result projection and resource links;
scope, completeness, assurance, obligations;
protocol version and tenant/policy/provider identities.
This suite catches implementation and packaging drift without depending on model sampling.
2. Repeated model-in-the-loop journey evaluation
Use frozen, transformed, and held-out tasks that require materially different paths:
direct stable scalar operation;
intent-led discovery with vocabulary mismatch;
nested/discriminated payload construction;
producer → inline verifier handoff;
producer → artifact/resource verifier handoff;
labelled matrix or ordered symbolic output;
long-running/progress/cancellation case;
weak/no-match fallback;
negative control where Jacobian should be skipped.
Use repeated trials and report uncertainty. Hold model, reasoning effort, prompt bytes, task/verifier digests, policy, provider catalog, Skill condition, host, and protocol version fixed within comparisons.
Versioned journey event model
Record typed stages rather than reconstructing them from ad hoc transcript strings:
checker/assurance change → false-certification and exact-record lanes.
Avoid rerunning every expensive model suite on unrelated leaf mathematics. Use deterministic gates broadly and small preregistered model suites where behavioral evidence is necessary.
Evidence retention
Every report should bind:
source revision/tree;
package/Skill/connector artifacts;
protocol and SDK versions;
catalog/policy/provider/contract digests;
task/prompt/output-schema/verifier digests;
model/effort/host configuration;
normalized events and raw trace/archive digest;
exclusions, failures, and environment limitations.
Raw private traces may remain local, but checked-in summaries must identify exactly what was measured and avoid unsupported causal claims.
Acceptance criteria
One deterministic fixture runs the complete list → browse → search → inspect → invoke → invalid-recover → resource → verifier path across every supported surface.
Cross-surface comparisons use canonical tool and contract identities rather than local function-symbol equality alone.
A model suite covers direct use, discovery, schema construction, result consumption, verification, long execution, no-match recovery, and abstention.
Metrics separate server availability, adoption, valid execution, mathematical contribution, final correctness, and assurance calibration.
Intermediate certificate/label/order correctness is scored, not only headline scalars.
Repeated trials report uncertainty; one-off reproductions remain labelled as reproductions.
Tool invocation is never itself a reward signal.
Change-impact planning selects the smallest sufficient deterministic/model lanes.
Priority
P1/P2 evaluation and release-engineering issue: Jacobian has strong component tests and many valuable model canaries, but no single suite verifies the complete agent journey from tool exposure through final evidence use across every supported host surface.
Area
MCP conformance, packaged connectors/skills, model-in-the-loop evaluation, regression governance, cross-surface telemetry.
Summary
Current regressions are discovered in separate layers and separate experiments:
The repository tests many individual arrows, but not the whole path under one frozen contract.
Examples of failures that passed neighboring layers:
tools/list.No single component is sufficient to score these trajectories. “Tool initialized,” “tool was called,” “operation completed,” and “final answer was correct” are different gates.
Audit baseline: current
main, including:tests/boundary/mcp/*tests/e2e/*tests/unit/tooling/test_codex_visibility.pybenchmarks/tooling/codex_visibility.pybenchmarks/tooling/codex_tool_context.pysrc/jacobian/eval/telemetry.pynpm/cli-e2e.test.mjsCurrent fragmentation
In-process conformance does not test installed surfaces
Boundary tests often use:
This is excellent for the canonical server object, but it cannot detect packaging aliases, stale managed Skills, launcher configuration, HTTP proxy behavior, or host-specific model-visible result projection.
Doctor certifies a narrow path
Doctor currently checks launch configuration, an older-protocol handshake, and tool names. It does not execute the full browse → inspect → invoke → invalid-retry → resource-read journey or compare schemas/results across hosts.
Visibility suites focus on adoption
The committed Codex visibility suites record discovery/invocation/verification/abstention signals. They are not a complete mathematical-output handoff suite and cannot prove that labels, ordering, candidate binding, resource consumption, or final claims are correct.
PR canaries are difficult to compare
Recent PRs use high-quality frozen theorem cases, but each defines its own prompt, model, output schema, telemetry summary, and success interpretation. One run per arm is often intentionally presented as a reproduction rather than a performance claim. The evidence is useful but does not form a stable release gate across contract changes.
Root cause
The test architecture mirrors implementation ownership rather than the agent’s actual workflow.
An agent experiences all of them as one protocol. Without a cross-layer journey contract, a change can be locally correct while breaking the next handoff.
Proposed architecture
Build two complementary suites sharing one versioned journey schema.
1. Deterministic cross-surface protocol journey
No language model is required. Run canonical fixtures through:
Each surface runs the same sequence:
Canonicalize and compare:
This suite catches implementation and packaging drift without depending on model sampling.
2. Repeated model-in-the-loop journey evaluation
Use frozen, transformed, and held-out tasks that require materially different paths:
Use repeated trials and report uncertainty. Hold model, reasoning effort, prompt bytes, task/verifier digests, policy, provider catalog, Skill condition, host, and protocol version fixed within comparisons.
Versioned journey event model
Record typed stages rather than reconstructing them from ad hoc transcript strings:
Events are observational only. They do not prescribe strategy and cannot authorize verification.
Required metrics
Report separately:
Do not reward tool invocation itself.
Change-impact release gates
Map production changes to required journey lanes. Examples:
Avoid rerunning every expensive model suite on unrelated leaf mathematics. Use deterministic gates broadly and small preregistered model suites where behavioral evidence is necessary.
Evidence retention
Every report should bind:
Raw private traces may remain local, but checked-in summaries must identify exactly what was measured and avoid unsupported causal claims.
Acceptance criteria
Related work
Non-goals