Give each assurance commitment a clear meaning

A shared objective connects the mechanism to implement, its operation and the evidence needed to evaluate it.

Give each assurance commitment a clear meaning

“We have a control” is useful only when people agree what it must do. Wildo defines objectives together with implementation expectations and the evidence needed to evaluate them. An application builds its assurance programme from that shared basis.

This keeps the framework’s contribution visible alongside the application’s own responsibilities. Selecting an objective, configuring its mechanisms and demonstrating that it operates are separate steps.

Example — Know what an access review must demonstrate

The framework supplies a scoped population of privileged users. The programme can also require a review occurrence: who reviewed that population, what was decided and where the outcome is retained.

For engineers

Build the authority snapshot from the application

createAssuranceProgramValidationAuthorities accepts the basis, enabled capabilities, application roles and host artifacts. This source excerpt shows the availability decision; omitted snapshot fields carry the same basis’s implementation and evidence expectations.

export function createAssuranceProgramValidationAuthorities(input: {
  readonly basis: unknown;
  readonly hostFacts: AssuranceProgramAuthorityHostFacts;
  readonly evaluatedAt: string;
}): AssuranceProgramValidationAuthorities {
  const basis = assertAssuranceProgramAuthorityBasisIsCoherent(input.basis);
  for (const artifact of input.hostFacts.hostImplementationArtifacts) {
    AssuranceProgramHostImplementationArtifactSchema.parse(artifact);
  }
  const enabledCapabilities = new Set(input.hostFacts.enabledEngineCapabilities);
  const snapshot = AssuranceProgramValidationAuthoritySnapshotSchema.parse({
    schemaVersion: 1,
    snapshotRef: basis.basisRef,
    snapshotVersion: basis.basisVersion,
    evaluatedAt: input.evaluatedAt,
    requestedSourceUses: basis.requestedSourceUses,
    sourceRegistry: basis.sourceRegistry,
    documentAuthorityCatalog: basis.documentAuthorityCatalog,
    objectiveCatalog: basis.objectiveCatalog,
    applicationRoleRefs: [...new Set(input.hostFacts.applicationRoleRefs)].sort(compareCanonicalText),
    capabilityAuthorities: basis.capabilityAuthorityDescriptors
      .filter(({ availability }) => isAssuranceCapabilityAvailable(availability, enabledCapabilities))
      .map(({ authority }) => authority),
    implementationArtifacts: basis.implementationRevision.artifacts,
    hostImplementationArtifacts: [...input.hostFacts.hostImplementationArtifacts].sort(
      (left, right) => compareCanonicalText(left.artifactKindRef, right.artifactKindRef) || compareCanonicalText(left.artifactRef, right.artifactRef),
    ),
    sourceRequirementAuthorities: basis.sourceRequirementAuthorities,
    implementationExpectationAuthorities: basis.implementationExpectationAuthorities,
    evidenceExpectationAuthorities: basis.evidenceExpectationAuthorities,
    verificationExpectationAuthorities: basis.verificationExpectationAuthorities,
  });
  return Object.freeze({ snapshot });
}

The application’s capability selections constrain which framework contributions it can claim. Host artifacts supply application-owned evidence contracts. A basis version identifies the interpretation of those commitments, so a programme can be reviewed against a specific framework generation.

Keep proof stages distinct

The programme uses an explicit ladder:


export enum AssuranceProgramProofStage {
  SELECTED = "SELECTED",
  CONFIGURED = "CONFIGURED",
  OPERATING = "OPERATING",
  EVIDENCED = "EVIDENCED",
  ASSESSED = "ASSESSED",
}

requiredProofStage expresses the programme’s target. It is not an observation that the target was reached. A configuration can establish CONFIGURED; an execution must substantiate operation; evidence must support the claimed period and scope. External assessment has its own authority.

Review the complete obligation

For each objective, read the bound capability references, implementation expectation, evidence requirement body and verification expectation together. A security event can prove an action occurred without proving that a periodic review occurred. Application owners provide the latter contract where it belongs. The intended assurance workflow can collect and evaluate these distinct records without flattening them into a single “compliant” flag.

Give each assurance commitment a clear meaning