Running one product all the way through is the fastest way to understand GearDock, because each stage hands something specific to the next and the handoffs are where the design decisions live.
The Nine Stages
1. Import
A spreadsheet row becomes a candidate product record. Nothing is written to your catalog yet; the row is validated and held.
2. Match
The row is resolved to a specific product using its identifiers. High-confidence matches proceed; ambiguous ones wait for a person. This is the stage that determines whether everything after it is meaningful.
3. Attach Evidence
Source documents are linked to the product and processed so their contents can be cited rather than retyped.
4. Detect Gaps
GearDock compares what is known about the product against what a product of that type should carry, and reports what is missing, conflicting, or weakly supported.
5. Complete
Gaps that available evidence can fill are proposed with their supporting source. Gaps nothing supports stay visible as gaps.
6. Generate
Draft product content is written from the structured facts and their evidence: a title, a summary, a description, and specifications.
7. Review
A person reads the draft against the evidence and records approve, revise, or reject with a rationale. The Claim Firewall has already flagged statements it could not tie to evidence.
8. Release
A separate release decision marks approved content as eligible to leave the system. It is the last cheap point to change your mind.
9. Export
Released content is packaged as a file or sent to a connected destination. Release state is re-checked at this moment, not trusted from earlier.
Three Stages Require a Person
What You Will Notice on the First Run
- The gap report is longer than expected. This is the catalog telling you the truth about its coverage, usually for the first time.
- Products with an attached specification sheet finish dramatically faster than those without. Document coverage is the main throughput variable.
- Review is quick when the evidence is shown beside the draft and slow when it is not, which is why the review screen puts them together.
- The audit trail accumulates without anyone maintaining it, and becomes useful the first time something is questioned.
Then Scale It
Once a single product has been through the whole path, the same sequence runs in batches. The stages do not change; what changes is that exceptions are worked as queues grouped by cause, rather than one product at a time.
Teams that scale well tend to do one thing consistently: they treat a rising rejection rate at review as a signal about imports, matching, or document coverage, rather than as a backlog to push through.