cyberstrategyinstitute/ai-safe2-framework/ai-safe2-development-method

AI SAFE2 Development Method

Convert software-development discipline into decision evidence. Keep policy, implementation, verification, semantic review, and human authority separate.

Workflow

1. Read the nearest repository instructions and current policy before acting.
2. Classify delivery shape independently from risk:

• spike: disposable learning; implementation does not become production output.
• bounded: limited scope with explicit acceptance conditions and exclusions.
• architectural: cross-boundary or durable design requiring a written spec and plan.

1. Create a safe2.development-plan-source.v1 source and run

safe2 dev plan SOURCE --output PLAN. Use the repository policy when present.

1. If the plan is review_required, pause only for the named missing decision.

Low- and medium-risk bounded work may proceed under existing user authority. Never work around an invalid plan.

1. Isolate repository-changing work. Preserve unrelated user changes.
2. Use the selected evidence mode:

• code: observe a failing behavior first, then the passing behavior;
• existing ambiguous behavior: characterize before changing it;
• contracts/configuration: establish the invalid/valid boundary first;
• documents/UI: use render or interaction validation;
• spike: record the hypothesis, result, and discard decision.

1. When a check fails, localize the cause before proposing a fix. Do not stack

speculative changes. Re-run the smallest affected check after each fix.

1. Review at the cadence in the plan. Treat PR-Agent, Greptile, and other model

reviewers as attributed evidence. Provider failure is unavailable, not pass.

1. Capture comparable before/after evidence when required. If no safe baseline

exists, preserve that gap and add a regression test without claiming a direct delta.

1. Before any completion claim, run fresh verification against the final revision

and produce safe2 dev receipt PLAN SOURCE --artifact-root ROOT --output RECEIPT.

Decision Rules

• Delivery shape controls design depth; risk controls scrutiny and authority.
• Architectural work and high/critical risk require explicit human design approval.
• Critical risk requires a threat model and specialist review cadence.
• A spike is disposable. Reusable output requires a bounded or architectural plan.
• Deterministic checks remain authoritative. Semantic reviewers explain and

corroborate; they do not replace tests, schemas, scanners, or human decisions.

• Never infer permission to merge, release, deploy, change policy, access secrets,

or accept residual risk from a plan or receipt.

References

• references/method.md: classification, debugging, evidence, and receipt guidance
• references/evaluation.md: pressure cases and regression expectations