Implementation

Purpose and boundary

Implementation turns approved design into reviewed code, records, and a candidate. Material changes need review. A green build is not readiness; Testing gathers evidence.

What starts here, what continues, and what feeds back

Use scope, criteria, and Design. Material proposals need an RFC; durable decisions an ADR. Give Testing a versioned candidate with evidence, migrations, flags, and manual checks.

What happens here

Trace small changes to requirements or decisions. Version code, configuration, manifests, flags, schemas, policies, and runbooks together.

Use SLSA’s build requirements for provenance-backed builds and, at L3, isolated builds. Record each source, dependency, CI action, base image, and tool with name/URI and resolved digest; a digest identifies content, not trust. Accept approved publisher or canonical source, immutable identity, and signature; reject mutable labels, branches, and latest. Centralise hardened definitions.

Keep secrets out of source, logs, definitions, attestations, and hand-offs. Untrusted pull-request jobs get no secrets or privileged credentials. Privileged work uses a fresh, isolated build from the protected revision and independently verifies pull-request code, artefacts, caches, workspace, and workflow values. Use short-lived least-privilege credentials. Before signing, a protected control plane generates or verifies provenance from authenticated records and controlled output storage; keys stay unavailable to user-controlled steps.

Record a bill of materials: URI, digest, reason, and gaps. Test rules, errors, conversions, permissions, components, and interactions in CI and locally; this finds regressions, not integration evidence.

Authors state intent, risk, and evidence; reviewers assess design, function, tests, docs, and coverage. Approval covers the final protected revision; changes need review. Use specialists for material security, privacy, concurrency, or accessibility. Resolve or justify comments.

Keep integrity, provenance, test evidence, and reproducibility separate. Integrity compares a candidate with trusted digest or approved-identity signature. Trust SLSA provenance only after policy verifies its signed envelope against configured root; minimum accepted builder assurance/isolation and mode-specific identity (reject lower modes); allowed predicateType, subject digest, signer-builder pair, expected buildType, complete allowlisted externalParameters (reject extras/mismatches), and immutable source/configuration dependencies. internalParameters are not caller inputs; retain non-secret output-affecting values in protected, integrity-bound rebuild/incident records and exclude/redact secrets. Provenance binds recorded subjects, dependencies, definition, and builder—not hidden inputs, tests, or unrecorded migration. A migration is bound only when its exact digest is a verified input or subject; otherwise bind it in the authenticated image-bound manifest. Reject missing build-contract dependencies and record accepted gaps.

Accept approved versioned predicates or signed subject-bound evidence with a policy schema. A protected, versioned test policy pins role/digest pairs for harness, test plan (required IDs), test/candidate configuration, fixtures/data, and target platform/environment. Evidence binds all named roles and the exact candidate subject. Policy checks envelope/root, trusted signer-runner pair, and that every role/digest equals the authenticated image-bound manifest or test policy; URLs never count. Require in-toto Test Result evidence: PASSED, required IDs in passedTests, no failedTests, and policy-accepted warnings. A source-revision fallback must identify the canonical repository and match the immutable revision in the candidate’s verified provenance dependency; otherwise use exact subject.

Reproducibility means specified unsigned primary subjects rebuild byte-identically from declared inputs, platform, environment, and instructions; logs are outside them. Embedded-signature transforms are versioned, documented, scripted, audited, and proved limited to safe signature bytes; otherwise include signatures. Use independently controlled rebuilds; classify mismatches with owner/reason.

Who owns what

Name risk and blocker owners. Engineers maintain evidence; reviewers approve work. Product confirms outcomes; design, security, and operations check accessibility, boundaries/secrets, and recovery.

Start with and leave with

Start with scope, criteria, design, constraints, checks, and invariants. Leave with reviewed source/configuration, unit evidence, repeatable build, and trust records linked to change, design, migrations, and checks.

Ready to continue, pause, or revisit when

Apply gates proportionately; the criteria below describe the highest assurance tier.

