Frequently Asked Questions

Embedded Semantics is a registry-backed multilingual semantic representation system. Its current production resolver maps reviewed exact expressions to stable concept identifiers; model-backed semantic generalization remains experimental.

Use it when important meaning must cross a language, application, memory, event, workflow, or audit boundary. A resolved ConceptCode gives participating systems one inspectable reference while the original expression and registry version remain available as evidence.

It is most useful at durable semantic boundaries: writing long-term agent memory, emitting shared API or event records, supplying semantic input to separately authorized routing, requesting clarification for ambiguity, and preserving auditable provenance. It is not necessary for every conversational turn.

Keep the original text, but add a resolved ConceptCode when governed evidence supports one. Text preserves the person's wording; the ConceptCode provides a stable cross-language reference; registryVersion makes cached evidence inspectable. None of those fields should replace the others.

Measure wrong-assignment prevention, cross-system consistency, useful clarification, provenance completeness, and reduction of duplicate local categories. Do not optimize for resolution rate alone because an explicit unknown or ambiguous result is safer than a wrong accepted identity.

Choose exactly one canonical recipe and run the dependency-free integration-readiness self-test. It exercises valid resolved, unknown, ambiguous, malformed resolved, request-error, and service-error fixtures locally. Only valid resolved may receive ConceptCode and registryVersion; every other fixture must retain evidence with no identity assignment. The report performs no side effect and does not grant authorization.

No. Stable concept identifiers, definitions, reviewed expression evidence, and registry records are authoritative. Embedding vectors are model-version-specific evidence and do not define concept identity.

Not through the current production path. If an expression is not already reviewed into the registry, the exact resolver abstains with unknown_expression unless a separately validated semantic runtime is configured in the future.

Reviewed expressions in different languages can map to the same stable ConceptCode. Language expressions are evidence for that identity, so the public concept identifier remains unchanged across languages.

Hard negatives are closely related but incorrect concepts used to test whether retrieval can distinguish semantic neighbors instead of merely grouping content from the same topic.

It abstains rather than guessing. Unknown reviewed-expression lookups return unknown_expression, and exact expressions that legitimately map to more than one concept return ambiguous_expression. A future model-backed lane will require separately validated confidence calibration before production use.

Send one exact expression in the expression field and, only when known, an optional valid BCP 47 language tag. Do not send credentials, hidden prompts, the whole conversation, or unrelated private context.

No. HTTP 200 means the request was processed. Accept identity only when data.status is resolved and data.concept.code is a non-empty string. Every abstained response means no ConceptCode assignment.

For unknown_expression, say that no reviewed registry identity was found and preserve unknown. For ambiguous_expression, say that more context is needed and ask a clarifying question. The agent must not silently choose a likely code.

No. A ConceptCode identifies governed semantic meaning only. Permission to publish, spend funds, invoke tools, change data, or affect another system must be decided by a separate authorization policy.