fix(ai): use adaptive orchestration for production proposals

CHANGELOG.md

@@ -4,6 +4,10 @@ All notable changes to LifeOS are documented in this file.
 
 ## Unreleased
 
+### Changed
+
+- Production contextual-orchestrator proposal requests now explicitly use adaptive `auto` mode and avoid provider-native structured-output passthrough, allowing the orchestration plane to meet the quality requirement and then minimize known cost while LifeOS retains strict fail-closed proposal validation.
+
 ### Added
 
 - Durable PostgreSQL plugin-installation authority with opaque UUIDv4 installation/workspace/installer identity, exact manifest digests, normalized explicit grants, bounded conflict replay, and atomic revocation evidence in the service-owned `plugin_integration` schema.

apps/ai-service/src/contextual-orchestrator-proposal-model.test.ts

@@ -129,7 +129,7 @@ describe('contextual orchestrator configuration', () => {
 });
 
 describe('ContextualOrchestratorProposalModel', () => {
-  it('sends a no-tools schema-constrained request and returns untrusted output', async () => {
+  it('sends a no-tools adaptive request and returns untrusted output', async () => {
     const draft = {
       summary: 'Prioritize launch readiness.',
       rationale: ['The checklist is the active critical path.'],
@@ -166,6 +166,8 @@ describe('ContextualOrchestratorProposalModel', () => {
 
     const body = JSON.parse(String(init?.body)) as Record<string, unknown>;
     expect(body.model).toBe('contextual-orchestrator');
+    expect(body.orchestration_mode).toBe('auto');
+    expect(body.include_orchestration_trace).toBe(false);
     expect(body.tools).toBeUndefined();
     expect(body.stream).toBe(false);
     expect(body.temperature).toBe(0);
@@ -179,24 +181,7 @@ describe('ContextualOrchestratorProposalModel', () => {
       content: JSON.stringify(request),
     });
 
-    const responseFormat = body.response_format as Record<string, unknown>;
-    expect(responseFormat.type).toBe('json_schema');
-    const jsonSchema = responseFormat.json_schema as Record<string, unknown>;
-    expect(jsonSchema.name).toBe('life_os_inert_proposal_draft');
-    expect(jsonSchema.strict).toBe(true);
-    const schema = jsonSchema.schema as Record<string, unknown>;
-    expect(schema.$schema).toBe('https://json-schema.org/draft/2020-12/schema');
-    expect(schema.additionalProperties).toBe(false);
-    expect(schema.required).toEqual(['summary', 'rationale', 'operations']);
-    const properties = schema.properties as Record<string, unknown>;
-    const operations = properties.operations as Record<string, unknown>;
-    const operationItem = operations.items as Record<string, unknown>;
-    expect(operationItem.oneOf).toHaveLength(3);
-    for (const variant of operationItem.oneOf as Array<
-      Record<string, unknown>
-    >) {
-      expect(variant.additionalProperties).toBe(false);
-    }
+    expect(body.response_format).toBeUndefined();
   });
 
   it('accepts one valid completion at the exact response-byte limit', async () => {

apps/ai-service/src/contextual-orchestrator-proposal-model.ts

@@ -212,6 +212,8 @@ export const CONTEXTUAL_ORCHESTRATOR_PROPOSAL_SCHEMA = deepFreeze({
 function requestBody(input: ProposalRequest): string {
   return JSON.stringify({
     model: 'contextual-orchestrator',
+    orchestration_mode: 'auto',
+    include_orchestration_trace: false,
     temperature: 0,
     stream: false,
     messages: [
@@ -221,14 +223,6 @@ function requestBody(input: ProposalRequest): string {
       },
       { role: 'user', content: JSON.stringify(input) },
     ],
-    response_format: {
-      type: 'json_schema',
-      json_schema: {
-        name: 'life_os_inert_proposal_draft',
-        strict: true,
-        schema: CONTEXTUAL_ORCHESTRATOR_PROPOSAL_SCHEMA,
-      },
-    },
   });
 }
 

docs/adr/0003-adaptive-contextual-orchestrator-proposal-default.md

@@ -0,0 +1,28 @@
+# ADR-0003: Adaptive contextual-orchestrator mode is the proposal default
+
+- Status: Accepted
+- Date: 2026-08-16
+
+## Context
+
+LifeOS sent a provider-native JSON Schema response format to contextual-orchestrator. The current gateway deliberately proxies such requests to one worker because multi-agent tool and structured-output envelopes cannot be merged losslessly. Although the request omitted a mode and therefore appeared adaptive, the structured-output trigger made the effective path a fixed single-model passthrough.
+
+LifeOS already treats model output as untrusted. The technology-independent ProposalService validates exact keys, bounded text and arrays, operation kinds, and UUIDv4 targets before an inert proposal can be persisted or returned.
+
+## Decision
+
+Production proposal requests include `orchestration_mode: "auto"` and `include_orchestration_trace: false`, and they do not send provider-native `response_format`.
+
+The fixed system instruction still demands one JSON object. Contextual-orchestrator owns provider/model selection, workflow depth, verification, fallback, and known-price optimization. Quality sufficiency is the first constraint; cost is minimized among execution paths that satisfy it. LifeOS remains the final authority for strict parsing and domain validation and fails closed on malformed output.
+
+The live-conformance harness retains explicit route and conduct profiles because it is an ablation and measurement surface, not the production default.
+
+## Consequences
+
+Simple requests may still use one worker when adaptive policy finds that sufficient. Harder requests may use deeper orchestration. LifeOS no longer gains provider-side schema enforcement, but it does not rely on that enforcement for trust; the existing strict validator remains mandatory and fully tested.
+
+## References
+
+Omidvar, H., & Akhlaghi, V. (2026). *A communication-theoretic framework for LLM agents: Cost-aware adaptive reliability* [Preprint]. arXiv. https://doi.org/10.48550/arXiv.2605.09121
+
+Tang, Y., Cetin, E., Xu, J., Sun, Q., Nielsen, S., Richard, V., Goda, H., Tymchenko, I., Nguyen, N., Lee, H., Ashiga, M., Kotyan, S., Kuroki, S., & Clanuwat, T. (2026). *Sakana Fugu technical report* [Technical report]. arXiv. https://doi.org/10.48550/arXiv.2606.21228

docs/operations/contextual-orchestrator-proposal-transport.md

@@ -60,15 +60,16 @@ LifeOS sends:
 - temperature `0`
 - streaming disabled
 - no tools or function definitions
-- a strict JSON Schema response format
+- explicit `orchestration_mode: auto` with trace disclosure disabled
+- no provider-native `response_format`, because that gateway passthrough would pin the request to one worker instead of adaptive orchestration
 
 The model may propose only:
 
 - `create_task`
 - `prioritize_item`
 - `schedule_item`
 
-Every output still passes the independent `ProposalService` validator. Unknown properties, empty or oversized text, unsupported operation kinds, malformed UUIDv4 targets, excessive arrays, invalid timestamps, and invalid identifiers fail closed. A successful proposal always carries `requiresConfirmation: true` and is persisted before return.
+The fixed system instruction requires one JSON object, and every output still passes the independent `ProposalService` validator. Removing provider-native structured-output passthrough does not relax the LifeOS trust boundary; malformed or unsupported output fails closed after adaptive orchestration. Unknown properties, empty or oversized text, unsupported operation kinds, malformed UUIDv4 targets, excessive arrays, invalid timestamps, and invalid identifiers fail closed. A successful proposal always carries `requiresConfirmation: true` and is persisted before return.
 
 ## Resource bounds