glas-harness/docs/execution-profiles.md

Execution profiles and workforce handoff

Glas profiles are versioned execution constellations. They make the execution layer replaceable without changing an upstream workforce assignment.

RoleAssignment / activity / channel
  | organizational refs + bounded task + harness_profile_ref
  v
ExecutionRequest
  | deterministic profile validation
  v
rein + model route + sandbox profile + tool profile + limits
  | one outer lifecycle
  v
ExecutionEvidence -> assignment/audit consumers

Profile schema

Each YAML document under profiles/ declares:

• stable id, semantic version, exact contract_version, and status;
• rein registry ID and required capabilities;
• sand-boxer sandbox_profile;
• rein-enforced tool_profile;
• model provider, explicit model identifier, model class, and route;
• positive token/timeout/turn limits when applicable; and
• credential route references and non-secret metadata.

The catalog discovers files deterministically, forbids unknown schema fields, rejects duplicate revisions, and checks the selected profile against registry/reins/*.yaml. Unpinned lookup is accepted only when exactly one enabled revision exists. Inline secrets and token-looking values are refused.

Use glas-harness profiles as the catalog/packaging validation command.

Catalog validation proves schema/compatibility, not host installation. An execution host must install glas-harness with sand-boxer support and each rein used by its enabled profiles. The Claude-backed rein also needs its documented rein-aharness[llm]/sibling llm-connect adapter dependency. Missing runtime dependencies surface as startup/execution failure evidence and still trigger sandbox teardown.

Consumer request

See examples/execution-request.json. Consumers know only a profile reference, not ReinAharness, ReinOpenWeights, Claude Code arguments, or OpenRouter client details. An assignment system may set the organizational references; a channel may omit fields it does not own.

If the requested profile, contract, rein, capability, resource envelope, or credential route is unavailable, the caller must receive a refusal/failure. No consumer may silently substitute a different rein or model constellation.

The current exact-profile path does not interpret resource envelopes or choose profiles from requirements. A future requirements resolver belongs at this Glas boundary, must be deterministic and explainable, and must refuse ambiguity.

Two equivalent selections

For the same task and organizational references, switch only:

harness.agent-dev-local@1.0.0
  -> rein-aharness / claude-sonnet-4-6 / profile.bwrap-local

harness.agent-dev-openweights-local@1.0.0
  -> rein-openweights / qwen/qwen-2.5-72b-instruct / profile.bwrap-local

Both use green-commit-only and return GatewayResult / ExecutionEvidence. This proves interchangeability at the Glas boundary; it does not claim the models have identical quality, price, or provider behavior.

Ownership handoff

• Agentic-resources/KaizenAgentic: leadership, role, duty, goal, resource envelope, worker/agent instance, and assignment definitions.
• Activity-core or a channel: when work is invoked and the bounded task input.
• Glas: versioned execution selection, lifecycle, attribution, and evidence.
• Rein: inner loop, backend-specific policy enforcement and credentials.
• llm-connect/provider: inference/provider boundary and model capabilities.
• Sand-boxer: sandbox profiles, placement, provisioning, and teardown.

Rollback is selection-based: repin a caller to its last approved Glas profile. Do not bypass Glas with --sandbox-profile or add a hidden default rein.