#Concepts

Flezise is built around a small set of concepts that work together to take a piece of software from an idea to a shipped change. Understanding how they relate makes every screen easier to read, whether you are approving a product brief, watching a run, or clearing your board.

#The basics

#Projects

A project is one piece of software and everything Flezise knows about it: the documents, the people, the work in flight, and the runs that produced it. Everything else on this page lives inside a project.

Each project has a slug that appears in every URL (/projects/signaldesk-demo/...), a pipeline that decides which documents get produced in which order, and its own settings for approvals, model routing and integrations.

Read more on creating a project.

#Artifacts

Artifacts are the documents a project produces and approves: the product brief, the PRD, the high-level design, UI designs, specs, test plans, and anything you upload. Each has a type, sits in a phase, and moves through a status lifecycle from draft to approved.

Artifacts are where most decisions in Flezise get made. A builder agent drafts one, a verifier agent reviews it, people approve it, and only then does the pipeline build on it. Every artifact carries a display ID such as PRD-001 next to its UUID, and either works in a URL or a CLI command.

Read more on artifacts.

#Phases

A phase is where a document sits in the delivery sequence. The pipeline sorts by this order:

1. analysis
2. planning
3. solutioning
4. implementation
5. testing
6. deployment

Blueprints can add phases of their own (assessment, discovery, strategy, requirements), so read a project's pipeline instead of assuming the list. A project's card on the home screen shows how far its documents have got, phase by phase, counted from their statuses.

#Statuses and versions

The API and the CLI use the underlying values: draft, in_review, changes_requested (shown as Revise), approved, superseded.

Every artifact has numbered versions. Approval freezes the current one; editing an approved document, rejecting it, or pressing New Version starts the next. Older versions stay in the history, and Restore brings one back.

Read more on review and approval and versions.

#Approvals

Each artifact type has an approval policy: who signs it, and in how many levels. Only the current level's approvers can act, plus members of the Project Admin group at any level they have not already voted at. A level that resolved to no eligible approvers is open, so anyone with approve permission can act and a short-staffed project never deadlocks.

Two things block an approval before the level rules are even checked: unresolved review findings, and design requirements that have not been sent to the PRD. Whatever the reason, it is the tooltip on the disabled Approve button.

#Work items

A work item is a task for an agent or a person: a bug from Jira, a ticket someone created on the board, a finding from the repository scan, or the implementation of an approved spec. Work items have their own states, from intake to done, and the board is the day-to-day view of them. Each carries a display ID such as WI-042.

Before an agent executes a work item it proposes a plan, and someone approves that plan first. That approval is the gate between thinking and doing.

Read more on the board.

#Runs

A run is one dispatch of the pipeline: a generation job that drafts one document, or an implementation job that turns an approved spec into a branch. A run records what was dispatched, by which trigger, how it ended, and the evidence collected on the way. Its status is one of dispatched, started, succeeded, failed and dead_letter.

In practice, the run list is where you go when something did not happen: a document that never arrived, an implementation that stopped.

Read more on runs.

#Around the work

#Knowledge base

The knowledge base is what agents and people search when they need context: approved artifacts, uploaded documents, and the as-is pages generated from an existing codebase once they are approved. Drafts stay out of it, so an agent never builds on something nobody signed off.

Read more on the knowledge base.

#Agents

Two kinds of agent work inside a project. Builder agents draft what the pipeline asks for: documents, designs, and the implementation of an approved spec. A verifier agent reads every draft before people do and records findings the builder has to resolve. On screen, the builder signs its work as Atlas and the verifier's findings are labelled Argus.

Atlas is also the assistant in every screen. It reports status, tells you what is waiting on you, explains why something is blocked, and acts on your behalf after you confirm, with every action audited. Approval gates on documents stay with people.

Read more on the assistant.

#How these concepts fit together

The way to think about Flezise is:

• a project holds everything about one piece of software
• artifacts carry the decisions; phases order them, statuses and approvals gate them
• work items carry the execution, and a plan is approved before an agent acts
• runs are the record of what the pipeline did and the evidence it left
• the knowledge base is what everyone, agents included, reads from

#Next steps

• Create a project
• Artifacts: types, prefixes and the list page.
• Pipeline editor: how generation is wired.