← Selected systemsAI Software Factory / Engineering foundation
AI Software Factory / Engineering foundation
Harley
Intent becomes reviewed, tested and releasable software through an orchestrated engineering system.
Watch the systemGuided example · local only
No external code executor or deploymentA release needs review and test evidence.
Walk one bounded request through finding, repair and evidence.
CASE / HARLEYrequest
Bounded work order
Request: repair the release gate
scope: one local exampleowner: human reviewevidence: synthetic / reusable
Current stageBounded request
Bounded request is ready for a proposed change.
No receipt yet — the next gate is still open.Intent → engineered evidence.
31 seconds / illustrated workflow31 sec · System film
One orchestrator.
Distinct responsibilities.
Governed engineering architecture
ReasoningCodingReviewTestBrowserRelease
The work leaves a trail.
Work order
Build
Review
Test
Evidence
Engineering foundationBounded work ordersIndependent reviewEvidence gates
Technical details
The source repository explicitly records Harley First Cycle as a foundation design in Phase 5 decomposition. These nodes describe the accepted operating model; they do not claim that implementation, GitHub delivery, staging, deployment or production operations are complete.
- Owner or business intentStarts work with the real outcome, boundaries and decision authority instead of a free-floating agent prompt.
- Master and governance boundaryFixes the governing scope, source-of-truth precedence, status meanings and contour boundary before implementation.
- Product definitionTurns intent into a product lifecycle, users, value and bounded MVP decision that can be reviewed.
- Requirements and acceptance designDefines what must be true, how it will be tested and which evidence is needed before a claim can pass.
- Architecture and securityChooses the system shape, data, APIs, deployment and security boundaries before execution creates code.
- Capability and competency mapMaps the work to capabilities and competencies so a team is composed for actual obligations rather than quantity.
- Phase work ordersBreaks the accepted design into ordered, bounded slices with prerequisites, outputs and explicit non-executable planning limits.
- Orchestrator and workflow contractCoordinates a governed workflow and records state without becoming the authority that approves its own output.
- Dynamic team and agent registrySelects role slots and capability profiles for the work, with identity and grants kept separate from the proposal.
- Code and GitHub changeMaterializes an accepted work order as traceable code and change history in the product's own repository boundary.
- Independent reviewChecks the exact subject against the requirements and gates using an actor that did not author the change.
- Tests and verificationVerifies behavior against the accepted requirements and records failures before staging or release.
- Staging and releaseMoves a verified change through staging and deployment only when the required gates and external provider conditions are satisfied.
- Evidence and assurance ledgerBinds claims to exact artifacts, digests, runtime receipts and gate decisions so status cannot be inferred from intent or code alone.
- Owner operations and learningReturns verified operational learning and change decisions to the Owner so the next cycle starts from reality.