How GenieForge works

A shared blueprint, isolated projects, and versioned change from real usage.

The loop

Stage	What happens
Brief	You describe who, journeys, and rules in Build
Assemble	GenieForge updates the shared blueprint
Operate	Each project runs that blueprint with its own database, files, and users
Observe	Signals, Feedback, Chats, and Executions show what really happened
Evolve	Back in Build: plans, versions, rollback
Remember	Build Rules and App Documentation keep intent across chats

App (blueprint): the recipe shared across every workspace of that app. One app can have many projects.
Project: an isolated runtime (its own data and files). Use one project per client, or staging vs live-style boundaries.

Building changes the recipe. Customer data stays in the project unless you deliberately seed or import it.

Imagine an inspection app:

Layer	What exists
Blueprint	How inspections are captured, who can do what, reminders
Project A (Acme)	Acme’s inspections, Acme’s users, Acme’s files
Project B (Beta Co)	Separate data and users; same product behavior from the blueprint

Acme never sees Beta’s rows. A blueprint change can roll out to both projects after you publish; each project’s history stays separate.

You want to…	Use
Change the app	Build mode
Ask about or operate live project data	Chat mode
See what a customer sees	Preview as that role
Get another model’s read-only take	Second opinion