Write lifecycle: propose → validate → apply

This lifecycle is the safest default for AI-assisted changes to your design system.

Copy link to sectionWhy this lifecycle exists

AI can generate fast. Governance requires correctness, context, and accountability. The lifecycle separates the three concerns:

• Idea generation — proposing a change
• Policy validation — checking the change against rules, tokens, patterns, and mode
• State-changing apply — committing the change to canonical artifacts

Skipping stages is allowed in low-risk environments. Skipping them in Guard or Enforce mode is not.

Copy link to sectionStage 1: Propose

Create a structured proposal before modifying canonical state.

A proposal should include:

• Intent and target artifacts
• Suggested change payload
• Rationale and expected impact
• Confidence and open questions

Expected output:

• Proposal ID
• Machine-readable diff summary
• Required approvals (if any)

Copy link to sectionStage 2: Validate

Run validation against rules, tokens, patterns, and the active compliance mode.

Validation checks should cover:

• Schema and structural validity
• Token, preset, and pattern alignment
• Interaction and accessibility constraints
• Drift impact and compatibility risk

Expected output:

• Pass/fail status
• Severity-ranked findings
• Auto-fix suggestions where safe

Copy link to sectionStage 3: Apply

Apply only when policy conditions are satisfied.

Typical apply gates:

• Validation pass (or allowed exception)
• Approval requirements met
• Write scope present

Expected output:

• Applied artifact version or snapshot reference
• Audit log entry
• Post-apply verification result

Copy link to sectionApproval patterns

Choose one based on environment risk:

• Low risk — auto-apply when validation passes
• Medium risk — human approval for specific artifact types
• High risk — mandatory multi-step approval and change window

Copy link to sectionFailure handling

If validation fails:

• Do not apply
• Return actionable findings
• Keep the proposal editable and re-runnable

If apply fails:

• Return a clear error and rollback status
• Preserve the proposal and validation context
• Require explicit retry

Copy link to sectionAudit requirements

For each lifecycle run, persist:

• Actor (human, AI, or tool identity)
• Inputs and resulting diff metadata
• Validation findings
• Approval events
• Final apply status

Copy link to sectionRecommended default policy

For most teams:

1. Always propose first
2. Always validate before apply
3. Require explicit approval in Guard and Enforce modes
4. Capture snapshot or version metadata on apply