Models
The store editor
Turns an instruction in the operator's own words into a proposed change with a cited reason, a rejected alternative, and a reversibility flag.
A product surface, not a published identifier. It runs on the shared inference path and carries no identifier of its own.
What it is for
The store editor generates a complete storefront for a claimed product and can regenerate it, reorder its sections, or apply a stated edit. It runs on the same inference path as the commerce engine, in a workspace scoped to one account, but it carries no published engine identifier of its own.
Its unit of work is an intent, not a pixel. The operator says what they want changed; the editor proposes an execution and shows its reasoning before anything is applied.
What it can do
Section order with a stated reason
A generated page is a sequence of sections, and that sequence is a claim about what the buyer needs first. The engine emits both the order and an order rationale: one entry per section saying why it sits where it does. A section that cannot cite the evidence row justifying its position does not ship, which is a build gate rather than a guideline.
One named mapping from evidence to section
Evidence legs map to sections through a single table, so the proposer and the applier cannot disagree about what a leg means. An urgency row leads to a why-now section, a scarcity row to availability, price evidence to the comparison block, customer questions to the FAQ.
Nothing applies until accepted
A proposal cites the dated row that justifies it, names the alternative it rejected and why, and marks whether the change can be put back. It is created with an empty applied-at field by construction, so an unaccepted proposal cannot be mistaken for a change.
Reversibility is a real property
Section order, dashboard layout, support tone and ad creative can be reverted, because applying one records the previous state. Anything that spends money or reaches the outside world is not reversible, and says so before it happens rather than after.
The inference path
| Property | Value |
|---|---|
| Runtime | Codex CLI, one ephemeral session per request |
| Model | gpt-5.5 |
| Reasoning effort | medium |
| Sandbox | read-only by default; workspace-write only where an edit is being applied |
| Isolation | The caller supplies an already-authorised account workspace as the working directory. No session state is shared between founders, and workspace-write never extends above that directory. |
| Pinned flags | exec --ephemeral --ignore-user-config --skip-git-repo-check --output-last-message |
The session is ephemeral and ignores any user configuration on the host, so a response cannot be shaped by state left behind on the machine. A refusal from the runtime is read out of its own event stream and passed through in its own words: an account out of credits reports that, rather than a generic failure the operator can do nothing about.
How it is measured
Not covered by commerce-v1. The benchmark scores final messages from the commerce engine; the editor produces file changes and proposals, which that rubric cannot read.
Because no recorded run exercises this surface, this page states no measurement of it at all. The benchmark and its system cards are published under research; they describe commerce-reasoning-v1 and nothing else.
Its limits
- An instruction no dated row supports is refused by name — we would be guessing at your buyer — rather than executed on the engine's taste.
- A refusal that comes from the underlying runtime is passed through in the runtime's own words. An account out of credits is told that, not told that the change could not be made.
- The editor writes inside one account's workspace and nowhere above it. Session state is never shared between founders.
- commerce-v1 does not exercise this surface.
Where these facts come from
Each line names a file in the implementation. The descriptions on this page are a transcription of those files and are marked provisional at their source until they have been checked against it again.
- The inference path and its refusal handling — flowfinds-ai-tool/backend/codex_cli.py
- Capabilities implemented today — flowfinds-ai-tool/PRODUCT-MAP.md
The others
- commerce-reasoning-v1 — The decision engine an operator talks to: it investigates a question with application tools before it answers, and it names the evidence it used.
- The find engine — Scores a candidate product on three independently sourced legs, and refuses to average them into one comfortable number.
- The organic research engine — Researches an audience per platform and produces a framing brief. It has no posting function, and no credential it could post with.
- The support agent — Answers a customer from one product's own record, and is scanned on the way out for the things it must never say.
Back to all models, or read what the engine is used for under the product.