Embedder.dimension is declared and never read

What happens¶

Embedder.dimension is an abstract property on the port, implemented by both embedders, and read nowhere outside platform/embedding. Nothing in documents, indexing, persistence or the entry points asks an embedder how wide its vectors are — the storage layer does not need to know, because Embedding.to_bytes/from_bytes handle any width and the columns are BLOBs.

Why the fastembed adapter pays for it¶

FastEmbedEmbedder cannot answer the question until it has embedded something, so it holds _DEFAULT_DIMENSION = 384 as a starting value and overwrites it on the first embed() call. That is a self-correcting field standing in for an answer the library already has: fastembed exposes get_embedding_size(model_name), which needs no inference pass.

So the property is wrong until first use, and nobody notices, because nobody reads it.

Why it was left alone¶

Found while surveying issue-a24f404dd106 and deliberately not fixed there: removing a member from a port touches every implementation, and that issue was about a corpus nobody could retrieve. Nothing depends on the answer either way, which is exactly why it is a cleanup rather than a defect.

How it was resolved¶

Deleted, not wired. Embedder.dimension is gone from the port and from both implementations, along with the fastembed adapter's _DEFAULT_DIMENSION and the self._dimension = len(values) assignment that kept it honest.

An unread property is not an interface. Wiring it to get_embedding_size() would have made it correct before first use, for a caller that does not exist — and left the port carrying a claim about vector shape that nothing in the system needs, since storage is width-agnostic and the one place two widths could disagree is checked inside Embedding where both are in hand.

What the deterministic embedder kept¶

The deterministic embedder keeps its dimension constructor argument: that one is read, by the hashing itself and by model_id, so two configurations cannot share a vector namespace. Only the public accessor went. test_the_configured_width_reaches_the_vector_and_the_model_id now asserts the width through the vector and the id rather than through an accessor — the two things it still has to do.

Left undecided on purpose: whether docir self status should report the vector width beside the model name. It was the one plausible caller and it is still speculative — the width is knowable from the model, and nobody has asked.