A 3D foot scan record contains a surface, a set of dimensions and a file format; what it does not contain is an assessment. Buyers who treat the file as a conclusion end up ordering insoles from a shape without a brief, and the pair that arrives is a faithful reproduction of a description nobody wrote.
The phrase itself is a search term rather than a technical specification — buyers type it, listings use it, and the object behind it varies from a smartphone capture to a laboratory instrument. That variation is not a scandal; it is a reason to read the record for what it holds.
This article sets out what a surface file can and cannot tell a production team, how to read the record alongside a pressure measurement, and which fields have to be added before an order makes sense. We produce insoles, so the description follows what a factory needs to receive rather than what a scanner can output.
What the file actually is
A surface file is a mesh or a point set describing the outside of a foot in a stated position. It records shape: length, width, curvature, the line of the arch, the volume of the heel. It records that shape at one moment, under one loading condition, with one set of assumptions about how the foot was held.
The loading condition is the important part. A foot captured while non-weight-bearing has a different arch than the same foot standing. A foot captured standing has a different shape again from a foot mid-step. Files taken under different conditions describe different objects, and mixing them in one order produces inconsistent pairs.
The format matters for a different reason: it decides what the factory can do with the file. A closed format that only one program can open creates a dependency; an open mesh or point cloud can be imported into design software and checked. Ask for the export before the order, not after.
None of this makes the file less useful. It makes it a measurement rather than a verdict, which is exactly the right status for something that will be turned into an object.
It is worth knowing how the file was produced, because production methods differ in what they can capture. A structured-light capture, a photogrammetric capture and a pressure-based surface approximation all produce a surface, and they disagree about concavities, about the arch’s underside and about the spaces between toes.
What it cannot tell you
It cannot tell you how load is distributed. Shape describes geometry; pressure describes interaction. A foot with a high arch and a foot with a low arch can both load unevenly, and the file will not distinguish them.
It cannot tell you how the foot behaves in motion. A static surface is a snapshot; walking involves transitions that a shape cannot represent. Systems that infer dynamic behaviour from a static file are extrapolating.
It cannot tell you what the wearer needs. That is a decision made by a professional from a history, an examination and a conversation, and the file is one input among several.
And it cannot tell you what the shoe will allow. The file describes a foot, not a volume; the shoe’s depth, instep and toe box constrain the design more than the foot’s shape does in many cases.
A fourth thing it cannot tell you is what the previous pair did. A file describes the foot; the history of what was worn and how it performed is a separate record, and it is usually the more useful one when a design is being revised.
There is a fifth absence worth naming: pressure under the metatarsal heads. Surface files describe the plantar contour, and contour is a poor proxy for load where the tissue is thin. A design based on contour alone can miss the region that most needs redistributing.
Reading it alongside a pressure record
A pressure record and a surface file describe different things about the same foot, and together they answer a question neither answers alone: where the shape puts material, and where the load actually goes.
The practical reading is comparative. If the pressure record shows load concentrated medially and the surface shows a low arch region, the design brief is coherent — support the medial region and control the collapse. If the two disagree, the disagreement is the finding, and it is worth a conversation rather than an assumption.
This is why clinics that capture both tend to specify better. The specification stops being a description of a shape and becomes a description of a behaviour, which is what a factory can build and what a fitter can evaluate.
Our own systems combine pressure sensing with posture capture for the same reason: the value is in the combination, not in either layer alone.
It also helps to capture the shoe. A file of the foot plus the target shoe’s internal length and the removable footbed’s shape answers questions that neither alone can, and a factory receiving both spends less time on assumptions.
It is worth capturing the foot in the shoe it will be worn in, where the system allows it. A file taken in a thin sock and a file taken in a work boot describe different volumes, and the difference is often larger than the differences the design is trying to address.
From file to specification
A file becomes a specification when four fields are added: the design intent, the arch geometry in buildable terms, the shell stiffness family, and the footwear context. Without them, the factory chooses, and the factory’s choice is a library default.
The design intent is a sentence: support the medial arch during daily wear in a walking shoe, accommodate a prominent navicular, provide cushioning for long standing. One sentence, stated in behaviour terms, is enough to select the right default.
The arch geometry follows from the intent and from the file: height, width, apex position, blend. The file informs all four; the intent decides which direction to move them. A specification written from the file alone tends to reproduce the foot rather than to support it.
The footwear context closes the loop. A design that ignores the shoe’s volume fails for reasons the file cannot predict, which is why our specification sheet asks for the target shoe in the same box as the arch width.
The order of the four fields matters less than their presence, but the intent sentence should come first, because it decides which way the geometry moves. A specification that begins with geometry tends to reproduce the foot; one that begins with intent tends to change something.
It is worth keeping the shoe’s own file alongside the foot’s. A photograph of the footbed, its outline and its thickness are enough for a factory to check the volume, and they cost a minute at the fitting rather than a remake three weeks later.
Resolution, accuracy and the questions that matter
Resolution describes how finely the surface is sampled; accuracy describes how close the sampled surface is to the real one. Both appear in marketing and neither answers the question a buyer actually has, which is whether two files of the same foot taken on different days will describe the same object.
Repeatability is the property that matters. A system with modest resolution and high repeatability produces usable comparisons; a system with high resolution and poor repeatability produces detailed files that cannot be compared, which is worse for a production workflow.
Test repeatability before purchase: capture the same foot twice in one session with a repositioning in between, then compare the files. If the differences are small and explicable, the system is stable enough for production use.
Ask also about positioning aids — a reference plane, a heel stop, a defined stance. These unglamorous accessories are what convert a scanner into a measuring instrument, and they are usually the difference between a clinic that uses its file and one that does not.
It is also worth asking about the file’s units. A file exported in one unit and imported in another produces a pair that is close to right and wrong enough to be uncomfortable, and the error is invisible until the pair is worn.
It is worth asking whether the system reports its own confidence. A capture where part of the surface was inferred rather than measured is a capture with a caveat, and a system that flags the caveat is more trustworthy than one that hides it behind a smooth mesh.
It is also worth agreeing who checks the file before it is sent. A two-minute check for orientation, completeness and units prevents the class of error that is only discovered when a pair arrives and does not fit the shoe it was designed for.
Where the record goes next
In a production workflow the file travels through design software, where a shell is generated against the specification, and then to forming, finishing and checking. Each handover is a chance for context to be lost, which is why a naming convention and a field list attached to the file matter.
In a retail workflow the file may travel to a partner factory and back as a pair. The customer experience depends on the promised timescale, and the timescale depends on how quickly the specification is complete rather than on how quickly the scan was taken.
In a clinical workflow the file may stay in the record as a baseline, to be compared with a later capture. That use is often the most valuable, and it depends on the capture conditions being documented rather than remembered.
Wherever the file goes, it should travel with its conditions. A file without a capture state is an image; a file with one is a measurement, and only the second can be built from.
A naming convention belongs in the same paragraph. Client reference, date, foot and protocol in the filename turns a folder of files into an archive that can be searched, and the convention costs nothing to adopt.
The archive should also travel with the specification. A file plus a field list plus a sample date is a package that a factory can rebuild from; a file alone is a shape that invites reinterpretation every time it is sent.
It is worth testing the round trip before committing: capture a file, send it to the factory, and ask for a sample. What arrives tells you more about the workflow than any description of it, and it costs one sample rather than one batch.
A short checklist before ordering
One: is the loading condition stated, and is it consistent across the feet and across visits? Two: is the file exportable in a format the factory can open, and has that been tested? Three: is there a stated positioning protocol, and can two operators follow it?
Four: is there a pressure record or a pressure finding to sit alongside the shape? Five: has the design intent been written as one sentence in behaviour terms? Six: has the target footwear been named, including whether its footbed is removable?
Seven: is there an approved sample or a documented reference for the batch to be compared against? Eight: is there a remake clause? Both are short questions that decide whether a discrepancy can be discussed or only disputed.
Eight questions, ten minutes, and the file stops being a novelty and becomes the front end of a production process.
A ninth question, occasionally decisive: who owns the file? A clinic that has paid for a capture should expect to keep the file and to be able to send it to another supplier. If the file cannot leave the system, the clinic has rented a measurement rather than bought one.
It also helps to state who is responsible for the file at each end. A clinic sending a file and a factory receiving one both assume the other has checked it, and that assumption is where the preventable errors live. One line naming the checker is enough.
Frequently asked questions
What does a 3D foot scan record contain?
A surface description of the foot in a stated position, with dimensions and a file format. It describes shape at a moment; it is not an assessment and it does not describe load distribution.
Is a scan enough to order custom insoles?
No. A production order needs the file plus a design intent, the arch geometry in buildable terms, the shell stiffness family and the footwear context. Without those, the factory applies a default.
Why does the loading condition matter?
Because a non-weight-bearing foot and a standing foot have different shapes. Mixing conditions across a pair or across visits produces inconsistent records and inconsistent products.
What format should we ask for?
One that the factory can open without a proprietary viewer. Test the export before the order — a file you cannot open is a file you do not own.
Do your systems capture shape or pressure?
Our assessment systems capture pressure distribution and posture or alignment. Where a surface file is needed for a production order, we work from the file supplied with its capture conditions.
What is your minimum order for insoles?
Two hundred pairs, mixable across models and sizes, with samples shipping within three days.
Can a scan be repeated for comparison later?
Yes, if the positioning protocol and the capture conditions are documented. That documentation is what makes a later file comparable with an earlier one.
What we would do next
Before ordering from a file, add the four missing fields: intent, arch geometry, shell family, footwear context. The Insole Categories page shows what we produce, and Our Factory describes how a specification is reviewed before forming.
The article on arch geometry explains the four fields that turn a shape into a buildable specification.
This article is intended for professional and educational reference. It is not medical advice. Foot assessment equipment produces measurements and images; clinical interpretation and any decision about care remain the responsibility of a qualified professional. Certification scope is limited to the documentation we hold: European Union certification and ISO quality system certification.