The problem
An operating specification alone does not establish a repeatable, repository-local way to work.
Repositories need a discoverable, consistent starting point rather than assuming an agent knows where to find current work and authority.
The underlying question is not simply whether the project can perform a task, but how that task can remain understandable, repeatable, and safe as conditions change.
The solution
Provide an installable .flywheel structure, manifest-driven startup, bootstrap missions, lifecycle records, and governance guidance.
Read .flywheel/manifest.yaml, follow its entrypoint, load the required operating artifacts in order, then use missions, goals, execution records, and evidence to govern work.
Adopt the framework when an existing repository needs an explicit AI operating model, including lifecycle records, decisions, and evidence.
Who it's for
Repository owners adopting the AI Flywheel operating model.
A practical fit is a reader or maintainer who wants a defined workflow and documented boundaries rather than an unexplained one-off operation.
Adopt the framework when an existing repository needs an explicit AI operating model, including lifecycle records, decisions, and evidence.
How it works
Key capabilities and concepts. See the project documentation or source code for implementation details.
Installs a canonical .flywheel structure and manifest-driven startup
Installs a canonical .flywheel structure and manifest-driven startup.
Read .flywheel/manifest.yaml, follow its entrypoint, load the required operating artifacts in order, then use missions, goals, execution records, and evidence to govern work.
Provides onboarding, bootstrap missions, and goal records
Provides onboarding, bootstrap missions, and goal records.
The framework is intentionally toolchain-neutral. That allows adoption across repositories, but repository-specific automation emerges through onboarding rather than being prescribed upfront.
Captures lifecycle state, evidence, learning, and governance
Captures lifecycle state, evidence, learning, and governance.
Adopt the framework when an existing repository needs an explicit AI operating model, including lifecycle records, decisions, and evidence.
Design decisions that matter
- Use the manifest as the authoritative entry point.
Use the manifest as the authoritative entry point.
The framework is intentionally toolchain-neutral. That allows adoption across repositories, but repository-specific automation emerges through onboarding rather than being prescribed upfront.
- Remain independent of programming language and toolchain.
Remain independent of programming language and toolchain.
Repositories need a discoverable, consistent starting point rather than assuming an agent knows where to find current work and authority.
- Support manual operation before repository-specific tools are built.
Support manual operation before repository-specific tools are built.
Read .flywheel/manifest.yaml, follow its entrypoint, load the required operating artifacts in order, then use missions, goals, execution records, and evidence to govern work.
Explore the implementation
The framework repository contains the current installation model, operating artifacts, and onboarding guidance.
The framework is intentionally toolchain-neutral. That allows adoption across repositories, but repository-specific automation emerges through onboarding rather than being prescribed upfront.
For exact current usage, prerequisites, and release status, consult the source repository.
Related articles
Engineering context and lessons behind this project.