What Flows just did
Based on your request to build MongoDB Data Model Plan, Flows created 5 implementation stages and 15 checks.
You asked for: Produce a query-driven MongoDB model: collections, embed/reference decisions, indexes, and validation.. Flows generated 5 stages because the application requires Access patterns listed before modeling; Embed vs reference decided per relationship with reasoning; Indexes matched to the query patterns. Each stage tells your AI builder what to do, tests whether it actually worked, and gives a repair instruction when it fails. These checks are designed to catch: Modeling like SQL with joins everywhere; Unbounded arrays that grow forever inside documents; No indexes, causing collection scans on every list.
Example failure
The form reported success, but no database record was created.
What Flows does
Flows detects the failure, generates a repair instruction, reruns the test, and stores the passing evidence.
Stages — Plan → Build → Test → Fix → Prove → Ship
5 stages · 15 checks · progressive disclosure — open a stage for details
Copy to external builder
Copies a prompt for Claude/Cursor/etc. Records prompt_copied only — not execution, commits, or checks.
Execute through Oort
Requires Sign in with Oort + a provider connection (BYOK). Keys stay on Oort. A model name in the dropdown is not the same as a live connection.
Next
Check off: Every screen's data needs appear
Add a proof note on each check — a checkbox alone is weak proof.
Probes & advanced tools are under “More verification tools”. Experience level: Settings.
Project (saved with proof)
Project binding: Unbound — complete project binding before trusting this run · missing repositoryUrl, repositoryStartCommit, environment, stack
More verification tools (probes, timeline, adapters)Show
App persistence (create → read → assert token)
Body template: {"probe":"{{token}}","title":"flows-probe-{{token}}"}. Needs CORS-readable public create/list endpoints (or inconclusive). Badge only when create→read→refresh finds the token (detects false success).
Two-account authorization (User B cannot see/change User A)
Authorization evidence source: Cross-account ownership test (trust level 5/6). These are not equivalent. Unauthenticated probe alone is weaker (source: unauthenticated API probe). Tokens stay in this browser session only — not uploaded to Flows servers.
Generated edge-case tests (review / approve)
- cross_account_probe User B cannot see or change User A’s data
- cross_account_probe Participant cannot call coach/admin endpoints
- cross_account_probe URL/body ID tampering cannot cross tenant boundary
- api_probe Create then refresh still shows the record
- api_probe Edit then refresh keeps the edit
- api_probe Delete then refresh removes the record
- api_probe Nonexistent record ID fails cleanly
- cross_account_probe Cross-user record identifier is rejected
Generated from this route’s signals — you approve; you do not invent security tests.
Content probe (GET body contains text)
In-product content probe reads response text when CORS allows — not full DOM/click automation. Playwright script is optional and external.
Proof strength
thin · 0/100
Heuristic from notes + probes + gates — not a production certification.
Verification adapters
- ● Deploy URL probe · idle
- ● API path probe · idle
- ● Authz probe (unauth → 401/403) · idle
- ● Browser persistence · idle
- ● App persistence (create→read) · idle
- ● Content / body text probe · idle
- ○ In-product Playwright DOM · not embedded (download external script)
Filled circles = available here. Empty = not shipped. Probes are not a production audit. Adapter docs
Step 1 of 5
Not startedList the access patterns
MongoDB models are chosen by queries - enumerate them first.
Flows keeps plan, checks, failures, and next steps connected
Your AI tool writes or changes the code
Repository grounds the plan only after inspect
Checks always carry a validation tier
How this plan was created
Plan from project details
Flows creates steps using the goal, requirements, stack, platform, and details you provide.
- Project description
- Selected template / route
- User-entered stack
- Constraints and notes
- MongoDB Data Model Plan
No repository inspection implied. Connect and inspect a codebase to ground steps in real files.
Codebase access
Checking GitHub…
Or paste a repository URL manually
Use these instructions in Claude, ChatGPT, Cursor, Emergent, or another builder.
List my app's data access patterns. I will describe the app below. Produce a table: every read pattern (what screen/feature, what it fetches, how filtered/sorted, expected volume) and every write pattern (what creates/updates what, how often). Rank by frequency. These patterns - not entity purity - will drive the model. MY APP: [describe here]
Project context
Copies the project goal, technical details, current step, previous progress, and checks so your AI tool understands what it is working on.
Expected after this step
A ranked table of all read and write patterns.
Should not happen
- ✕Modeling like SQL with joins everywhere
- ✕Unbounded arrays that grow forever inside documents
- ✕No indexes, causing collection scans on every list
- ✕No ownership field, making user scoping impossible
Verify gate — prove this step works before continuing
Do not move on until every check is true. Add proof notes — a checked box alone is weak proof. Checks are manual by default; deploy/API probes live under “More verification tools” and do not auto-check boxes.
Do not continue if…
- !Modeling like SQL with joins everywhere
- !Unbounded arrays that grow forever inside documents
- !No indexes, causing collection scans on every list
- !No ownership field, making user scoping impossible
Repair path — if this step fails
Use the Repair Prompt when a verify gate fails. Loop: Detected → Diagnosed → Repair issued → Changed → Retested → Resolved
Show repair prompt textShow
The patterns are vague. For each screen write the exact question the database must answer ('newest 20 items for user X where status=active').
Your notes for this step
Definition of Done
Final route-level requirements. Manual checks — separate from per-step verify gates. Completing step gates does not auto-check these. Route completion is not a production-ready claim.