AWP Engineering Practices

Increment map

Practice	Status	First required	Primary tool/standard
R1 Architecture conformance	Accepted	Increment 0	dependency-cruiser
R2 Threat modeling	Accepted, conditional	AWP before Increment 1; Planning in 2	OWASP / Threat Dragon
R3 SBOM + provenance	Accepted	When artifacts distribute; full in 6	CycloneDX, SLSA, Trivy, Cosign, ORAS
R4 Contract compatibility	Accepted	When stable consumers exist; CI in 5	OpenAPI + oasdiff
R5 Reliability/SLO	Accepted, parked	Increment 9	OpenSLO; Sloth/Pyrra if applicable

R5 is intentionally last. Dogfooding needs telemetry and failure visibility, not an SLO/error-budget product. Formal reliability objectives arrive when AWP is prepared for external/enterprise operation.

R1 — Architecture conformance

Binding module/trust rules must become executable detectors when practical so architecture does not erode during incremental implementation.

gateway -> contracts only
domain -X-> Hono
domain -X-> provider SDK types
gateway -X-> DBOS / Kubernetes / control repositories
agents/runners -X-> reusable publication authority

Tool: prefer dependency-cruiser for TypeScript dependency rules unless an existing Platform capability is simpler.

R2 — Conditional threat modeling

Threat modeling is triggered by security/privacy/trust boundaries rather than applied to every Plan. AWP itself must have a maintained threat model before the privileged first dogfood lifecycle.

Trigger examples
  authentication / public ingress
  provider credentials
  privileged execution
  production-control authority
  PII / sensitive data
  multi-tenancy
  untrusted-code execution

Tool: OWASP methods and Threat Dragon for data-flow/threat/mitigation authoring where useful.

R3 — SBOM and verifiable build provenance

Released or otherwise meaningful distributable artifacts preserve evidence bound to immutable identity.

artifact digest
source revision
SBOM
build provenance / builder identity
build inputs
signature / attestation verification
vulnerability result bound to digest

Standards/tools: CycloneDX preferred, SPDX accepted; SLSA/in-toto compatible provenance; Trivy; Cosign; ORAS. Use Syft only when it provides a concrete advantage over the existing Trivy path.

R4 — API and contract compatibility

Compatibility gates protect declared compatibility boundaries. They do not freeze internal dogfood contracts that can still change atomically with all consumers.

canonical contract
  -> proposed change
  -> compatibility diff
  -> compatible: normal review
  -> breaking: Decision + migration/versioning policy

Tools: OpenAPI for HTTP contracts where applicable; oasdiff for breaking-change detection.

R5 — Reliability / SLO / error-budget policy

Accepted, but parked for external productization. Dogfooding retains basic telemetry, health, incidents and failure visibility without building an SLO subsystem.

Later ReliabilityPlan
  user-relevant SLIs
  SLO targets
  measurement window/source
  optional error-budget policy
  owner/review cadence
  release/incident policy links

Tools: OpenSLO as portable representation; Sloth or Pyrra when Prometheus-compatible metrics justify rule generation.

Decision and traceability integration

Material adoptions, exemptions and supersessions use the canonical Decision / Approval contract. Architecture, security, compatibility and reliability rules should point to the Decision or requirement that created them.

Verification principle: use the smallest check that can meaningfully falsify the property; broaden only for a recorded reason; stop when sufficient still-valid evidence exists.