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 catalog enablement status;
• typed operational readiness (ready, unverified, or blocked) with its reason, owner, and evidence reference;
• 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 revision exists; disabled revisions still make a multi-revision selector ambiguous so callers must pin deliberately. A pinned disabled revision is refused. Inline secrets and token-looking values are refused.

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

Catalog enablement and operational readiness answer different questions:

• status: enabled permits deterministic selection after schema and rein compatibility checks;
• operational_readiness.status: ready requires a positive evidence_ref;
• unverified permits a bounded proof attempt but is carried into execution evidence and must not be described as ready; and
• blocked requires an owner plus evidence reference and is refused during resolution, before sandbox creation.

Profiles that predate the field default conservatively to unverified. The catalog command lists all enabled profiles and labels readiness; it does not filter blocked profiles or call them executable.

Catalog validation proves schema/compatibility, not transport installation. An execution host must install glas-harness with sand-boxer support and make each selected rein plus its dependencies available inside the sandbox transport, not merely on the host. Same-host bwrap execution enters the descriptor's namespace; remote execution crosses its SSH endpoint. The Claude-backed rein also needs its documented rein-aharness[llm]/sibling llm-connect adapter dependency in that environment. Missing runtime dependencies fail closed at session start and still trigger sandbox teardown.

The committed local profiles are currently declared blocked by GLAS-IN-0002. The remote profile is unverified because there is no positive post-hardening execution proof. There is currently no committed ready profile.

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 parallel local 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 declare green-commit-only and the same outer GatewayResult / ExecutionEvidence contract. They are interchangeable as catalog shapes, but both are currently operationally blocked and refused before sandbox creation. This does not claim current runtime availability or identical model 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.