Indian Hill Container Operations¶

Indian Hill Container Operations is an Indian Hill-only product profile powered by Alfred V1.1. Alfred is the durable control plane for lifecycle state, policy, approvals, controlled execution, and audit. This repository is the evidence producer and a narrowly scoped repository/build adapter: it evaluates immutable build evidence, emits proposals, and may perform only explicitly autonomous engineering actions delegated by Alfred. It does not become a second control plane and is not permitted to weaken the controls that judge its work.

The operating model¶

The controller follows a closed loop:

Observe supported release digests, SBOMs, supplier releases, scanner databases, CISA KEV, end-of-life notices, build health, and deployment health.
Reconcile current evidence with durable lifecycle state. A scanner match becomes a stable case instead of an isolated CI log entry.
Decide priority, remediation objective, fix availability, and the next allowed actions from the controlled lifecycle policy.
Remediate by preparing a base-image refresh, dependency update, configuration change, applicability investigation, mitigation, or VEX statement.
Qualify every changed artifact as a new immutable digest through the complete Secure, Hardened, or Validated pipeline. The agent cannot mark its own output qualified.
Release and operate through separately authorized publication, production promotion, and deployment boundaries, followed by health monitoring and rollback when required.
Learn from elapsed time, failed attempts, false-positive analysis, rollback events, and escaped findings using versioned evaluations. Learning can improve proposals; it cannot silently change policy or authority.

Repository adapter and policy kernel¶

compliance/agent/container-lifecycle-policy.json is the initial fail-closed authority policy. ci/container_lifecycle_agent.py consumes the exact Grype reports, KEV-enriched vulnerability summary, artifact digests, full source revision, repository and pipeline identity, and optional prior state. It emits:

container-lifecycle-state.json: active and resolved cases, first-observed time, remediation objective, affected digests, package identity, fix availability, and release eligibility;
container-remediation-plan.json: ordered, idempotent actions with an explicit authority mode;
container-lifecycle.env: small CI facts for downstream gates and dashboards.

The policy file is a controlled producer-side guardrail and authority snapshot; Alfred remains the authoritative policy and approval plane. A reasoning model may analyze upstream changes, applicability, reachability, test failures, and candidate patches, but it receives only the tools allowed for the current action. The executor must reject any action not present in an Alfred-validated plan or whose authority is not autonomous.

Alfred V1.1 integration contract¶

Both JSON files use ihl-alfred-container-operations contract version 1.0.0 and validate against compliance/agent/ihl-container-operations-envelope-v1.schema.json. The report payload remains schemaVersion: 1 and retains its existing report type. The envelope fields are:

Field	Contract
`contract`	Exact name/version plus product profile, `indian-hill` producer, and `alfred-v1.1` control plane. Unknown versions fail closed.
`message`	Deterministic message ID, caller-supplied correlation ID, deterministic SHA-256 idempotency key, canonical UTC generation time, and payload SHA-256.
`source`	GitLab project ID/URL, pipeline ID/URL, and full 40- or 64-hex Git object ID marked immutable with its algorithm.
`artifacts`	Exactly `runtime` and `referenceApi`; each entry repeats the digest-bound image reference and matching `sha256:` digest.
`policy`	Policy ID, policy schema version, and SHA-256 of the exact policy file bytes. Alfred must allowlist the accepted policy identity and hash.
`evidence`	Unique typed URI plus SHA-256 references. Policy, vulnerability summary, runtime Grype report, and reference API Grype report are mandatory; prior state is included when used.
`authority`	`autonomous`, `approval`, and `forbidden` modes; unknown actions default to `forbidden`; the complete action-to-mode snapshot is included.
`payload`	The existing `ihl-container-lifecycle-state` or `ihl-container-remediation-plan` report.

Hashes use lowercase sha256:<64 hex>. Evidence hashes cover exact file bytes. Payload and idempotency hashes use UTF-8 canonical JSON with recursively sorted keys and separators , and : without insignificant whitespace. The idempotency hash covers exactly contract, payload reportType, source repository and revision, artifacts, policy, and evidence. Pipeline, correlation, timestamps, and payload outcome are deliberately excluded, so a pipeline retry for the same immutable inputs deduplicates while keeping a distinct correlation trail. Message ID is message- plus the first 20 hex characters of SHA-256 over the report type and idempotency key, separated by U+001F, matching the producer's stable_id function.

The paired state and plan must have identical contract, source, artifact, policy, evidence, and authority bindings and the same correlation ID. The producer validates those invariants before writing either file. Alfred must independently validate the schema, recalculate hashes and idempotency identity, verify referenced evidence bytes, allowlist repository and policy identity, require the two messages to agree, and reject missing, duplicated, unknown, malformed, stale, or mismatched fields. A syntactically valid plan is evidence, not execution authorization.

