Capability
Generation Is Not Approval, and Approval Is Not Release
Draft, review, approval, and release are four separate states reached by three separate human decisions, each recorded with a name, a time, and a reason.
The Question This Answers
Who decides what gets published, and how is that recorded?
The separation of these states is the single most consequential design decision in GearDock. Collapsing any two of them removes a checkpoint that cannot be recovered later.
Four States
| State | What it means | Who moves it forward |
|---|---|---|
| Draft | Generated or edited. Carries no authority. | Anyone with catalog access |
| In review | Being read against its evidence. | A reviewer |
| Approved | A person judged this version acceptable. | A reviewer with approval rights |
| Released | Eligible to leave the system. | A person with release rights |
The Review Screen
Evidence sits beside the draft, because review speed depends almost entirely on whether the reviewer has to go looking for the source. Claim Firewall findings appear with the content, so flagged statements are visible rather than discovered.
Rejection Reasons Are the Valuable Output
A recurring rejection reason usually points at a bad source, an unresolved matching problem, or a category that generation handles poorly. Fixing that cause is worth considerably more than fixing one product, which is why rejections are recorded with a rationale rather than as a simple state change.
Why Release Is Separate
Boundaries
What This Does Not Do
Stated plainly, because knowing the edges of a capability is more useful than another list of benefits.
- GearDock never approves its own drafts, and no setting changes that.
- Release is a per-item decision, not a bulk toggle.
- Approval alone does not make content exportable. Release is required, and it is checked again when the export runs.
- Recorded decisions cannot be edited or deleted; corrections are new events.
In Sequence
What Comes Before and After
Each capability hands something specific to the next. Following the chain is usually more useful than reading them in isolation.
Questions
Common Questions
Can one person both approve and release?
That depends on the roles your organization assigns. Reviewing, approving, and releasing are distinct capabilities, so they can be held by different people or by the same person depending on how you configure access.
What happens to content that is rejected?
It returns to draft with the rationale attached, and the rejected version stays in the product's history. Nothing is deleted.
Private Beta
See This Working on Your Catalog
Capability pages describe the mechanism. A working session on your own products shows you how it behaves with your data, which is a more useful basis for a decision.