JEPA-Anything synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From task intent to a candidate contract
JEPA-Anything is a model-assisted task-design builder, not an enclosing agent runtime or a trained world-model service. Its shipped Skill asks a host model to convert a user's world-model intent into a configuration and inspectable code skeleton. The host supplies inference, project inspection, tool execution and next-step decisions. Python tools check declarations and render interfaces; the numerical library supplies reusable tensor operations. This account covers the shipped Skill, validator, generator, generated consumers, numerical support, synthetic recipe and checkpoint verifier at commit c6e6c88f3ef75a4ce7acd660d6fa5779d995512c, with cutoff 2026-10-15. The sole source, SRC-1, supplies implementation and doctrine/design evidence. No target execution, host trace or causal experiment supports this run. See the boundary and Source register and EPI-CLM-world-model-compiler.
For a representative history-to-future rollout task, the host is instructed to establish the system instance, available history and actions, target horizon and intended consumer. It should recover facts from the project before questioning the user. Unrecoverable facts that could change the task or introduce target leakage require clarification; JEPA-specific architecture choices instead remain the host's proposal responsibility. Rollout intent selects the repeated_transition interface. Provisional choices and a task summary belong in compiler assumptions, not in a claim of measured success. This is a source-defined workflow, not an observed conversion: RT-RTE-task-compilation, its workflow annotations, and MEM-OBJ-compiler-assumptions.
The host receives natural-language methodology and produces a symbolic configuration. The latter describes causal inputs, architecture, dimensions, losses, baselines, audits, use mode and planned comparisons. Planned claims must remain planned. Neither task declarations nor proposed defaults acquire empirical warrant merely by entering this mapping. Without a concrete task/design trace, the analysis cannot determine which proposed statements are faithful imports, entailed consequences or conjectures. See RT-OBJ-design-protocol, RT-OBJ-design-config, EPI-OBJ-claims and the epistemic route assessment.
Deterministic criticism, admission and delivery
The validator returns diagnostic codes, paths, messages, counts and a validity bit. The Skill asks the host to repair every error and repeat validation. The validator supplies fixed declaration predicates, not an oracle for the best architecture or an implemented model-repair scheduler. The host owns revision; mandatory per-field human approval is not part of the requested loop. This separation is supported by EPI-RTE-design-diagnostics and RT-RTE-task-compilation.
The generator CLI independently validates its input before rendering. A valid report admits a declared-complete design for skeleton generation; it does not accept scientific claims. Skipping standalone validation does not bypass this CLI check. However, the direct Python renderer accepts a supplied report without revalidating or requiring its validity. The guarantee is therefore CLI-specific, not universal. Both paths check destination availability; a non-empty destination is refused. Rendering uses a temporary sibling directory and cleans it on exceptions, but supplies neither versioned rollback after promotion nor a concurrent-writer or filesystem-isolation guarantee. See RT-RTE-scaffold-admission.
Rendering transfers selected configuration fields into literals in fixed templates and saves the normalized configuration, validation feedback, generated code/documentation and file list. This specializes declarations rather than adding scientific support. Later imports and invoked functions consume the executable constants. Copied assumptions remain inspectable, but their retention does not establish a later model reader of their meaning. The feedback and file list likewise do not inherit executable authority from sharing a directory with code. See EPI-RTE-template-specialization, RT-OBJ-scaffold-manifest, RT-BAP-generated-contract and MEM-OBJ-compiler-assumptions.
The requested next step is generated contract testing, followed by a user handoff explaining the task-to-design mapping, paths, validator result, use mode, adapter/encoder proposal, dimensions and unresolved assumptions. Tests use fabricated values and callbacks; the adapter remains a stub and the model an interface protocol. Generator completion is an intermediate result, not evidence that tests passed or that the host delivered the requested account. The source supplies no implemented delivery gate tied to test success or specific failed-test recovery procedure. These distinctions are retained in the workflow account and its annotations on RT-RTE-task-compilation.
What later execution can rely on
Generated contracts have real but local force. Mode constants select terminal readout, factor analysis or repeated transition. The dispatcher calls caller-supplied callbacks and, for rollout, returns selected horizon states. It checks required exogenous inputs step by step, but does not require the separate geometry, activity, capacity or claim-envelope helpers before callback execution. Callback effects are not sandboxed or rolled back; an earlier callback may already have run when a later step fails. Horizon entries are not copied snapshots if a callback mutates and returns the same object. See RT-RTE-state-consumption and its memory annotation.
The audit helpers distinguish several kinds of conformity. Claim-envelope checks compare result metadata with planned comparisons; activity, capacity and geometry helpers test caller-supplied numerical envelopes. Invoked exceptions can stop that caller, but passing does not authenticate measurement origin or establish statistical support. Generated tests can satisfy the envelope by copying planned metadata. In contrast, core numerical audits actually compute tensor rank, conditioning and reconstruction properties. Their conclusions are stronger about those inputs, but remain numerical, not evidence of predictive quality or semantic factors. See EPI-RTE-evidence-envelope, EPI-RTE-measurement-checks, EPI-RTE-numerical-audits and RT-CLM-validation-scope.
Repository evaluators do not bridge that evidential gap. The synthetic recipe computes activity from oracle state coordinates rather than learned encoders. The current checkpoint manifest describes an unpublished fixture with no payload or executed training. Its future published-file branch checks locally staged bytes and metadata, not model quality, downloading or loading. Make/CI consumes check statuses, but no successful run is supplied. See RT-RTE-structural-checks and MEM-OBJ-checkpoint-manifest.
Retained history and independent improvement properties
The strongest supported feedback contribution is a requested chain from validator execution feedback through host repair to a retained design and later-consumed generated contracts. The profile verification accepts this as claimed trace learning in the limited sense of feedback-fed durable artifact revision. It is not observed beneficial learning, revised Skill methodology or compiler self-improvement. The unresolved question is whether this chain operates reliably and improves future capacity, rather than merely changing an external product. No comparison establishing that benefit was performed. Its supporting routes are RT-RTE-task-compilation, EPI-RTE-design-diagnostics, RT-RTE-scaffold-admission and RT-BAP-generated-contract.
There is also genuine implemented numerical history. Welford count, mean and M2 summarize previous factor batches and enter a later differentiable activity penalty; reset forgets all history. EMA updates retain mixtures of encoder state for later target encoding. Learnable projection rows can change through external optimization and explicit scheduled QR retraction; configuring retraction alone does not schedule it. These afford adaptation but establish no executed optimizer, durable numerical reload or improved prediction. Sample origins and original encoder training remain unresolved. Host session memory, compaction and context budgeting remain external. See MEM-OBJ-online-variance-tracker, MEM-RTE-streaming-monitor, MEM-CMP-target-encoder and RT-RTE-core-projection.
The runtime's theory assessment keeps each property separate. For the host compilation route, condition 1, localized theory content, is afforded by inspectable method statements and equations. Condition 2, content-dependent consumption, is claimed, not observed. Condition 3, content-directed criticism and revision, is claimed through diagnostic repair, without an observed trace of blame attribution. Condition 4, retained criticism shaping another round, is claimed through requested revalidation. Criticism of the consumed methodology improving future capacity is unestablished. Reflection is not established: the represented subject is the external task, not an evidenced feedback-controlled self-representation of this compiler. Autonomous theory building is unestablished despite requested computational proposal and repair. At this builder boundary, exercised self-improvement is also unestablished: no supported chain shows feedback changing the compiler's own organization and subsequent operation causally depending on that change. These are independent findings, not a ladder or a single verdict. See RT-RTE-task-compilation.
For the scenario of producing an inspectable implementation contract, the supported contribution is a declared host workflow backed by executable declaration gates, fixed-template generation and local interface checks. For the different scenario of obtaining a trained or scientifically supported world model, those outputs are insufficient. A pinned host trace connecting request, diagnostics, revisions, generated files, tests and handoff would change the operation assessment. Provenance-linked measurements and held-out task evaluations would change the performance assessment; controlled interventions would be needed to isolate component effects. A retained-method update consumed in later compiler operation would be necessary to reassess self-improvement, independently of whether the external design improved. No additional source reads were made for this synthesis.
Limitations
| Limitation | Affected SRC IDs and record citations | Inspected boundary | Conclusion prevented | Evidence that would resolve it |
|---|---|---|---|---|
| Undeclared diagnostic-report part; unresolved reconciliation conflict carried by report verification | SRC-1; RT-OBJ-design-config, EPI-RTE-design-diagnostics, memory annotations, report-verification limits | Candidate configuration and derived diagnostics, including standalone reports persisted for rejected designs | Complete per-part object inventory or one authority/invalidation assessment for the combined object. The fresh CLI validity consumer remains supported. | Declaring-analyst record separating diagnostic feedback from candidate content, with its consumers, retention and invalidation account |
| Undeclared executable-contract and file-list-manifest parts; second unresolved reconciliation conflict carried by report verification | SRC-1; RT-OBJ-scaffold-manifest, RT-BAP-generated-contract, EPI-RTE-template-specialization, memory annotations, report-verification limits | Generated program, copied configuration/report, documentation and file list | Complete part-level retention, authority and invalidation comparisons; executable force cannot be assigned to the whole package or metadata | Separate declaring-analyst records for the material output parts and their actual consumers |
| Host workflow and delivery unobserved | SRC-1; RT-RTE-task-compilation, workflow account | Shipped host instructions and deterministic supports, not an executed host session | Actual reference consumption, repair, testing, successful handoff, autonomous completion or reliability | Pinned host execution trace linking the full task-to-delivery sequence and tool results |
| Structural and numerical checks do not establish empirical model results | SRC-1; RT-CLM-validation-scope, EPI-RTE-evidence-envelope, EPI-RTE-measurement-checks, EPI-RTE-numerical-audits, RT-RTE-structural-checks | Declaration predicates, supplied envelopes, tensor geometry and synthetic oracle-state fixture; no trained task run | Learned activity, semantic factors, model quality, statistically supported comparisons or causal benefit | Provenance-linked backend measurements, domain data/weights, acceptance criteria and task results; controlled comparisons for causal attribution |
| Numerical initialization, experience provenance and durable deployment unresolved | SRC-1; RT-CMP-orthogonal-factor-projection, MEM-CMP-target-encoder, MEM-RTE-streaming-monitor, MEM-OBJ-checkpoint-manifest | Local tensor mutations/history and metadata-only current checkpoint entry | Complete initial lineage/admission, numerical trace-source classification, deployed checkpoint reload or observed learning | Documented initial training/sample origins, optimizer callers and provenance-linked save/reload and later-consumption traces |
| Later semantic reuse and host context management unresolved | SRC-1; MEM-OBJ-compiler-assumptions, RT-BAP-skill-guidance, RT-OBJ-scaffold-manifest, RT-RTE-structural-checks | Copied reasons, optional reports and target-owned guidance; enclosing host internals outside implementation boundary | Automatic cross-session reuse, complete read-back inventory, push selection or context-budget/compaction guarantees | Explicit later consumer wiring and selector/context policies, supported by consumption traces |
| Inspection supports bounded routes, not exhaustive validator/recipe correctness or universal scientific-acceptance absence | SRC-1; EPI-RTE-design-diagnostics, RT-RTE-structural-checks, epistemic coverage | Sampled validator/recipe branches and opaque host/backend behavior | Complete schema/recipe correctness or a system-complete negative about every possible acceptance mechanism | Targeted inspection and supporting records for remaining material branches and concrete host/backend acceptance routes |
| Compiler learning, reflection, autonomy and self-improvement not demonstrated by product repair or numerical mutability | SRC-1; RT-RTE-task-compilation, RT-RTE-core-projection, profile verification | Task-design builder and numerical affordances at the frozen revision | Improved future capacity, exercised autonomous theory building, reflective method revision or exercised compiler self-improvement | Property-specific evidence: retained criticism/revision and subsequent consumption, feedback-controlled self-representation, role-by-role computational execution, and a causal chain through changed compiler organization; outcome evidence separately for benefit |