Proposal: Signed enterprise work orders for governed access to higher-capability Codex models

[ljefford2-cmyk]

I am an end-user and operator, not an AI vendor. OpenAI’s recent discussion of safeguards for next-frontier critical cyber capabilities⁠ raises a larger enterprise deployment question.

If a model becomes too capable to expose through an ordinary prompt interface, must the choice be between broad access and suppressing the model’s capability? Or could OpenAI provide a separately governed access path for qualified enterprise operating environments?

The underlying problem is that an ordinary employee should not be expected to write and optimize the operative prompt for consequential work. The employee should state an operational need through the organization’s normal interface. That request is neither the model instruction nor a grant of authority.

An organizational L1 control plane would recognize an approved work type and compile a signed, versioned work order from validated fields and approved templates. The work order could bind:

• Work-type identity and operating-definition version
• Requester identity, role, purpose, and authority source
• Authority scope, expiration, revocation status, and required approvals
• Minimum sufficient context and authorized context sources
• Permitted repositories, systems, tools, credentials, targets, and network destinations
• Time, resource, persistence, and external-effect limits
• Success criteria, stop conditions, escalation requirements, and evidence destinations
• Model, capability tier, adapter, and evaluation requirements

L1 would route and compile; it would not invent missing authority, redefine the objective, select unauthorized targets, or repair an incomplete request through inference. If the required purpose, authority, context, or effect boundary could not be established, the request would be rejected or escalated.

The model would receive the information needed for that specific operation—not an unnecessary portion of the enterprise’s policies, files, history, and reference library. A model-specific adapter could optimize how the governed work order is presented to Codex, but it could not change the controlling meaning or boundaries.

“Minimum sufficient context” is important. Simply providing less information is not automatically safer. An omitted exception, restriction, or current fact can invalidate an otherwise excellent result. Therefore, the context-selection rules, provenance, staleness checks, and required inclusions would themselves be part of the qualified control path and the system under test.

The prompt would not be treated as the enforcement boundary. Tool, credential, filesystem, network, target, and external-effect restrictions must be enforced outside the model. Codex should not be expected to infer its authority from text or certify that its own actions remained authorized.

Qualification would also need to be narrow, time-bound, and revocable. It would not certify that an organization is generally “safe.” It would qualify a defined combination of:

• Control-plane version and configuration
• Registered work type
• Model and capability tier
• Tool, credential, and network controls
• Evaluation and evidence path
• Permitted consequence boundary
• Validity period

Every operation would still require its own valid authority. Material changes, failed verification, control drift, or missing evidence could suspend the qualified access path.

An independent L2 evaluation function would examine two separate questions:

1. Did the operation conform to its declared work order?
2. Does the declared operating definition remain adequate for the environment in which it is being used?

Neither Codex nor the L1 controller should be authorized to certify its own correctness.

OpenAI could support reconstruction by returning a verifiably bound provider receipt covering the portion of the operation it observed: the work-order digest, model and policy versions, accepted capability profile, context manifest, tool requests, safeguard decisions, timestamps, and completion or rejection status. That receipt could be correlated with enterprise-side credential, network, approval, execution, and external-effect records.

This would not eliminate anyone’s legal or operational responsibility. It would make responsibility more observable, bounded, and testable. It could also improve model utilization by supplying consistent, task-specific context while reducing unnecessary data exposure and uncontrolled prompt variation.

I would appreciate OpenAI’s view on several architectural questions:

1. Could Codex support a first-class signed work-order interface alongside ordinary conversational prompting?
2. Could selected capability tiers reject direct or unsigned requests and accept invocation only from qualified control planes?
3. Could access be scoped by control-plane version, registered work type, enforcement profile, and operational consequence?
4. What provider receipt could support independent reconstruction without exposing protected model internals?
5. How should the interface fail when authority, context provenance, or effect limits are missing?
6. Could the canonical envelope remain provider-neutral while allowing a Codex-specific adapter to optimize model utilization?

I am not suggesting that this exact structure is the complete answer. I am asking whether the operating environment—not merely the model and its prompt—should become a first-class part of the access and assurance architecture.

Lawrence Jeffords
End-User and Operator
The_Controller_Is_Part_of_the_System_Under_Test_Public_Edition.docx

[ljefford2-cmyk]

One clarification may help explain the scale of the architectural question I am asking.

This is not simply a proposal for a frontier-model provider to accept a more structured prompt, nor is it a suggestion that an enterprise add another AI safety control.

