ifc-0161

12.1 The OPTIC target card

Let \(\mathbb S_{\mathrm{skill}}\) be a typed workflow sketch. Its objects may represent skill types, inputs, outputs, tools, resources, preconditions, postconditions, and persistent records. Its arrows represent execution, sequencing, data transport, checking, and rollback. Distinguished diagrams declare which interfaces compose and which executions must agree.

An OPTIC target card is

\[ \mathsf{Target}_{\mathrm{OPTIC}} =\bigl(P_m,\mathbb S_{\mathrm{skill}},\mathcal C_{\mathrm{exec}}\bigr), \]

where \(P_m\) is the executable program compiled from a skill document \(m\), and \(\mathcal C_{\mathrm{exec}}\) is a family of execution, safety, regression, cost, and transport certificates. The target is not merely a high-scoring prompt. A skill program must be typed, executable, persistent, and independently testable.

Operationally, OPTIC receives a versioned skill document, its compiler and authorization environment, typed execution traces, and a registered edit and experiment budget. It returns a replayable executable program, a typed workflow-extension proposal, a request for evidence, or an abstention. The return record includes the source, compiler, traces, regressions, and certificate status; an improved piece of prose is not by itself an output of the system.

For a fixed sketch, optimization may select skills, adjust continuous coefficients, reorder registered steps, or specialize a program to a local state. OPTIC calls this assimilation. A proto-accommodation proposal changes the registered skill package. Its control suite \(\mathsf{Ctl}_{\mathrm{OPTIC}}\) includes current and no-change programs, coefficient and ordering search, repairs using known workflow constructs, alternate factorizations, authorization and schema checks, and capacity-matched prompt or program-search controls. Only after these controls fail under the registered representability test may OPTIC propose a package comparison

\[ \Upsilon _{\mathrm{OPTIC}}: \mathfrak R_{\mathrm{OPTIC}} \longrightarrow \mathfrak R_{\mathrm{OPTIC}}^+. \]

When the workflow presentation changes, its presentation component is

\[ J_{\mathrm{skill}}: \mathbb S_{\mathrm{skill}} \longrightarrow \mathbb S_{\mathrm{skill}}^{+}. \]

It may introduce a skill object, interface, factorization, control-flow construct, or composition law. The presentation component does not transport semantic states by itself. A candidate must also supply or induce a semantic transport

\[ \bar J_{\mathrm{skill}}: M_{\mathrm{skill}}\longrightarrow M_{\mathrm{skill}}^{+} \]

and a compatible lift for old skills and their evidence. Changes to the compiler, authorization environment, observer, or admission procedure occupy their own components of \(\Upsilon _{\mathrm{OPTIC}}\). A proposal that destroys previously admitted behavior is not a successful creative extension.

. OPTIC optimizes an executable program and may propose a larger theory of executable programs when a registered representability test rules out the relevant fixed-workflow repairs. The larger theory becomes an accommodation only after finite realization and independent admission. Improvement inside a fixed workflow is not the same claim as extending the workflow language.

Its artifact dossier separates the compiled program \(P_m\) from the package comparison \(\Upsilon _{\mathrm{OPTIC}}\), its presentation and semantic transport components \((J_{\mathrm{skill}},\bar J_{\mathrm{skill}})\), the regression and transport record for old skills, the locked execution certificates, and the persistent source, compiler, and trace hashes. The experiments in this chapter learn routing and composition over supplied subskills. They provide mechanism evidence for this dossier interface, but no experiment below independently admits a new skill type, interface, or grammar rule.