Faster delivery
Less time is spent exploring unrelated code before useful work begins.
AI-native software architecture
Software delivery, re-engineered for humans + AI.
AIFA turns every feature into a clear, enforceable agreement—so people set the intent, AI accelerates the work, and the architecture keeps both aligned.
- Less hidden context
- Safer delegation
- Easier review
A
SYSTEM ALIGNED
AIFA CONTROLFEATURE DELIVERY PROTOCOL
SHAREDCONTRACT01
01
INPUTCustomer need
02
POLICYExplicit rules
03
EXECUTIONHuman + AI
04
OUTPUTVerified result
The business question
What if a team could change one feature without first rediscovering the whole product?
AIFA turns hidden project knowledge into a visible, reviewable contract.
Why it is good
Better delivery through shared understanding.
AIFA does not remove complexity. It makes complexity visible before implementation, so teams can plan, delegate, and review work with fewer surprises.
Lower risk
Permissions, failures, system access, and success criteria are explicit.
Parallel work
Separate feature boundaries reduce overlap and merge conflicts.
Easier review
Reviewers compare a focused change against a visible contract.
Preserved knowledge
Important rules live with the feature instead of only in people’s memory.
Safer change
Technology can evolve behind stable capabilities without rewriting behavior.
Human + AI implementation
People set direction. AI accelerates bounded work.
The contract is the handoff. It gives AI enough context to help while keeping human judgment in control of customer value, policy, and architectural decisions.
Human responsibility
Purpose and judgment
- Choose the customer outcome
- Define business rules and risk
- Review experience and tradeoffs
- Approve architectural change
AI contribution
Speed and consistency
- Implement within the contract
- Build backend and frontend pieces
- Write focused tests
- Explain the completed change
Shared brief→Bounded implementation→Automated checks→Human review
A real product, not a toy example
Focusly shows the business idea in working software.
People can manage tasks while AI proposes useful plans. Both use the same approved product operations, so speed does not come at the cost of control.
- Human + AI workflows
- Reviewable AI actions
- Shared business rules
- Automated safety checks
MY WORKSPACETasks
Todo 3
Prepare launch briefWork · High
Review AI suggestionsPlanning · Medium
In progress 2
Map feature contractsWork · High
Completed 4
Connect local AISetup · Done
Technical details
Now, see how the architecture creates those outcomes.
One feature contract connects business intent, backend behavior, frontend UI, and verification.
The model
Product behavior in one bounded slice.
The definition states what a feature is allowed to know and do. Discovery connects it to the application. The runtime enforces the boundary.
-
01
Declare
Define business intent, schemas, failures, capabilities, security, and UI slots.
-
02
Discover
Load backend routes, MCP tools, and frontend contributions from local manifests.
-
03
Execute
Run feature logic with validated input and only its explicitly granted capabilities.
-
04
Verify
Enforce schemas, imports, dependency graphs, boundaries, and behavior in CI.
Feature anatomy
Everything needed to understand one capability.
Backend behavior and frontend affordance stay close without collapsing their boundaries. Each file has one visible architectural job.
Open an implemented feature◆ create-task/
◇ feature.definition.json
planning contract
◇ manifest.ts executable binding
◇ contracts/ input + output schemas
◇ backend/ feature behavior
◇ frontend/ slot contribution + hook
◇ IMPLEMENTATION_PLAN.md
acceptance guide
One feature, two surfaces
Clear on the backend. Composable on the frontend.
Runtime boundary
Backend
HTTP routes and MCP tools invoke the same discovered feature, so browser users and AI clients follow identical product rules.
- 01 Authenticate actor
- 02 Validate schema + authorization
- 03 Execute with granted capabilities
- 04 Commit data + audit + outbox
No database, HTTP, environment, or provider imports in features.
Composition boundary
Frontend
The React shell owns typed slots and shared runtime services. Features contribute UI without reaching into each other or the shell.
- 01 Discover frontend manifest
- 02 Register typed slot contribution
- 03 Call feature through local hook
- 04 Invalidate semantic cache tags
No feature-to-feature component imports or refresh commands.
Short code examples
One idea, expressed at each boundary.
These shortened examples come from Focusly’s Create Task feature. The business need stays recognizable all the way from declaration to UI.
Declare
The contract
{
"name": "create-task",
"capabilities": [
"TaskCreate",
"ClockNow"
],
"slots": ["TaskComposer"]
}States what the feature may do and where it appears.
Backend
The behavior
async execute(context) {
const task = await
context.capabilities.TaskCreate({
task: {
title: context.input.title,
status: "Todo"
}
});
return context.ok({ task });
}Uses only the system operations granted by the runtime.
Frontend
The contribution
export const contribution = {
slot: "TaskComposer",
name: "create-task-form",
render: () => <CreateTaskForm />
};Adds feature-owned UI without editing a central screen.
Choose your path
From idea to implementation.
Start with the overview, inspect the working app, then use the detailed contract when contributing.
01
Project overview
What AIFA is, why it exists, and how to navigate the repository.
Read README → 02Architecture guide
The feature, runtime, backend, frontend, and dependency model.
Understand AIFA → 03Implementation architecture
The authoritative security, data, composition, and quality rules.
Go deeper → 04Ticket contract
How to specify a feature so it can be safely implemented and verified.
Write a feature →Run the example
See the boundaries in working code.
Clone the repository, enter the demo, and start Focusly locally.
$ cd demo/ai-todo-assistant
$ npm install
$ cp .env.example .env
$ docker compose up -d
$ npm run dev