The frontier-model developer sees one portion of a consequential operation. The organization sees another. The defensible operational claim exists only when evidence from both portions can be joined.

Consider a frontier model used to analyze a possible rail defect. The model provider may be able to establish which model and policy versions operated, what context manifest was received, which tools were requested, what safeguards were applied, and what analysis was returned.

The provider cannot establish whether the railroad requester possessed valid authority, whether a required safety restriction was omitted from the context, whether the reviewing engineer had a genuine opportunity to disagree, whether the track was restricted, whether the repair occurred, or whether the real-world effect was verified.

The railroad can establish those organizational facts. But it cannot independently establish undocumented claims about the model’s underlying capability, configuration, or provider-side safeguards.

Neither side, standing alone, can certify that the complete operation was authorized, properly controlled, and effective.

That is the purpose of the signed, versioned work order proposed here. It is not merely an improved prompt. It is the governed meeting point between two separately evaluated systems.

The organization would bind the work type, purpose, requester, authority, required context, permitted tools, consequence limits, human-review requirements, stop conditions, and evidence path. The frontier-model provider would accept the request only under an approved capability profile and return a verifiably bound receipt covering the portion of the operation it observed. Enterprise-side authority, credential, approval, execution, and external-effect records would be correlated under the same work-order identity.

Qualification would therefore be two-sided and bounded:

• The provider qualifies a particular model and capability profile for a defined role.
• The organization qualifies a particular control path for a defined work type and consequence boundary.
• Each individual operation still requires its own current and valid authority.

An independent evaluator must then be able to determine whether the operation followed the declared work order, whether the supporting assumptions remained true, whether the intended external effect occurred, and whether the operating definition itself remains adequate.

The larger industry problem is that each participant naturally draws the system boundary around the portion it owns. Model developers evaluate the model. Product vendors evaluate the product. Organizations audit their policies and processes. But the consequential result is produced by the complete operating path—and many failures occur in the seams between those separately evaluated portions.

I am not asking the frontier-model provider to govern the customer’s organization, and I am not asking the organization to certify the frontier model.

I am asking whether the interface and evidence architecture can allow both sides to make bounded, independently defensible claims about their respective portions—and allow the combined operation to be reconstructed without either side certifying its own correctness.

The model is not the enterprise. The enterprise is not the model provider. But for consequential work, both become parts of the same claim-relevant operating system.

[ljefford2-cmyk]

Response to “An Alien Mind”: Evaluating the Complete Operating Path

Jakub Pachocki’s September 6 essay, “An Alien Mind,”⁠ brings renewed urgency to the question I raised in this discussion. His concern about the diminishing dependability of reasoning monitoring makes it increasingly important to examine the complete operating system through which a model acts.

A model operates through tools, credentials, context-selection processes, controllers, evaluation mechanisms, and people. These functions shape both what happens and what evidence remains available to establish whether the operation was authorized, properly controlled, and effective.

Each participant naturally evaluates the portion it owns. The model developer evaluates the model. The product vendor evaluates the product. The organization evaluates its processes. But the consequential result is produced by the complete operating path, and failures can occur in the seams between those separately evaluated portions.

This is the purpose of the question and supporting paper already posted here, The Controller Is Part of the System Under Test. The functions governing, observing, and evaluating an operation must themselves remain subject to independent evaluation. Neither the model nor its controller should become the final authority over evidence establishing its own correctness.

The signed work-order proposal is one possible way to connect provider-side and organization-side authority and evidence. The underlying question is broader than that particular mechanism:

Will OpenAI address how the model, its operating environment, and the corresponding human and machine processes can be evaluated together—so that confidence rests on independently defensible evidence about the complete operation?

I would welcome a response from the team responsible for these questions, including where OpenAI believes this approach is useful or insufficient.

I am attaching Evaluating Advanced AI in Real Operations as a companion to The Controller Is Part of the System Under Test. It develops the provider–organization connection into a proposed evaluation process: defining the authorized work, preserving evidence from both sides, independently examining the connected operation, and returning findings to the function requiring correction.

A worked example shows how that evidence can distinguish an organizational omission from an unresolved discrepancy in the exchange. It also separates the quality of the model’s contribution, proper authorization and control, and verification of the intended result.

This is a discussion proposal. It reports no trial of the complete arrangement or provider adoption.

Lawrence Jeffords
End-User and Operator

The_Controller_Is_Part_of_the_System_Under_Test_Public_Edition_FINAL_August_2026.docx

Evaluating_Advanced_AI_in_Real_Operations_Proposal_Draft.docx