Recommendation method / Planned
A frame direction, not a face-shape rule.
Mirae’s recommendation method is in development. It is intended to use visible proportions and frame geometry to organize exploration without reducing a person to a label. No accuracy or outcome claim is being made on this page.
01
The intended inputs
With permission, the planned experience is intended to consider visible relationships such as face length, cheekbone width, forehead, and jawline. These observations would form a temporary styling profile for comparison with eyewear shapes.
The method is not intended to infer identity, health, personality, ethnicity, attractiveness, prescription, or purchasing power. It is also not intended to decide a universal face-shape category and apply a fixed rule.
02
How the comparison is framed
The design direction is to compare the temporary styling profile with frame geometry and visual balance. Relevant frame characteristics may include overall silhouette and the visual relationship between the frame and the proportions visible in the camera view.
Because style is subjective, Mirae is being designed to show more than one reasonable direction. The explanation matters as much as the shortlist: users should be able to understand the visual reasoning and ignore it when it does not match their taste.
03
The planned output
The intended result is a small shortlist with plain-language context for each direction. The product should help a user move from an overwhelming catalog toward a few shapes, colors, or silhouettes worth comparing.
- A direction rather than a single winning frame.
- An explanation rather than an unexplained score.
- A starting point rather than a rule about appearance.
- A visual preview rather than proof of physical or optical fit.
04
Method limits and publication standard
The production model, thresholds, evaluation protocol, sample characteristics, observed error cases, and abstention behavior have not yet been published. Mirae should not make performance claims until those materials exist and can be reviewed alongside their limitations.
Before release, the public method documentation should describe the implemented version—not an aspiration—and distinguish measured behavior from product intent. Dated changes and known failure cases should remain visible as the method evolves.