Manufacturing Documentation Every Hardware Product Needs

Missing documents do not look missing on the first units. They look like questions. Each question is a delay, or a unit built to a private interpretation. The interpretation becomes "how we build it" until a second shift does something else and both shifts use the same revision name. Figures below are hypothetical teaching maths, not BrahmWorks prices, yields, timelines or test results. How this pack supports a real handoff is described in How to Take a Hardware Prototype to Production.

The bill of materials is the buying list. Each line has an identity a purchaser can order: a manufacturer and a manufacturer part number, or a specification tight enough to inspect on arrival. "Screw, M3" and "gasket, black" are not identities. Alternates are either qualified and listed, or absent. The bill's revision matches the assembly it belongs to. A bill that still contains a prototype substitute, unmarked, will be bought.

Drawings say which features matter and from which datum. They need the interfaces: mounting holes, seal lands, keep-outs, structural thicknesses, cosmetic faces, and a general tolerance the maker has accepted. They do not need every fillet. A STEP file alone lets every supplier invent those choices. Native CAD is not a controlled definition unless the configuration and revision on order are stated.

Materials and finishes live on the drawing or the bill, not in a sample chip that only one person can find. A colour that matters is a colour code or a limit sample with a revision. "Match the prototype" fails as soon as the prototype is lost or was never the production resin.

The assembly method is an order, a fastener table and the checks that happen before a joint is covered. Torques are numbers. "Secure the lid" is not an instruction. Photos help when they show orientation, and they harm when they contradict the drawing and nobody knows which wins. State the precedence: the revision-controlled drawing and the bill win. A photo is an aid.

The test method states the stimulus, the limit and the record. "Functional test" is a heading. A limit is a voltage, a leak rate, a click, a version the unit must report. Name the fixture if the result depends on it. A test run from memory is a performance, not a method.

If the product runs software, the binary or the configuration file has a version, a checksum or an equivalent identity, and the unit stores or is labelled with what it received. A laptop folder called "final" is not an identity. Programming instructions say what to load and how to confirm it. They also say what to do when the confirmation fails. Unprogrammed units must be impossible to pack by accident, or the pack step must check the identity.

Keep incoming inspection small enough to run and sharp enough to catch a substitution that would still build: a gasket durometer, a connector polarity, a housing from the wrong cavity. Leave the rest to the supplier's control, and say so. It is not a second copy of their process.

Packing is a drawing or a method: carton, insert, label fields, serial capture, what must be visible on the outside. A crushed product or a label with the wrong revision is a manufacturing defect even when the electronics were perfect. If accessories are in the box, they are on the bill and in the pack method.

One rule ties the set together. A change to a part, a torque, a test limit or a binary moves the revision that the other documents point at. You may use a simple scheme. You may not allow a mechanical change to ship under a test method that still describes the old seal. The point of control is not bureaucracy. It is the ability to say which definition a failed unit was built from.

At low quantity the pack can stay short. It cannot be replaced by attendance. Twenty units built while the designer watches are not documented by that presence. Write the order and the limits before the batch. Length is not the measure. Unambiguous revision is.

The teaching product is a sealed handheld logger. It is not a BrahmWorks product. The mechanical model is mature. The drawing says the lid is screwed down. The assembly note says "secure the lid". Two builders make a lot. One uses a clutch driver set hard, cracks two bosses, and backs the clutch off by feel. The other leaves the screws seated but below the torque that compresses the gasket. Both lots meet the note as written. A splash test, done only on the designer's own unit months earlier, is not in the pack at all.

Teaching correction, not an audit: the drawing gains a torque and a boss engagement. The method gains that torque, a cross-pattern, and a leak or pressure check with a limit. The bill names the screw length so a longer screw cannot be "secured" until it bottoms out. The splash result from the designer's unit is either repeated on this revision or deleted from any claim. The two lots already built are identified. They are not averaged into one population.

Hypothetical teaching maths. Not a time study and not a BrahmWorks result.

Assume each unit raises one question that takes 3 minutes of an engineer and 3 minutes of an assembler, because a note is ambiguous. Assume 40 units. Time = 40 × 6 minutes = 240 minutes = 4 hours. At an invented combined rate of INR 400 per hour, the questions cost 4 × 400 = INR 1,600. That sum is too small to motivate anyone, and it is the wrong sum.

Assume instead that the ambiguity ships, and that 6 of the 40 units are rebuilt after a failed leak check once a check finally exists. Assume 20 minutes of rework each. Rework = 6 × 20 = 120 minutes = 2 hours. Still a small number. The cost that matters is the units you cannot tell apart: half the lot may be under-torqued and already in a carton. If you then inspect all 40 at 5 minutes each, that is 200 minutes. The arithmetic stays modest on purpose. Ambiguous documentation is dangerous because its piece cost looks trivial, so it survives, while the effect is a lot you cannot disposition. Write the torque. The INR 1,600 was never the reason.

• Every fitted part is on the bill with an identity you can buy or inspect.
• The bill revision matches the assembly and the drawings.
• Drawings state datums, functional features, material and the general tolerance.
• Torques, adhesives and sequence are numbers and an order, not verbs.
• A covered joint has a check before it is covered.
• Test limits and the firmware identity are written, with the fail path.
• Incoming checks cover substitutions that would otherwise build and ship.
• Pack, label and serial capture are a method.
• One change moves every document that would otherwise lie about it.
• The designer's presence is not listed as a control.

No. Native files contain alternatives, suppressed features and no decision about which faces are critical. A supplier who has the file will choose. Give them a released configuration and a drawing of the features you will reject a part for. Keep the native file as the source of the next edit, under revision, not as the purchase order.

You need an unambiguous order. For a simple product that may be a page: orientation photos that agree with the model, a fastener table, two checks. A forty-page document that repeats the CAD without torques is worse than a short one that has them. Match the length to the decisions, not to a template from a larger company.

In the release record, on the unit or in a log tied to the serial number, and in the programming method that loaded it. Any one of those alone will drift. When a unit returns, you should be able to say what it ran without opening a laptop named after an employee. If the product has no software, say so in the pack so nobody "helps" by loading an unofficial build.

A revision-identified bill, a drawing with datums and the few requirements you will enforce, a one-page build and test method with limits, and a pack note. State who may change them. A controlled pack can be short. An uncontrolled folder of "latest" files is not a pack, however complete the geometry inside it looks.

Bring the bill, the drawings and the method you believe a stranger could follow. BrahmWorks can read them for the decisions that are still only in someone's head.

Review the next stage with BrahmWorks