Skip to main content

Contract-First SDLC designed

GPUaaS is intentionally biased toward design and contract before code. That is how the platform avoids discovering missing flows, missing APIs, and broken recovery paths only during UAT or release.

Delivery Rule​

Flow and UX shape first -> contract and ownership second -> code third

What This Proves​

AudienceWhat this page should prove
Productfeature delivery starts from workflow completeness, not just implementation tickets
Developerscode is downstream of route, contract, state, and ownership decisions
Architecturethe target system shape is decided before code spreads across layers
Security / opsdeploy and live validation are not the first discovery loop

Lifecycle​

1. Product Gap And Dependency Mapping​

Critical flows do not start from "let's code the page".

They start from:

  • persona;
  • canonical entry point;
  • happy path;
  • empty and blocked states;
  • in-place recovery;
  • cleanup / rollback;
  • fixture, permission, provider, DNS, browser, and environment prerequisites.

If those are unknown, the work is not development-ready yet.

2. UX And Flow Shape​

For user-visible or operator-visible behavior, the page family and workflow shape must be clear before implementation broadens.

That means:

  • route placement is known;
  • role boundaries are known;
  • loading, blocked, error, success, and cleanup states are known;
  • the user can recover in place where appropriate.

3. Contract Before Code​

Public behavior changes start in contract artifacts:

  • OpenAPI for REST
  • AsyncAPI for events
  • CLI or SDK surface where relevant

Code should follow the contract, not reverse-engineer it later.

4. Codegen As A Real Gate​

Contract work is not complete until generated artifacts are validated.

This is why the SDLC explicitly includes:

  • contract update
  • codegen run
  • enforced-clean drift check
  • generated artifact commit

Without that, frontend and backend drift quietly until CI or runtime use finds it late.

5. Implementation In The Owning Lane​

Implementation should happen only after the owning route, domain, state machine, and schema boundaries are clear.

Typical ownership chain:

  • contract and route authority
  • backend/domain package
  • shared-service boundary
  • frontend surface
  • worker/runtime path
  • readback/evidence path

If the owner is unclear, architecture work comes before feature coding.

6. Focused Proof Before Broad UAT​

Broad UAT is not the first discovery loop.

The expected order is:

  1. focused proof for the changed flow;
  2. reusable automation or smoke where appropriate;
  3. broad UAT only when the dependency graph is already mapped.

7. Environment And Deploy Readiness​

Promotion happens only after the same source SHA has:

  • passed the required local and CI gates;
  • produced deploy/readback evidence;
  • satisfied the required review shape for the risk boundary;
  • shown rollback or safe next action where needed.

Escape-Rate Rule​

If broad UAT or live validation discovers:

  • a missing flow,
  • a missing dependency,
  • a missing API,
  • a missing recovery path,
  • or a harness gap,

that is an earlier-gate miss. It should become a scoped task and update the flow coverage model so the same class of issue moves upstream next time.

Why This Model Exists​

The team learned that strong design docs alone are not enough if the actual dependency map is discovered during UAT, live windows, or deploy.

The contract-first SDLC exists to make this sequence explicit:

  • product intent
  • dependency map
  • contract
  • implementation
  • proof
  • deploy/readiness evidence

Next Reading​

Canonical sources