• Behaviour traces to approved requirements and design decisions.
• Code, configuration, and documentation have risk-proportionate review of the final protected revision; concerns are resolved or accepted.
• Build, static checks, and relevant tests pass for the exact source revision and candidate.
• Every artefact input has URI and resolved digest. Each non-secret scalar external parameter has exact typed allowlisted value or content-addressed configuration. No hidden output value is allowed unless an access-controlled, integrity-bound record retains every non-secret output-affecting internal value for rebuild/incident use; actual secrets are excluded/redacted and never reach untrusted jobs. Privileged builds are fresh protected-revision builds independently verifying pull-request inputs.
• A protected control plane writes signed provenance from authenticated records and controlled output storage. Policy verifies envelope/root, minimum assurance/isolation level, mode-specific builder identity, type, subject, signer-builder pair, build type, complete allowlisted externalParameters, source/configuration digests, and dependencies; it rejects extras/mismatches, lower modes, and unrecorded migrations as bound.
• Test policy accepts only that evidence. It checks root/signer-runner, every named role against the authenticated image-bound manifest or protected test policy, PASSED, required passedTests, no failedTests, and accepted warnings; only explicit, documented non-behavioural exceptions pass. A source fallback equals the canonical repository and immutable revision in the candidate’s verified provenance dependency; otherwise use exact subject.
• An immutable, authenticated image-bound manifest binds image subject (digest/platform/media type), configuration content or digest, flag rules/targets/values, migration digests, and toolchain descriptors. Accept it only through a signature to the configured trust root or a verifier-pinned registry-policy binding whose root and policy are recorded; verify that binding and every entry. Hand it to Testing with attestation locations/digests and results.
• Rebuild unsigned primary subjects byte-identically from declared inputs, platform, environment, and instructions; exclude logs. Embedded-signature transform is versioned, documented, scripted, audited, and limited to safe signature bytes; otherwise include signatures. Independently controlled rebuilds classify mismatches and own residual risk.

Common mistakes

Do not code from a ticket title or add material decisions without an RFC or ADR. Do not hide configuration, scripts, failures, or uncertain integration. Avoid unpinned inputs, secrets, and mutable artefact labels.

Illustrative guest checkout

This fictional example uses invented names, figures, dates, and thresholds.

Shoppers buy without accounts; account checkout stays stable.

Engineers implement the approved flow, migration, and test configuration. Tests cover contact/delivery, account checkout, duplicate submission, and unverified lookup. Guest support uses only the approved identity-verification procedure (IVP) and its IVP-issued, server-verified, single-use proof; another method needs a Design/PRD change. Before disclosure, one conditional, serialisable trusted-service operation validates the proof’s approved issuer and integrity; binds actor, verified subject, exact order, purpose, issue/expiry, nonce, and issuance authorisation/revocation generation; atomically checks current function/data/tenant authority and equality of issuance and current authorisation/revocation generations, consumes proof, appends audit record, and returns least fields. Revocation and regrant writes share its serialisation domain and win: no consumption or data. An object ID is never authority. Tests reject forged/malformed, wrong actor/subject/order/purpose/tenant, replayed, expired, revoked, removed-access, concurrent same-proof, revoke/authority-change-versus-consume, and revoke-then-regrant old-proof requests.

The build produces an immutable image: digest, platform, media type. Its immutable, authenticated image-bound manifest binds that image, exact configuration content or digest, flag rules/targets/values, migration digests, and toolchain descriptors. Testing accepts only evidence whose named roles match that manifest or the protected test policy, apart from explicit documented non-behavioural exceptions. The Testing hand-off includes manifest, attestation locations/digests, results, and test payment/email-sandbox references. Testing proves guest/account journeys, failures, accessibility, and analytics.

Continue with

Use Design for interfaces, failures, data boundaries, and trade-offs; RFCs for material proposals; and ADRs for durable decisions. Continue to Testing for system/release evidence.