compliance/agent/ihl-container-operations-conformance-v1.json is the language-neutral Alfred conformance vector. It fixes a canonical JSON byte sequence and SHA-256 plus the exact state and plan idempotency keys and message IDs for a common synthetic binding. A consumer is compatible only when it reproduces every value exactly. For each channel, construct the idempotency object by copying idempotencyBasis and adding that channel's reportType.

Verified delivery bundle¶

The agent:remediation-plan job runs ci/validate_container_lifecycle_envelopes.py after generation and before artifact upload. The validator treats state and plan as one atomic handoff, checks their shared bindings and lifecycle counts, and re-hashes caller-selected evidence paths; it never opens a path supplied by the envelope. The developer-restricted, one-year job artifact contains:

the lifecycle state and remediation plan envelopes;
the vulnerability summary and both Grype reports referenced by those envelopes;
the exact lifecycle policy referenced by hash;
the v1 JSON Schema and conformance vector.

Alfred should retrieve the complete archive through the authenticated GitLab job-artifact API. It must verify the expected project, pipeline, commit, successful job, and artifact access policy before applying the same contract checks. Producer validation is defense in depth and does not replace Alfred validation or approval.

For local or incident-response verification, run the same independent check from the repository root:

python ci/validate_container_lifecycle_envelopes.py \
  --policy compliance/agent/container-lifecycle-policy.json \
  --state pipeline-evidence/container-lifecycle-state.json \
  --plan pipeline-evidence/container-remediation-plan.json \
  --evidence lifecycle-policy=compliance/agent/container-lifecycle-policy.json \
  --evidence vulnerability-summary=pipeline-evidence/vulnerability-summary.json \
  --evidence runtime-grype-report=pipeline-evidence/runtime.grype.json \
  --evidence reference-api-grype-report=pipeline-evidence/reference-api.grype.json

Shadow-mode acceptance¶

Before enabling an Alfred-triggered repository or build action, retain audit results for these five tests against a real successful pipeline:

Test	Required result
Authentic retrieval	Alfred binds the archive to the allowlisted GitLab project, successful job, pipeline, and exact source revision.
Normal ingestion	Both messages and all evidence hashes validate; no side effect occurs.
Replay	Reingestion has the same per-channel idempotency keys, records a replay, and creates no duplicate case, proposal, or execution.
Tamper and mix	A changed evidence byte or envelopes from different pipelines is rejected before durable state changes.
Authority	Autonomous actions remain shadow observations; approval actions become non-executable proposals; unknown and forbidden actions are rejected and audited.

Shadow mode passes only when all five results are demonstrated and no source, registry, publication, deployment, withdrawal, policy, or evidence mutation was possible through the ingestion identity.

Authority boundary¶

Action class	Initial authority
Observe, correlate, open/update a case, block an unsafe promotion	Autonomous
Prepare a base refresh or dependency patch, run tests, rebuild, scan, qualify, draft VEX	Autonomous
Publish a replacement, promote to production, deploy to production, withdraw a release	Approval required
Weaken or change lifecycle/assurance policy, disable a security control, delete evidence	Forbidden

These boundaries are deliberately asymmetric. The agent may do extensive reversible engineering work without waiting, while actions that alter customer or production state remain independently authorized. More autonomy should be earned per action through measured reliability, not granted as one global switch.

Alfred-owned durable service architecture¶

The Alfred V1.1 production service owns five independently secured components:

Event gateway: signed GitLab, registry, advisory, and deployment events plus scheduled reconciliation. Events are deduplicated and retained.
Lifecycle database: the durable system of record for supported products, immutable releases, cases, attempts, approvals, deployments, VEX, and evidence references. CI artifacts or caches are not the source of truth.
Reasoning workers: isolated worktrees with short-lived credentials, network allowlists, bounded retries, and an explicit tool set for each planned action.
Policy/execution gateway: validates action ID, authority, artifact identity, approval, environment, and evidence preconditions immediately before every side effect.
Evidence and telemetry: append-only audit events, traces, cost, latency, failure reason, qualification result, signature identity, deployment health, and rollback outcome.

The agent must use workload identity rather than stored cloud credentials. Separate identities are required for observation, source changes, candidate builds, release, production promotion, and deployment. No reasoning worker should receive all of them.

Rollout¶

Shadow mode: run reconciliation and compare plans with human decisions; no source writes.
Engineering autonomy: allow branches, patches, merge requests, candidate pipelines, VEX drafts, and evidence collection. Measure precision, successful qualification, time-to-fix, retry rate, and human override rate.
Release preparation: allow signed release proposals and staged rollout plans, but retain approval for customer-impacting actions.
Narrow production autonomy: only after evaluations show reliability, consider approving specific low-blast-radius rollout classes through pre-authorized policy. Emergency withdrawal, policy changes, and evidence deletion remain independently controlled.

The current repository implements only the deterministic evidence kernel and the Indian Hill repository/build adapter. Alfred V1.1 owns the durable event service, lifecycle database, reasoning/executor coordination, release catalog, approvals, audit, and production rollout controller. No integration message grants this repository publication or production authority.