A workshop capability profile needs evidence, not a machine list

A workshop may own a capable machine and still be unable to take a particular job. The machine may be set up for different materials, the requested geometry may need tooling that is not available, the inspection method may not support the required acceptance check, or the workshop may not have capacity on the requested date.

That is why a machine list is useful for discovery but weak as a production promise.

Describe the work, not only the equipment

A capability profile should begin with the work the maker is prepared to perform. For each offered method, a maker can state:

• The product types or operations they support.
• The input forms and materials they have experience assessing.
• The dimensions, finish, or quality requirements they can evaluate, where documented.
• The normal setup, post-processing, and inspection steps.
• The information required to quote or assess a new job.
• The conditions that trigger a sample, proof, first article, or a decline.

Use “can assess” and “supported under these conditions” when an outcome has not yet been proven for the requested job. This is more useful than an unsupported range, tolerance, speed, capacity, or material-compatibility claim.

Link claims to test conditions

Capability is not a property of the machine alone. A credible claim connects the machine, the material or workpiece, the method, the setup, the measurement approach, and the observed result. When a maker has test evidence, the profile should retain enough context to understand what was actually tested.

For a small workshop, that could be a dated sample, the input identifier, the process notes, the inspection result, and the known boundary. It does not need to be a public technical report. It does need to be available to the maker when deciding whether a new request is within the evidence they have.

Make the unknowns visible

A capability profile earns trust when it says what is not yet established. Examples include a new material, an unfamiliar product geometry, a tighter acceptance requirement, a different software workflow, or a deadline that does not allow a proof. The right response may be to test, ask for more information, route the job to another capable maker, or decline it.