Read the explanation
The reuse map sends each requirement and all eleven capability descriptions into one local feature extraction batch. The three bundled requirements therefore produce fourteen text vectors. The catalog is not pre-indexed: the code re-embeds its descriptions on each run, with mean pooling and normalization. The page requests a local Mini L M model and disallows remote model files, but its runtime and WebAssembly dependencies still require external resources. Our offline checks do not load or verify that model. The function named cosine is a dot product. It acts as cosine similarity because the pipeline asks for normalized vectors. An illustrative two dimensional requirement vector one comma zero, compared with a normalized candidate point six comma point eight, gives similarity point six. That is an example of the arithmetic, not a computed output of the page model. Similarity ranks semantic candidates; it does not mean sixty percent feasibility, confidence, or production readiness. For every requirement, the code sorts all eleven similarities and displays the first two. Three requirements therefore show six match rows. Its reuse set contains only each requirement first ranked capability, removing duplicates. In this illustrative diagram, two first choices are X and one is Y, so reuse count is two. Second-ranked choices do not contribute to that count. The number describes repeated retrieved labels, not a proven reusable implementation. Input validation accepts one to six nonempty lines with at least eighteen characters each. Character length does not prove that the requirement has an observable outcome. A valid input proceeds to runtime loading, local embedding, and ranking, while a loading failure returns an error without creating a result. Export requires a completed result and includes the original requirements and rankings. Feasibility, cost, latency, security, and real user evaluation remain separate from this retrieval exercise.