01
Specify
Define the requested outcome, repository or system boundary, constraints, acceptance criteria, risk, and required evidence.
ILAIOS Software Factory
Software engineering with explicit boundaries and acceptance gates.
Software Factory converts software goals into governed engineering work rather than treating code generation as an unrestricted one-shot request.
Software Factory at a glance
Turn requirements into tested, reviewable software changes.
The target visual keeps requirements, implementation, tests, review, bounded repair and handoff visible without treating a code diff as completion.
Target workflow: requirement + context → scope & plan → implement → test → review → bounded repair → tested change.
ILAIOS tracks capability maturity separately from release state. Repository verification for a bounded scope does not claim every Software Factory function or external effect is generally available today.
02
Plan
Decompose work into bounded engineering jobs with dependencies, ownership, permissions, and a validation plan.
03
Inspect before changing
Use source, symbol, dependency, configuration, and runtime context where available instead of making blind edits.
04
Implement inside scope
Engineering capabilities modify only authorized files and systems; architecture and security boundaries remain authoritative.
05
Test & review
Run applicable deterministic tests, lint/type/static checks, code review, and security checks before acceptance.
06
Verify independently
Material work is not accepted solely because its author or executing process reports success. Required independent verification remains risk-driven.
07
Release preparation
Version artifacts, capture build/test/security evidence, prepare rollback or recovery semantics, and keep environment progression explicit.
08
Deliver & reconcile
Deliver source/build/deployment preparation with traceable evidence; failures follow bounded diagnose, repair, retest, retry, or rollback paths.
Governed delivery
Implementation, verification, merge and release authority remain separate where risk requires it.
A tested change is not automatically merged, deployed or production-verified. Those transitions require their own evidence.