Projects

​

Overview

A Project is the durable home for an effort that’s too big for a single conversation — a simulation study, a multi-session model build, a planning rollout — anything where the work needs to survive across chats, produce artifacts you sign off on, and let anyone on the team pick it back up later without reconstructing the thread. Projects are how Dexter turns longer-running work into something you can revisit, audit, and hand off. Each project page shows an overview, a set of phases with the artifacts approved at each one, and a rolling “where things stand” cursor that says where the effort is right now.

​

Projects vs. Plain Conversations

Use a plain conversation for one-shot work: a quick data question, a chart, a small edit to an existing model, a report you need today. A plain conversation isn’t temporary — it’s saved to your history and the artifacts it produced stay in the factory, exactly like any other chat. What it lacks is a project’s phased artifact structure: the sequence of phases, the gated sign-offs, and the approved deliverables filed by phase into a durable, hand-off-ready record. Use a project when the work has any of these shapes:

• It will span multiple sessions.
• It produces a sequence of deliverables that build on each other, each needing your sign-off before the next.
• Someone other than the person driving today will need to resume it.
• You want a durable record of what was assumed, validated, and decided.

​

Where Projects Live

Projects is a top-level item in the left sidebar, alongside Chat, Knowledge Base, and Workflows. The Projects page lists every project in the current factory with its current phase and its latest update. When there are none, it shows: “No projects yet — When Dexter starts longer-running work for this factory, it will appear here with its current phase and latest update.” The Projects page itself has no “New project” button — you create a project from the project picker in the message composer (choose Create project), or Dexter opens one for you when the work warrants it, typically after you approve a review brief scoping the effort or when you pick up a workflow like a simulation study. Opening a project shows its overview, its phases, and the artifacts inside each phase.

​

The Project Overview

Opening a project shows an Overview and a “Where things stand” section at the top, above the phases and their artifacts. Together they name what the effort is, what decision it drives, which phase is current, what’s in flight, what’s blocked, what’s next, and what open questions are outstanding — so the next session (or the next person, once they’ve been sent a copy of the factory) can resume without reconstructing the thread. Dexter maintains these sections. You read them to see where things stand; if something is wrong or stale, tell Dexter and it will patch it in place. What you work with is the rendered Overview and Where things stand — Dexter keeps the project’s internal bookkeeping (its phase cursor and resume notes) in a behind-the-scenes file you never open or edit. That file isn’t one of the project’s deliverables: the artifacts you actually review and sign off on — starting with the charter in a simulation study — are separate, and are covered under Phases and Gates below.

​

Phases and Gates

A project is organized into phases — each one a gated unit of progress. A phase isn’t a calendar block; it’s the work behind a single point where you sign off before the next phase can build on it. At the end of each phase, Dexter presents a review brief — the decision, the evidence, the assumptions it rests on — as an approval card in chat. When you approve, the artifact the brief rests on lands in that phase’s folder and becomes part of the project’s user-visible record. The current phase then advances. In a simulation study, for instance, the first such artifact is the charter — the decision the model exists to drive and the bar it must clear — which you sign off before the model is built against it. The same gating applies to two other transitions: advancing the current phase, and closing the project. Both happen through a review brief you approve.

​

Drafts vs. Final Artifacts

Not everything Dexter produces during a phase is ready for you to see. It keeps in-progress work in a private drafts area inside the project — sketches, exploratory scripts, half-formed briefs. Drafts are not shown on the Projects page and are never cited in briefs. Once a draft is ready, Dexter presents it as a review brief. On approval, it moves into the phase’s folder as a final artifact — the version of record. Final artifacts are what teammates and future sessions see and rely on.

​

Bridging to Related Knowledge

Projects don’t live in isolation from what Dexter has already learned about your operation. Each project keeps a “see also” link back to the related entries in the Knowledge Base — process flow, data sources, and prior in-platform work relevant to this effort. When Dexter picks a project back up, it reads the project’s overview first to see where things stand, then follows those links to reorient itself in your operation before touching the work itself.

​

How Conversations Attach

At any moment, a conversation is either project-attached or loose:

• A loose conversation is a normal chat. Its work lands in the factory, not in a project.
• A project-attached conversation is scoped to one project. Dexter uses that project’s overview, phase artifacts, and bridge as context; work approved through the conversation lands in that project’s folder.

A conversation attaches to a project when Dexter opens or resumes one — either at your request (“pick up the sedan-line study”), or because the work you’re asking for is clearly the next step of an existing project. You can also attach it yourself: the project picker in the message composer shows the active project (or No project) and opens a menu of the factory’s projects — pick one to scope the current conversation to it, or choose No project to detach. Only one project is active per conversation; starting a new chat begins loose again.

​

Working Through a Project

A typical arc:

1. Kickoff. You ask Dexter to do something substantial. Dexter proposes running it as a project, drafts a scoping brief (the decision, the phases, the deliverables), and presents it for approval.
2. Project opens. On approval, the project appears on the Projects page with its overview, empty phases, and its bridge into the Knowledge Base.
3. Work in a phase. Dexter executes the current phase — asking questions, analyzing data, building artifacts — keeping in-progress work in drafts and posting updates as it goes.
4. Phase gate. Dexter presents a review brief for that phase’s deliverable. You approve, request changes, or ask questions. On approval, the artifact lands in the phase folder and the current phase advances.
5. Resume across sessions. In a later chat, you open the project or ask Dexter to pick it up. Dexter reads the project’s overview and the bridge and continues from where things stand.
6. Close. When the last phase’s deliverable is approved, Dexter presents a closing brief. On approval, the project moves to closed. It stays on the Projects page as a durable record, and you can still ask Dexter to reference or reopen it in a later chat.

​

Limits and Caveats

• No “New project” button on the Projects page. You start a project from the composer’s project picker (Create project), or Dexter opens one when the work warrants it.
• One project per conversation. Switching projects means starting a new chat, or asking Dexter to re-attach explicitly.
• The overview and phase artifacts are Dexter’s to author. You approve, request changes, and correct — you don’t edit them directly.
• Drafts stay hidden until approved. If you need visibility earlier, ask.
• Reports and other downloadable deliverables produced during a project attach to the project’s phase folders and are also accessible where they’d normally appear.