Custom Lens Design Review: The Evidence Package to Demand

Your first custom lens deserves a strange sentence before anyone machines a single part: the design is not finished when the simulation looks good, it is finished when the evidence survives a review you can actually run. Before the maker cuts metal, require five things on paper: a requirements traceability matrix, nominal performance at your own conditions, a tolerance table in which every line names its inspection method, worst-case corners that are physically credible, and an alignment plan that says who adjusts what at assembly. Ask for the pack as version-locked PDFs plus the model files that produced them, tied to a named gate in the project schedule. Then hold one more expectation that most buyers forget: the same numbers you approve at design review must reappear, measured, in the batch documents that ship with production lenses. A review you cannot trace into production paperwork is theater.

This article walks the path from feasibility answer to drawing freeze, itemizes the pack so you can judge each sheet in minutes, and shows what the evidence owes your production records. The intent is practical: an optics buyer with a calendar and a quality system, not a simulation lab, should be able to run this review and write down a defensible yes or no.

The evidence path from feasibility answer to drawing freeze

Evidence arrives in stages, and each stage buys the right to spend money on the next. Compress the stages and you pay for it later in change orders; stretch them and the launch date pays instead. A sane path looks like this:

1. Feasibility in writing. Send the RFQ, sign an NDA first if the maker prefers, and expect a first-pass feasibility answer within about 48 hours. The answer should restate your sensor format, working distance, field of view and band in the maker’s own words, flag the risks, and say whether the concept fits your envelope.
2. Quotation on measurable terms. Every bidder answers at named image heights with named conditions, so bids compare like with like.
3. Design review pack. Before metal moves, the maker delivers the pack itemized below and books time to walk you through it.
4. Comment closure and drawing freeze. Your review comments get answered in writing, the drawing gets a revision letter, and both sides sign the same version.
5. First article against the pack. The first parts are measured against exactly the evidence you reviewed, not against a friendlier summary written afterwards.

What the feasibility answer should already contain

A feasibility reply that says only “yes, we can do this” is not an answer. Look for restated inputs, an honest list of the hard parts, and any assumption the maker had to invent because your RFQ was silent. Those assumptions are where projects quietly derail months later, so force them into the open at the stage where changing them is free.

Where the review sits in the schedule

Put the design review on the project calendar as a gate with a date, an owner on your side and a named reviewer on the maker’s side. A review without a slot becomes a formality squeezed between other work, and unfocused reviews produce the two worst outcomes: rubber-stamping today and relitigating the design after parts exist.

The review pack, item by item

Six items cover the ground. Fewer means gaps; many more usually means the maker has bundled internal paperwork that no buyer can audit. Judge each sheet against what it must carry and what you are reading it for.

Evidence item	What it must carry	What you read it for
Requirements traceability matrix	Each requirement mapped to a metric, a condition set, a verification method and a limit	Nothing in your spec escaped; nothing extra crept in
Nominal performance report	Performance across your fields, wavelengths and working distance, not only on axis at best focus	The design meets the spec with margin, at your conditions
Tolerance table	Each parameter with its limit, its distribution and its named inspection method	Every number can be measured by somebody, with named equipment
Worst-case corner report	Credible adverse combinations, per-corner results and margins, stated pass or fail	The floor of performance is still above your line
Alignment and compensator plan	What is adjusted at assembly, in what order, with what measurement, and the residual after adjustment	The yield story rests on a procedure, not on luck
Batch documentation echo	The commitment that production batch reports will repeat the agreed parameters, conditions and judgments	Design evidence survives into the shipments you actually receive

The last row is the one buyers skip. A pack that never mentions how the design intent will be verified on production parts has described a prototype, not a product. Ask the maker to point at the exact report fields where each reviewed parameter will reappear.

Simulation output belongs in the pack as readable plots with values, not as screenshots stripped of axes. Field curvature and distortion plots like the ones below are exactly the sheets you should be able to read against your own specification:

Judging tolerances when you have no tolerance lab

Most lens buyers cannot recompute a Monte Carlo run, and they should not have to. Three reading habits catch most of the real problems without a single simulation on your desk.

Every tolerance names its inspection method

Go down the tolerance table and ask one question per line: who measures this, with what instrument, at which stage. A tolerance nobody can measure is a wish. The barrel and housing callouts should sit on a recognized dimensioning standard such as the ASME Y14.5 dimensioning and tolerancing standard, so that “within tolerance” means the same thing in both factories. Optical surface callouts follow the maker’s optical drawing practice; what you are checking is that the method column is never empty and never says “final inspection” alone.

Worst cases must be credible, not theatrical

A worst-case report that puts every parameter at its adverse limit simultaneously is easy to fail and safe to ignore, because that lens cannot exist. Credible corners group the errors that actually travel together: machining drifts one way, cement and cure behave as a pair, thermal effects follow your real temperature range. Ask the maker which variables were treated as correlated and why. The answer separates an engineer who understands the build from one who ran a software default.

The drawing and the model describe one lens

Pick three tolerances at random from the simulation and find each one on the drawing. Then reverse: pick three drawing callouts and find each in the analysis. Mismatches are the single most common defect in design evidence, and they are invisible in any single document. While you are at it, check that the lens-side data your housing team needs, such as principal point location and flange face squareness, appears in the pack, because your assembly tolerance budget consumes exactly that data.

What the simulation owes your batch documents

Design evidence that dies at the review table protected nothing. The pack should commit to what production paperwork will carry: for the parts this site builds, every production batch ships with test documentation covering the agreed family parameters, typically MTF, distortion, back focal length and depth of field, together with the batch number, the test conditions, the inspection coverage and an explicit pass or fail judgment. That is the standard here, and it is the standard worth writing into your order anywhere else.

Connect the two worlds explicitly. The nominal report predicted a distortion curve; the batch report should measure the same quantity under the same conditions and say pass or fail against the same limit. The first article is where prediction and measurement meet for the first time, and a first article gate that compares measured values against the reviewed pack catches drift while it is still cheap. When the maker later proposes any change, the reviewed pack is also what makes the change visible: a new revision means the evidence gets refreshed, not just the drawing.

The machine vision numbers generic advice skips

Astroscopy-grade evidence lists wavefront error and spot diagrams. Machine vision buyers should pull the conversation toward the numbers their line actually consumes. Resolution belongs at your image heights against your sensor’s Nyquist frequency, quoted as MTF at named spatial frequencies, because that is how a camera engineer converts the curve into a defect size on a part. Geometry belongs as distortion at the image heights your software measures, and the FA lens line here holds distortion below 0.05 percent with batch consistency demonstrated across runs of ten thousand pieces and more, which is what a written, batch-verifiable commitment looks like. Relative illumination matters if your algorithm compares brightness across the field. Working in the near infrared? Ask for the performance at your band, because visible-band glory does not transfer automatically.

None of this requires new physics. It requires the review pack to promise the numbers at the points in the field where your application lives, so the batch documents can keep the same promise later.

Schedule and cost: what evidence does to the calendar

Evidence costs time, and pretending otherwise produces reviews that get skipped. The honest accounting looks like this. Paper evidence is cheap: traceability matrices, tolerance tables and corner reports add days to engineering, not weeks, provided the maker runs them as standard practice rather than as a special study. Review rounds add calendar time proportional to how many people must comment, so cap the comment window and name one consolidator on your side. The prototype-to-mass-production commitment on this site is 60 working days as a standard written term, with repeat orders at 30 days, and a two-round review fits inside that envelope while a four-round review visibly does not. Payment rhythm interacts too: when terms are half in advance and half before shipment, put the review gate and the first article gate inside that rhythm, so the second payment lands after evidence you have actually accepted.

What you should refuse to pay extra for is the evidence itself. Analysis of a design the maker is about to build is part of building it. What you can expect to negotiate separately is depth: extra Monte Carlo studies, extra prototype legs, third-party measurement. Ask for the depth your risk deserves, not the depth a checklist recites.

How reviews actually fail

The pack exists; the meeting happens; the failure still arrives, usually in one of these forms:

• The rubber stamp. Comments are collected, softened into “noted”, and nothing changes. Fix it by requiring written dispositions: accepted, rejected with reason, or deferred with a date.
• Screenshots instead of data. A picture of a plot with no axis values cannot be audited later. Request the underlying tables for anything you plan to enforce.
• “Meets specification” without conditions. A performance claim without wavelengths, fields and focus state is decoration. The quotation comparison discipline applies inside the review too.
• Hidden compensators. The yield looks fine because the model quietly allows an adjustment your assembly line cannot perform. Read the alignment plan as a promise about your own floor, not the maker’s bench.
• Open comments carried into production. Unresolved items must either close or become accepted risks in writing, because otherwise they resurface as warranty arguments.

Every one of these has the same antidote: the review ends with a signed pack, a revision letter and a comment log with dispositions. That trio is what your future self will need when a production question reaches back to a design decision made months earlier.

Where this leaves your first custom lens

Require the evidence in stages, judge it with reading habits instead of a simulation lab, and bind it to the batch documents that follow the parts out the door. A maker who volunteers this pack, closes comments in writing and lets the first article be measured against the reviewed numbers is showing you how the whole program will run. If you are framing that first request, start from the custom optics overview, set the quotation against the discipline of numbers at named image heights, and plan the gate where the first article is measured against the frozen drawing. When a change arrives mid-program, the change freeze clause you signed is what keeps the reviewed pack from quietly expiring. Evidence is not overhead. It is the cheapest prototype you will ever build.

Written by Baker Zhao, Founder at Lensmind Optics