Production Architecture for a Governed Embedded Semantics Runtime

Full report

On this page

Executive summary and public architecture baseline

Executive summary. The central architectural requirement is not merely “high-scale semantic search.” It is preservation of governed semantic identity under scale, failure, replication, model change, and partial connectivity. Embedded Semantics’ public architecture states this principle directly: reviewed multilingual expressions resolve to stable ConceptCodes; vectors are evidence rather than authority; the production path is deterministic reviewed-exact resolution; and unseen-query retrieval remains experimental. The project also treats unknown_expression and governed ambiguous_expression as legitimate outcomes rather than forcing a match.

As observed on August 23, 2026, there is an important distinction between that architectural contract and the currently deployed public registry. The status page reports zero published concepts, zero reviewed exact expressions, zero represented languages, zero active embedding profiles, and an inactive arbitrary-query semantic runtime, while also reporting a deterministic pre-release bootstrap bundle expected to contain 11 concepts and 55 expressions. Consequently, this report treats the website as authoritative about the semantic contract and intended resolution boundary, but does not infer an undocumented production database, source-code implementation, or current backend topology.

The production architecture I recommend is:

A strongly transactional governance control plane backed by relational SQL; immutable, signed, content-addressed registry releases as the unit of runtime consistency; region-local exact-expression read models for the authoritative resolver; asynchronous CQRS/CDC projections for search and analytics; and completely separate lexical/vector candidate infrastructure whose results can suggest existing concepts but can never manufacture, overwrite, or supersede governed semantic identity.

The deepest design decision is that authority is a property of provenance and governance, not of rank. A result is authoritative because an approved registry release says that a reviewed expression is governed evidence for a particular stable ConceptCode, not because an ANN search produced cosine similarity 0.94. The project’s own methodology makes the same distinction: the research objective may use similarity to find candidate concepts, but topic similarity is not semantic identity, model-backed generalization must preserve abstention, and model profiles/evaluation outcomes are tracked independently from stable ConceptCode identity.

This leads to three physically and operationally distinct planes:

This is also the safest way to scale. Ten million concepts and even one billion expressions do not require a globally synchronous database lookup on every request. The high-QPS data plane can execute against immutable regional or local read models, while the much lower-write-rate governance plane receives the stronger transactional machinery.

Answers to the key questions.

The strongest architectural rule should therefore be encoded as an invariant, not as a convention:

authoritative_resolution(request) :=
    a ConceptCode only when the active governed registry projection
    contains sufficient reviewed exact evidence under the active
    matching policy.

ANN_score, embedding_similarity, reranker_score, language_model_score :=
    NEVER sufficient authority by themselves.

That invariant is consistent with the public site’s current reviewed_exact_registry_first production mode and explicit separation between stable ConceptCode authority and embedding evidence.

Workload, authority, and data models

Workload assumptions. The requested future scale should be treated as several different workloads rather than a single database workload. Ten million concepts are moderately large structured reference data. One billion expressions are the dominant cardinality. Thousands of runtime requests per second are predominantly reads. Governance/review writes are likely many orders of magnitude lower than resolution reads, whereas raw expression observations may arrive as a high-volume event stream. Candidate vector queries have fundamentally different CPU, memory, accelerator, and latency characteristics from exact resolution. The architecture should therefore resist putting all of these workloads into one distributed datastore.

A useful capacity envelope is to design the public exact resolver initially for roughly 5,000 sustained requests/s per global service, 10× burst headroom, and horizontal regional growth, while making the read model independently sharded so 50,000–100,000 requests/s is an ordinary partitioning exercise rather than a database redesign. These are recommended engineering envelopes, not observations about the current site.

The phrase “one billion reviewed/observed expressions” also hides a critical distinction. Observed does not mean governed. Raw phrases seen in traffic, model experiments, imports, or customer corpora should enter an observation pipeline, not immediately become authoritative registry rows. Only after a governance workflow turns an observation into reviewed evidence should it participate in authoritative resolution. This follows the public project’s explicit emphasis on reviewed evidence, provenance, equivalence, and abstention.

I would explicitly model four states:

OBSERVED
    ↓ review / provenance collection
PROPOSED
    ↓ approved semantic assertion
REVIEWED
    ↓ release publication
PUBLISHED_IN_RELEASE

A rejected or merely observed expression remains useful for evaluation, hard-negative mining, demand analysis, and candidate retrieval but is not authority.

Authoritative-data model. A relational source of truth should separate the expression form from the semantic assertion about that form. This matters because the same visible expression may be an intentional ambiguity between two concepts; forcing one concept_id column onto an expression row would make governed ambiguity awkward or impossible.

A production logical schema should resemble:

The public project says ConceptCode and its registry definition are authoritative while expressions, embeddings, scores, prototypes and model metadata are attached evidence; it also states that definitions, expressions, relationships, model profiles and evaluation outcomes are independently trackable. The schema above deliberately preserves those boundaries.

The key database constraints should include immutable uniqueness of (authority_id, concept_code), unique revision identities, foreign-key integrity for every governed assertion, and a publish-time rule that every exact key mapping to multiple distinct active ConceptCodes must either have a valid reviewed ambiguity case or fail publication. Do not impose “one normalized expression equals one concept” as a database uniqueness constraint, because the public architecture explicitly supports ambiguous_expression.

Definitions and reviewed semantic assertions should normally be append/supersede/revoke, rather than edited destructively. ConceptCode remains stable; a new definition becomes a revision; a bad expression assertion is revoked with provenance rather than disappearing. That allows the system to explain why release R42 behaved differently from R43 without requiring full event sourcing.

The match_profile deserves first-class authority because changing text equivalence rules changes which input is allowed to resolve exactly. The profile cannot be an application-library implementation detail. A registry release should say, for example, that it uses exact-profile-v3, and all runtime implementations must reproduce that profile byte-for-byte.

Derived-data model. Everything that improves read speed but does not establish governance belongs downstream:

Authoritative SQL
   ├── exact-expression release projection
   ├── concept-by-ID projection
   ├── registry browser/search index
   ├── lexical candidate index
   ├── vector embeddings / prototypes
   ├── ANN indexes
   ├── offline registry packs
   ├── cache entries
   ├── analytics tables
   └── evaluation datasets / aggregate quality metrics

There is one important nuance: the exact expression map is derived computationally, but after it has been deterministically built, validated, hashed, signed, and referenced by a published registry manifest, it becomes a trusted runtime representation of registry authority. It is not an independent semantic source. A vector index never obtains that status, because its neighbors depend on a probabilistic/model-defined geometry rather than a governed equivalence assertion.

Raw observations should follow a different path:

Observation API
     ↓
durable stream
     ├── compressed object-store history
     ├── analytics / demand reports
     ├── candidate evaluation
     └── review queue ──► authoritative SQL only after governance

Kafka partitions are ordered append-only logs with offsets, making them well suited to high-volume event transport, while Debezium’s PostgreSQL connector can begin from a consistent snapshot and then emit committed row changes. The outbox pattern avoids the classic dual-write failure in which the database commit succeeds but event publication does not, or vice versa.

I recommend CQRS without full event sourcing. The command side is relational governance state plus append-only audit history. The query side is release-scoped materialized projections. Kafka/CDC is the propagation mechanism, not the ultimate semantic source of truth. This avoids making correctness depend on indefinite message-broker retention while preserving reproducibility.

Exact text semantics and multilingual normalization. Unicode normalization must be explicit and conservative. Unicode UAX #15 distinguishes canonical normalization from compatibility normalization; NFC composes canonically equivalent forms, whereas compatibility transformations can remove distinctions.

A good initial authoritative profile is therefore approximately:

exact-profile-v1:
    input encoding: UTF-8
    preserve original Unicode expression: yes
    canonical Unicode normalization: NFC
    case folding: no
    accent stripping: no
    punctuation stripping: no
    whitespace collapsing: no
    stemming: no
    transliteration: no
    compatibility normalization (NFKC/NFKD): no
    probabilistic language detection: no
    language representation: reviewed BCP 47 tag/constraint

The reason is not that case folding or NFKC are intrinsically bad for retrieval. They are useful candidate-generation transformations. They are inappropriate as invisible authority-generating operations because two strings that a search engine considers equivalent need not be governed semantic equivalents. When business requirements demand case-insensitive or transliterated exact resolution, the safer mechanism is to review those forms explicitly or publish a new governed matching profile.

BCP 47/RFC 5646 defines the structure and semantics of language tags, while RFC 4647 defines filtering/lookup semantics. Language handling should therefore be modeled independently of text normalization rather than embedding ad hoc locale behavior into a SQL collation.

A particularly important multilingual rule is never use automatic language detection to break an authoritative ambiguity. Suppose identical Unicode text exists as reviewed evidence in two languages but maps to different concepts. If no language was supplied, the exact resolver should examine the governed possibilities:

no governed match                     → unknown_expression
all matching language records → C17   → resolved(C17)
matching records → {C17, C42}         → ambiguous_expression

A model saying “92% likely German” is interesting candidate evidence but is not authorization to choose C42.

Exact expression indexing. The logical lookup key should be:

ExactKey =
    registry_scope
  + match_profile_id
  + language_constraint_key
  + normalized_utf8_bytes

For high scale:

partition =
    stable_hash(registry_scope || match_profile || language || normalized_text)

stored key =
    full logical key OR
    fixed-width hash + full-byte collision-verification payload

stored value =
    {
      assertion_ids[],
      distinct_concept_uids[],
      status_metadata
    }

The full normalized bytes must be verified before equality is accepted. A 128- or 256-bit hash may make partitioning and indexes compact, but a hash collision must be incapable of becoming a semantic collision.

At the authoritative SQL layer, deterministic B-tree behavior and explicit keys are preferable to opaque locale-equivalence rules. PostgreSQL notes that nondeterministic collations may regard text variants as equal in ways that require semantically significant differences such as case or accent differences to be preserved internally; that is precisely the kind of hidden matching policy an authoritative resolver should avoid.

At small scale the resolver can query a composite SQL B-tree directly. At hundreds of millions to a billion expressions, I would make a static release read model the primary path. Practical implementations worth benchmarking are:

sorted block/SST-like files + sparse index
embedded LSM/B-tree KV
minimal/perfect-hash-assisted static map + collision table
regional managed KV projection

The important property is not the brand; it is immutable generation loading, exact-byte verification, bounded memory, predictable point lookups, and offline portability.

Enterprise private registries. Private registries should be federated, not silently merged. A public ConceptCode must never be redefined by a tenant. A private authority gets its own namespace and signatures. A resolver can mount:

public release P42
tenant release T17
federation policy F3

registry_set_digest =
    H(P42.manifest_digest || T17.manifest_digest || F3.policy_digest)

Every exact cache key, trace, and response then contains registry_set_digest.

Precedence must be governed. Policies such as private-first, public-first, explicit-scope-required, or conflict-is-ambiguity can be legitimate, but implicit last-writer-wins is not. If a private expression deliberately aliases an existing public concept, it should point to that public ConceptCode with reviewed private evidence; if the enterprise concept is genuinely different, it receives an enterprise ConceptCode.

That gives a crucial property: a private overlay may add authority, but it cannot mutate the identity history of the public registry.

Resolver planes, database choices, vector infrastructure, and caching

Exact resolver architecture. The public exact endpoint should be architected as the most boring service in the platform. On a normal request it should not call the authoritative SQL database, a language model, a search cluster, a vector database, Kafka, or another region.

A request path should be:

request
  ↓
authentication / registry-scope selection
  ↓
strict input validation
  ↓
versioned deterministic normalization
  ↓
L1 exact cache
  ↓ miss
active immutable exact map
  ↓
map distinct governed ConceptCodes
  ├── zero  → unknown_expression
  ├── one   → resolved
  └── many  → ambiguous_expression
  ↓
concept projection / evidence attachment
  ↓
decision trace + response

This directly matches Embedded Semantics’ public behavior: reviewed exact expressions resolve deterministically and absence of exact authority causes abstention rather than invented identity.

I would expose exact and experimental candidate retrieval as different APIs or clearly different response modes. For example:

{
  "status": "resolved",
  "conceptCode": "semantic_registry.stable_concept_identity",
  "authorityBasis": "reviewed_exact",
  "registryRelease": "sha256:...",
  "registrySet": "sha256:...",
  "matchProfile": "exact-v3",
  "evidenceIds": ["expr-...", "assertion-..."],
  "decisionId": "..."
}

versus:

{
  "status": "unknown_expression",
  "registryRelease": "sha256:...",
  "decisionId": "...",
  "candidateRetrieval": {
    "status": "available",
    "authorityBasis": "none",
    "candidates": [
      {
        "conceptCode": "...",
        "score": 0.83,
        "rank": 1
      }
    ],
    "modelProfile": "...",
    "indexDigest": "sha256:..."
  }
}

The second result has suggested an existing governed concept, but it has not asserted that the query is semantically identical to it.

Candidate-retrieval architecture. Candidate retrieval should execute only when explicitly requested or when an exact miss enters a documented experimental lane:

exact miss
   ↓
candidate policy / quota
   ├──────── lexical candidate search
   ├──────── embedding model
   │             ↓
   │           ANN
   └──────── metadata/domain/language candidates
                  ↓
              union/fusion
                  ↓
             optional reranker
                  ↓
      authoritative release cross-check
                  ↓
 candidate list + scores + abstention metadata

The cross-check is mandatory. Candidate infrastructure must not return a deleted, revoked, wrong-tenant, or nonexistent ConceptCode merely because a stale vector remains in an ANN collection.

Every candidate index is identified by at least:

candidate_index_id
registry_release_digest
model_profile_id
model_binary_or_service_version
embedding_dimension
preprocessing_profile_digest
distance_metric
ANN_algorithm_and_parameters
build_digest
creation_timestamp
tenant/authority scope
evaluation_suite_version

The public research methodology already identifies Recall@1, Recall@5, mean reciprocal rank, cross-language agreement, false-neighbor rate, language-family spread, score margin, and abstention precision/recall as relevant evaluation measures. Those should become release gates for candidate infrastructure, not correctness metrics for the deterministic exact lane.

Hard negatives are particularly important. A semantically close but wrong concept is exactly where a generic similarity system will look impressive while violating identity. Embedded Semantics explicitly calls for reviewed translations/paraphrases plus hard negatives and says weak or competing model evidence must lead to abstention.

Database analysis. The major datastore classes have very different roles here.

The default recommendation is consequently PostgreSQL first, globally consistent SQL only when governance-write requirements force it. Registry review is not the same workload as consumer resolution. A single primary write region with synchronous intra-region HA and globally distributed immutable data-plane releases is much simpler than global active-active semantic authoring and will usually provide better correctness/operational economics.

PostgreSQL logical replication applies changes in publisher order within a subscription, and PostgreSQL logical decoding derives a replayable change stream from WAL; consumers must nevertheless tolerate replay/duplicate behavior around failures. That is useful for projections, but runtime releases should still activate atomically rather than treating each replicated row as independently visible authority.

Vector infrastructure analysis. There is no reason to begin by vectorizing one billion expressions.

At 768-dimensional float32:

10 million vectors   × 768 × 4 bytes =   30.72 GB raw
100 million vectors  × 768 × 4 bytes =  307.20 GB raw
1 billion vectors    × 768 × 4 bytes =    3.072 TB raw

Those figures are before ANN structures, metadata, filesystem overhead, replicas, snapshots, or temporary rebuild capacity. Three raw replicas of one billion 768-dimensional vectors alone are about 9.2 TB. The economics become much better if the first candidate index contains 10 million concept prototypes/definitions plus only selected high-value reviewed expressions.

The right progression is therefore:

10M concept-level prototype vectors
        ↓ only if measured quality demands it
selected reviewed expression vectors
        ↓
language/domain-specific prototype variants
        ↓ only with strong evidence
larger expression-level index

Never index every observed phrase simply because it exists.

For an early deployment, pgvector is attractive because it minimizes infrastructure sprawl. Its official project documentation supports both HNSW and IVFFlat; IVFFlat builds faster and uses less memory, with a different speed/recall trade-off than HNSW. Once independent scaling, memory isolation, operational ownership, or very large indexes justify it, dedicated options include Qdrant, Milvus, OpenSearch vector search, or a managed system.

Qdrant supports shard replication and configurable write consistency; Milvus exposes Strong, Bounded, Session, and Eventually consistency levels; Pinecone documents eventual visibility of changed records; and OpenSearch’s HNSW/IVF query controls explicitly trade higher candidate exploration for higher recall and higher latency. None of those consistency knobs make nearest-neighbor ranking semantic authority.

I would choose by workload:

Whatever engine is selected, run a shadow exact or brute-force benchmark over a statistically representative subset to calculate ANN recall. ANN is allowed to miss candidates; the authoritative registry is not allowed to misidentify a query because an ANN graph did so.

Cache strategy. Use three levels:

L1  process-local
    exact-key → result
    concept_uid → compact concept response

L2  optional regional Redis/cache
    hot exact results
    concept projection
    short candidate responses

L3  CDN/object cache
    immutable release manifests/artifacts

The fundamental cache key is:

H(
  registry_set_digest,
  resolver_semantics_version,
  match_profile_id,
  language_constraint,
  normalized_expression
)

For immutable releases, positive cache entries do not need conventional invalidation: a new release produces a new keyspace. This is a major benefit of release pinning.

Negative caching needs more care. An unknown_expression is correct for release R42, but might become resolved in R43. Therefore the negative entry must be keyed to R42. Within an immutable release it is logically safe indefinitely; operationally, keep a bounded TTL so obsolete generations age out.

An ambiguous_expression can likewise be cached safely inside its release.

Redis must never be the correctness boundary. Its documented behavior includes memory-driven eviction, so an eviction must cause a normal lookup miss and fallback to the immutable read model—not a semantic behavior change.

Candidate-cache keys additionally include:

model_profile_digest
candidate_index_digest
reranker_digest
candidate_policy_digest

and should be comparatively short-lived because candidate quality may change independently from the governed registry.

Replication, registry releases, multi-region, and offline operation

Replication strategy. There are two replication problems and they should not be solved identically.

For authoring state, use ordinary database HA. With PostgreSQL, synchronous intra-region replication can protect the writer, while cross-region asynchronous WAL can provide DR; PostgreSQL explicitly documents a data-loss window for asynchronous log shipping after commit. If the business requires cross-region RPO 0 for governance writes, use an architecture whose transactional consensus spans regions—such as an appropriately configured Spanner-class system—rather than pretending asynchronous replicas are globally synchronous. Spanner’s multi-region configuration deliberately trades additional write quorum latency for geographic replication.

For the resolver data plane, do not expose database-replica timing as semantic consistency. Replicate immutable complete registry generations.

Each serving region should run a release agent with an A/B model:

ACTIVE:  R142
STAGING: R143

download R143
      ↓
verify manifest signature
      ↓
verify every object digest
      ↓
open exact-map shards
      ↓
validate schema/profile versions
      ↓
run semantic/integrity probes
      ↓
warm essential pages/cache
      ↓
atomic ACTIVE pointer R142 → R143
      ↓
retain R142 until in-flight reads drain

At no moment should a request use the expression index from R143 and the concept projection from R142. The active generation pointer chooses a registry set, not an individual file.

Registry release propagation. The release pipeline should be treated like a software supply chain:

Governed SQL transaction
        ↓
release source snapshot / publication intent
        ↓
deterministic builder
        ↓
exact-map shards + concepts + evidence projections
        ↓
schema/invariant/evaluation validation
        ↓
manifest with digests
        ↓
sign manifest
        ↓
content-addressed object/OCI-style storage
        ↓
transactional outbox → CDC → RegistryReleasePublished
        ↓
regional staging agents
        ↓
hash/signature verification
        ↓
regional canary
        ↓
atomic activation
        ↓
regional release acknowledgements

The current public status page already demonstrates an embryonic form of this design by exposing a deterministic pre-release bundle and its SHA-256 digest. Production should extend that concept to signatures, per-artifact hashes, parent releases, schema versions, normalization-profile digests, and regional activation records.

A manifest should minimally contain:

{
  "registryAuthority": "...",
  "releaseId": "...",
  "parentRelease": "...",
  "createdAt": "...",
  "sourceSnapshot": "...",
  "schemaVersion": "...",
  "matchingProfile": "...",
  "builderDigest": "...",
  "conceptCount": 10000000,
  "expressionAssertionCount": 1000000000,
  "artifacts": [
    {"name": "exact-shard-0000", "sha256": "...", "bytes": 123},
    {"name": "concept-projection-0000", "sha256": "...", "bytes": 456}
  ],
  "signatureMetadata": "..."
}

The mutable object should be only a small “current release” locator. Correct clients resolve that pointer to an immutable manifest digest and pin the digest for the request generation.

Content addressing prevents silent replacement of a named artifact, but a digest alone does not prove who approved it or prevent a malicious mirror from serving an old valid release. A production updater should therefore incorporate signed metadata and rollback/freeze protection modeled on systems such as The Update Framework. TUF explicitly addresses rollback, freeze, and mix-and-match attacks through versioned, signed snapshot/timestamp metadata and hash validation.

Object storage is well suited to these releases. S3-class object stores provide strongly consistent object writes/reads in-region, versioning can preserve overwritten objects, and Object Lock can provide WORM-style retention when compliance requires it.

Incremental releases. One billion expressions make “copy every row on every release” wasteful. Use stable virtual shards, for example 1,024 hash buckets over the exact key. A release manifest references a digest for each shard. If 1% of expressions change, only affected shards need rebuilding and redistribution.

Concept projections can use a similar stable hash partition on concept UID. The release manifest is then a tiny immutable root over an immutable artifact graph.

The unit of correctness remains the entire manifest. A resolver must not activate changed shards one at a time; it stages all referenced objects and atomically switches when the release is complete.

Rollback. Rollback should be a serving operation:

ACTIVE R143 discovered bad
       ↓
freeze further rollouts
       ↓
validate retained R142
       ↓
atomic pointer R143 → R142
       ↓
invalidate/warm generation-local caches as needed
       ↓
publish corrective forward release R144

The authoritative SQL database should not be rewound merely because serving rolled back. The governed corrections that produced R143 remain audit history. If those changes themselves were invalid, they are revoked/superseded through new governance transactions.

For a bad release, rollback is appropriate. For an urgent newly discovered dangerous mapping, a forward emergency revocation is preferable to rollback because an old release might contain other older defects. I recommend a small signed “revocation overlay” that can be produced and distributed quickly, then folded into the next full release. The runtime treats:

registry_set =
    base_release + signed_revocation_overlay

as a new digest, preserving immutable consistency.

Multi-region architecture. The production deployment should be active-active for reads, not automatically active-active for governance writes.

A mature global topology:

                         ┌───────────────────────────┐
                         │ Governance control plane │
                         │ single write region      │
                         │                          │
                         │ Serializable SQL         │
                         │ review / provenance      │
                         │ release publisher        │
                         └─────────────┬─────────────┘
                                       │
                               signed releases
                                       │
                         ┌─────────────▼─────────────┐
                         │ Global artifact fabric   │
                         │ object store + mirrors   │
                         │ content-addressed blobs  │
                         └──────┬─────────┬──────────┘
                                │         │
                  ┌─────────────┘         └─────────────┐
                  ▼                                     ▼
        ┌───────────────────┐                 ┌───────────────────┐
        │ Region A          │                 │ Region B          │
        │ release agent     │                 │ release agent     │
        │ local exact map   │                 │ local exact map   │
        │ resolver fleet    │                 │ resolver fleet    │
        │ L1 / optional L2  │                 │ L1 / optional L2  │
        │ candidate cluster │                 │ candidate cluster │
        └───────────────────┘                 └───────────────────┘
                  ▲                                     ▲
                  └────────── global traffic ───────────┘

This gives global read availability even if the control-plane writer is unavailable. It also means resolution latency is a local region problem rather than a WAN-consensus problem.

Each region should span multiple failure domains. The exact map can be copied onto local NVMe/disks of resolver/storage nodes, or hash-sharded with multiple regional replicas when the complete 1B-expression map is too large to duplicate on every process. The route key is already the exact-expression hash, making shard routing straightforward.

Do not require cross-region consensus on each exact query. All nodes answering from the same signed immutable generation already agree by construction.

Only adopt globally active governance writes when there is a concrete product requirement for geographically distributed reviewers that cannot tolerate a single logical writer region. Spanner’s external consistency is attractive for that case, while CockroachDB offers Serializable transactions with possible client retries.

Offline architecture. Offline should not be a degraded afterthought; immutable releases make it a natural first-class mode.

An offline registry pack should contain:

signed manifest
trust metadata
matching profile
exact-map shards
concept projection shards
governed evidence needed for explanation
optional private-registry overlay
optional lexical candidate index
optional model + ANN index

The exact components must work with no network and no model.

Large deployments should support pack selection by language/authority/domain where policy permits. An air-gapped enterprise might install English, Japanese, and organization-specific shards rather than the entire global observation corpus.

Offline clients must expose freshness:

registry_release
registry_set_digest
release_created_at
last_successful_sync
release_age_seconds
revocation_watermark
offline=true

A stale but correctly signed release is historically coherent; it is not necessarily current. That distinction must be visible to callers.

For strict deployments, configure a maximum permitted release age:

release_age <= policy.max_staleness
    → serve normally

release_age > policy.max_staleness
    → either:
       serve with explicit stale-authority flag, or
       fail closed

The choice is an enterprise policy decision. Safety-critical consumers may prefer fail-closed. Field/offline systems may legitimately prefer last-known-good authority.

Offline observations should queue into encrypted local append-only storage and synchronize later. Synchronization creates observations, not automatic registry evidence.

Reference architecture diagram. The architecture below deliberately places the exact resolver entirely outside the probabilistic candidate dependency chain.

flowchart LR
    C[Clients / SDKs] --> G[API Gateway\nAuth + Rate Limits]

    G --> E[Exact Resolver]
    E --> L1[L1 Process Cache]
    E --> X[Immutable Exact Read Model\nPinned Registry Release]
    E --> CP[Concept / Evidence Projection]
    E --> OUT[Resolved / Unknown / Ambiguous]

    G -. explicit experimental request .-> CR[Candidate Retrieval]
    CR --> LS[Lexical Search]
    CR --> EM[Embedding Service]
    EM --> ANN[Vector / ANN Index]
    LS --> RR[Candidate Fusion / Rerank]
    ANN --> RR
    RR --> AV[Authoritative Release Cross-check]
    AV --> CO[Candidates / Abstention\nNever authoritative resolution]

    GOV[Governance UI / API] --> SQL[(Authoritative Serializable SQL)]
    SQL --> OB[Transactional Outbox]
    OB --> CDC[CDC / Event Stream]

    SQL --> RB[Deterministic Release Builder]
    RB --> VA[Validation]
    VA --> SG[Manifest Signing]
    SG --> CAS[(Content-addressed Object Storage)]

    CAS --> RA1[Regional Release Agent A]
    CAS --> RA2[Regional Release Agent B]
    RA1 --> X
    RA2 --> XR[Region B Exact Read Model]

    CDC --> SI[Search Projection]
    CDC --> VI[Vector Build Pipeline]
    CDC --> AN[Analytics / Observation Processing]

    PR[Enterprise Private Registry] --> PO[Signed Private Overlay]
    PO --> E

    OBS[OpenTelemetry\nTraces Metrics Logs] -.-> E
    OBS -.-> CR
    OBS -.-> GOV
    OBS -.-> RA1

The arrow that must never exist is:

ANN / model score ─────X─────► authoritative ConceptCode assignment

An ANN result may point at an existing ConceptCode as a candidate; only registry governance establishes what that ConceptCode means and whether an input is governed evidence for it.

Consistency, failures, degraded operation, recovery, and security

Consistency model. “Strong consistency everywhere” would be both expensive and conceptually wrong. Different components need different guarantees.

PostgreSQL Serializable transactions provide a serial-equivalent outcome, making them suitable for governance transactions; applications must retry serialization failures. FoundationDB and Spanner provide even stronger real-time/strict forms of ordering in their respective transactional models, making either plausible if the operational requirements warrant them.

The critical runtime guarantee is release consistency, not read-your-latest-row consistency.

A user receiving:

expression assertion from R100
concept definition from R101
private overlay from T17
federation policy from F16

has received an incoherent semantic decision even if every individual datastore read was “strongly consistent.” Therefore the registry-set digest is the real read consistency token.

Clients that require reproducibility should be allowed to pin a specific release:

X-Registry-Release: <digest>

or equivalent request metadata. The resolver either serves exactly that release or returns “release unavailable”; silently upgrading a pinned request defeats reproducibility.

Failure behavior and degraded-mode behavior.

That table captures the most important operational consequence of the authority principle: probabilistic availability never substitutes for authoritative unavailability.

If both the model and vector database are down, a reviewed exact expression still resolves.

If the registry SQL writer is down, an already published expression still resolves from the signed local release.

If the local trusted registry itself is unavailable or corrupt, a beautiful 0.99 vector score still cannot become an authoritative result.

Model outages. Exact requests should not even establish connections to model infrastructure. That creates a powerful isolation boundary: a GPU capacity incident cannot consume the exact resolver’s connection pools, threads, or timeout budget.

For an exact miss with candidate retrieval requested:

{
  "status": "unknown_expression",
  "authorityBasis": "none",
  "registryRelease": "...",
  "candidateRetrieval": {
    "status": "unavailable",
    "reason": "embedding_backend_unavailable"
  }
}

The exact semantic result is still unknown_expression; the optional evidence service failed.

Registry outages. Distinguish three outage classes.

A governance database outage does not affect serving. A release-distribution outage prevents new versions but leaves current local versions intact. A local authority-data outage is more severe: the resolver should try a second verified local copy or remove itself from service. It must not consult ANN as a replacement.

This architecture intentionally converts most registry outages from “request outage” into “freshness outage.”

Disaster recovery. DR targets should be specified separately by plane.

Recommended initial objectives:

PostgreSQL supports continuous WAL archiving and point-in-time recovery, while current pg_basebackup supports full and incremental base backups.

The DR exercise must restore more than SQL. A meaningful test restores:

database
→ release builder
→ signing/trust path
→ immutable artifact store
→ exact read model
→ regional resolver
→ known semantic probes

A database backup that cannot regenerate the same authoritative resolution behavior is not a sufficient semantic DR test.

Backup strategy. Recommended policy:

Authoritative SQL
  continuous WAL/PITR
  regular full/incremental base backups
  encrypted off-account/off-region copy
  periodic logical export for portability
  tested restore

Published releases
  immutable replicated copies
  object versioning
  optional WORM/Object Lock
  never garbage-collect release still referenced by audit/retention policy

Search/vector
  source-of-rebuild recorded permanently
  snapshots where they improve RTO
  do not treat snapshots as semantic backup

Observation data
  compressed immutable object partitions
  lifecycle/tier according to retention

Keys/trust
  HSM/KMS-managed online signing keys
  separately protected root/recovery keys
  tested rotation and emergency revocation

PostgreSQL explicitly distinguishes logical dumps, filesystem backups, and continuous archiving; PITR depends on a base backup plus retained WAL. S3 versioning can retain prior versions after overwrite/delete, while Object Lock supports WORM retention.

A sensible operational starting point is monthly restore verification and quarterly full regional DR exercises, adjusted to compliance requirements. Measure actual restoration time rather than assuming backup completion implies recoverability.

Security boundaries. The strongest architecture has a one-way trust reduction from governance to serving:

Governance writers
   │ high privilege
   ▼
Authoritative DB
   │
   ▼
Release builder
   │
   ▼
Signer
   │
   ▼
Immutable artifacts
   │
   ▼
Read-only resolver

The production resolver should have no credentials capable of editing the registry. Ideally it does not have SQL write credentials at all and consumes only signed release artifacts.

Security zones should include:

A vector database is also a potential cross-tenant disclosure surface. Separate private namespaces/collections and enforce tenant filtering server-side before ranking. For highly sensitive tenants, physically separate candidate infrastructure or disable candidate retrieval.

Rate limiting. Exact and candidate workloads should have separate quotas and worker pools:

exact lookup       weight 1
lexical candidates weight 5
embedding + ANN    weight 20
reranking          weight 30
bulk resolution    explicit batch budget

The exact lane receives reserved CPU, connections, and concurrency. Candidate requests are shed first during overload. Apply per-tenant/API-key quotas plus coarse abusive-IP protections; do not make a remote global rate-limit service a mandatory dependency for every offline/local exact request.

A bulk API should hash-group requests by exact shard and process vectors/batches efficiently rather than allowing clients to simulate bulk traffic through millions of concurrent single requests.

Observability, semantic tracing, SLOs, capacity, cost, and deployment topologies

Observability. Ordinary SRE telemetry is necessary but insufficient. A resolver can return HTTP 200 in 3 ms while returning the wrong ConceptCode; operationally healthy infrastructure can still be semantically wrong. OpenTelemetry provides the right transport model because traces, metrics, logs and context propagation are designed to correlate activity across distributed services.

Instrument four dimensions:

infrastructure correctness
release correctness
resolver semantic correctness
candidate quality

Infrastructure telemetry includes latency, saturation, queueing, failures, database health, replication lag, CDC lag, cache behavior and resource usage.

Release telemetry includes:

registry_release_build_seconds
registry_release_build_failures_total
registry_release_validation_failures_total
registry_release_artifact_bytes
registry_release_activation_seconds
registry_release_region_age_seconds
registry_release_region_skew
registry_release_hash_failure_total
registry_release_signature_failure_total
registry_release_rollback_total
registry_release_stale_instances

Semantic correctness telemetry deserves first-class alarms:

authority_violation_total                   MUST BE 0
mixed_registry_generation_total             MUST BE 0
ambiguous_expression_resolved_total         MUST BE 0
revoked_assertion_served_total              MUST BE 0
unknown_expression_ratio
ambiguous_expression_ratio
normalization_profile_mismatch_total        MUST BE 0
golden_exact_mismatch_total                 MUST BE 0
unexpected_new_ambiguity_total
concept_code_reuse_attempt_total            MUST BE 0
cross_tenant_result_violation_total         MUST BE 0
candidate_registry_version_mismatch_total

Unknown and ambiguity rates are not errors by themselves. They become valuable change-detection signals. A sudden jump in Japanese unknown_expression after release activation could indicate missing shards, normalization drift, bad language tags, or an accidental revocation.

Candidate metrics should mirror the project’s published methodology: Recall@1/@5, MRR, cross-language agreement, false-neighbor rate, distribution/spread metrics, top-1/top-2 margin and abstention precision/recall.

Semantic decision tracing. Every exact decision must be explainable, but storing full raw request text in every distributed trace creates privacy and cost problems. The solution is a compact reconstructable decision envelope.

Recommended exact trace:

{
  "decisionId": "...",
  "traceId": "...",
  "timestamp": "...",
  "resolverBuild": "...",
  "region": "...",
  "tenant": "...",
  "expressionFingerprint": "hmac:...",
  "rawExpressionLogged": false,
  "inputLanguage": "ja",
  "matchingProfile": "exact-v3",
  "registrySetDigest": "sha256:...",
  "publicRelease": "sha256:...",
  "privateRelease": "sha256:...",
  "normalizedKeyHash": "...",
  "cache": "L1|L2|MISS",
  "governedMatchCount": 2,
  "distinctConceptCount": 1,
  "assertionIds": ["...", "..."],
  "conceptCodes": ["..."],
  "result": "resolved",
  "authorityBasis": "reviewed_exact",
  "latency": {
    "normalizeMicros": 30,
    "lookupMicros": 500,
    "renderMicros": 90
  }
}

For candidate retrieval, append:

{
  "candidate": {
    "invoked": true,
    "authorityBasis": "none",
    "embeddingModelDigest": "...",
    "preprocessingDigest": "...",
    "vectorIndexDigest": "...",
    "candidateRegistryRelease": "...",
    "annAlgorithm": "hnsw",
    "topK": 20,
    "scores": ["..."],
    "rerankerDigest": "...",
    "abstentionPolicyDigest": "...",
    "outcome": "candidates_only"
  }
}

OpenTelemetry semantic conventions provide standardized attribute naming patterns, while traces and propagated context can correlate events across services. Define an Embedded Semantics namespace such as:

semantic.registry.release
semantic.registry.set_digest
semantic.resolve.mode
semantic.resolve.status
semantic.resolve.authority_basis
semantic.match.profile
semantic.match.evidence_count
semantic.candidate.model
semantic.candidate.index_digest
semantic.abstention.reason

Avoid ConceptCode, raw expression, or arbitrary tenant text as metric labels because of high cardinality and privacy. Put them in controlled traces/logs instead.

At 5,000 RPS, 100% verbose decision logging becomes enormous: 432 million requests/day. A 200-byte compact record is already roughly 86 GB/day before encoding/compression. Therefore:

100%:
    counters
    SLI measurements
    compact recent decision envelopes if budget permits
    all semantic invariant violations
    all governance/publish/revoke audit events

sampled:
    normal detailed distributed traces

100% persistent:
    governance decisions
    release signatures/manifests
    semantic anomalies
    explicit explain/debug requests

A privacy-sensitive deployment should use tenant-scoped keyed fingerprints for raw expressions; secure debugging may capture encrypted content only under controlled, time-bounded authorization.

Metrics. The minimum operational dashboard should contain:

PostgreSQL’s logical replication and statistics facilities can expose replication state, while Debezium produces the committed change stream needed for CDC-lag measurement.

SLOs and SLIs. These should be separated by service class.

Recommended starting production objectives:

These are recommended initial targets to validate through benchmark, not claims about present Embedded Semantics performance.

A semantic authority violation should not have an error budget. “We were allowed to let ANN silently override exact authority for 43 minutes this month because our SLO was 99.9%” is the wrong operating model. Treat such conditions as safety invariants and incident-severity triggers.

Latency budgets should also be physically isolated:

EXACT RESOLUTION — p99 service budget ≈ 25–50 ms
-------------------------------------------------
ingress/auth                 2–8 ms
normalization                <1 ms typical
L1/local exact lookup        <1–10 ms
concept/evidence projection  1–10 ms
serialization/trace          1–3 ms
reserve for queue/jitter     remainder

versus:

CANDIDATE RETRIEVAL — p99 budget ≈ 500–750 ms
------------------------------------------------
exact miss determination     5–25 ms
embedding inference          20–150+ ms
ANN / lexical retrieval      10–150 ms
fusion/rerank                10–200 ms
authority cross-check        1–20 ms
network/queue reserve        substantial

The exact responder should immediately return a successful governed match without waiting to “enhance” it with vectors.

Capacity planning. At the projected scale, exact keys are large but quite manageable if represented compactly.

For one billion exact expressions, suppose a compact index requires approximately:

16 B  expression/key hash
 8 B  language/profile/partition metadata
 8 B  value or offset pointer
 8–24 B additional block/index metadata amortized
--------------------------------------------------
≈40–56 B core/key

That is roughly 40–56 GB for core key metadata before full-string collision verification. If normalized expressions average 40 bytes, that contributes another ~40 GB uncompressed. Block structures, values, evidence references and filesystem/LSM overhead can reasonably push a complete compact exact map into roughly the 100–250 GB class, depending heavily on compression and expression length. These are sizing assumptions to benchmark, not a product claim.

That size is small enough to make region-local NVMe-backed authoritative maps practical. With 1,024 stable virtual shards, a 150 GB release averages only about 146 MB per virtual shard. Virtual shards can then be placed across a much smaller number of physical shard servers.

Ten million compact concept projections are smaller. At 2 KB per concept, 10 million concepts consume around 20 GB before indexes/replication; at 5 KB, around 50 GB.

Vectors deserve much more caution:

ANN indexes, replicas and metadata are additional. OpenSearch, for example, exposes disk/quantized vector modes precisely because vector storage/memory becomes a major operational variable, while ANN search parameters trade recall against latency.

Therefore concept-level vectors first is both cheaper and semantically cleaner.

Observation cardinality must be translated into a time rate. One billion observations over a year averages only about 32 events/s; one billion observations per day is about 11,574 events/s. Design Kafka and ingestion around peak rate and retention horizon, not the phrase “one billion rows.”

Release rebuild throughput has a similar implication:

1B expressions / 24 h ≈ 11.6k rows/s
1B expressions /  6 h ≈ 46.3k rows/s
1B expressions /  2 h ≈ 138.9k rows/s

A deterministic parallel builder should target comfortably above the desired full-rebuild speed, while routine releases use content-sharded deltas.

Cost considerations. The largest likely cost mistakes are architectural, not micro-optimizations.

The expensive design is:

every request
 → cross-region SQL
 → search cluster
 → remote embedding API
 → billion-vector ANN cluster
 → distributed cache

The economical design is:

most requests
 → local immutable exact map

with candidate services paid for only when requested.

Cost drivers, roughly in descending concern at large scale, are likely to include vector inference/index memory, redundant 1B-row secondary indexes, multi-region synchronous database capacity, duplicated full-text search storage, cross-region artifact/telemetry traffic, verbose high-cardinality observability and long-term raw observation retention.

Specific cost controls should include:

keep unreviewed observations out of OLTP
compress/archive observations to object storage
index concepts before indexing every expression vector
batch embeddings
quantize only after measured quality tests
use immutable release deltas rather than whole-registry copies
keep exact lookup local
avoid distributed Redis on paths already satisfied by local immutable data
tier old release/artifact retention
sample normal traces
reserve high-cardinality payloads for logs/object storage

A dedicated vector database should be introduced because benchmarks justify it, not because “semantic” appears in the product name.

Deployment topology examples.

Early production topology.

One governance region
  PostgreSQL primary + HA standby
  exact resolver pods
  SQL B-tree or immutable exact map
  object storage for signed releases
  in-process L1 cache
  Redis optional
  pgvector experimental cluster/database

This handles the first millions of records with the fewest systems.

Scaled global public topology.

Control region
  Serializable PostgreSQL/managed SQL
  CDC/outbox
  release build/sign pipeline

Global
  replicated content-addressed release artifacts
  event/control dissemination

Each serving region
  3+ resolver instances/failure domains
  local immutable exact shards RF≥2/3
  process cache
  optional Redis L2
  optional regional search/vector stack
  regional release agent
  OpenTelemetry collector

Enterprise private topology.

Public signed releases ──► enterprise mirror
                              +
Enterprise governance DB ─► private signed releases
                              ↓
                     tenant resolver cluster
                              ↓
       public + private registry-set fingerprint

Candidate infrastructure:
   customer-hosted OR disabled OR explicitly opt-in cloud

Air-gapped/offline topology.

connected release exporter
     ↓ signed removable/offline package
air-gapped artifact mirror
     ↓
local edge resolvers
     ↓
local exact maps
     ↓
optional local lexical/vector candidate stack

No cloud service is required to preserve exact authority.

Globally active governance topology, only if necessary.

Global-consensus SQL
      ↓
regional governance APIs
      ↓
same immutable publish pipeline
      ↓
same regional resolver architecture

Even when authoring becomes globally writable, runtime resolution should still use immutable releases. Global SQL does not remove the value of a version-coherent data plane.

Scaling roadmap and benchmarks

Phased scaling roadmap.

The migration rule should be: scale read models horizontally before scaling authority horizontally. Ten million concepts and one billion expressions are large enough to require partitioning and build engineering, but not intrinsically large enough to justify globally distributed semantic writes.

Benchmarks that should be run. Do not choose the final exact key/value technology, ANN algorithm, vector database, or shard layout from documentation alone. Benchmark the actual expression distribution.

The exact-resolution benchmark needs at least:

The Unicode/matching benchmark should include Unicode normalization conformance against UAX #15, runtime-version parity, malformed UTF-8 rejection, combining characters, canonical equivalents, visually similar non-equivalents, width/compatibility forms, casing, punctuation, whitespace and confusable-script cases. UAX #15 is the normative normalization reference.

The release benchmark should measure:

full 1B build
0.1%, 1%, 5%, 20% delta releases
parallel shard throughput
peak temporary disk
deterministic rebuild equality
manifest creation/signing
regional download
verification
cold-open time
cache/page warmup
atomic swap duration
old-generation drain
rollback duration

Run a reproducibility test in which two independent builders receive the same source snapshot and must produce byte-identical content digests.

The governance database benchmark should test:

concurrent concept creation
concurrent review of same assertion
ambiguity introduction/removal
revocation races
Serializable conflict/retry rate
release snapshot while reviews continue
writer failover
replica lag
PITR restore
CDC backpressure
replication-slot/WAL growth

PostgreSQL’s Serializable mode may abort transactions to preserve serializable execution, so retry behavior needs explicit load testing rather than being discovered under review traffic.

The CDC benchmark should disconnect consumers for minutes/hours, accumulate outbox/WAL lag, reconnect, replay duplicates, and verify projection convergence. PostgreSQL logical decoding can replay recent data around recovery conditions and explicitly places responsibility on clients to avoid harmful duplicate handling.

The candidate benchmark should use both approximate and exact/brute-force baselines. OpenSearch documents the fundamental ANN control trade-off: examining more HNSW candidates improves recall while increasing latency. Measure:

Recall@1
Recall@5
MRR
false-neighbor rate
hard-negative error rate
cross-language agreement
abstention precision
abstention recall
top1-top2 margin calibration
latency versus ANN recall
memory versus recall
quantization quality loss
model-version drift
language-family breakdown
domain breakdown
tenant/domain filter correctness

Those quality dimensions align closely with Embedded Semantics’ own published research criteria.

The most important candidate test is not an average benchmark. Build explicit adversarial sets where two concepts are extremely related but non-equivalent. The candidate infrastructure should fail safely into “multiple candidates” or abstention.

Run failure-injection tests for:

embedding service timeout
vector index unavailable
search unavailable
cache unavailable
SQL primary unavailable
CDC stopped
artifact store unavailable
signing service unavailable
one region partitioned
resolver uses old release
corrupted shard delivered
manifest hash mismatch
signature mismatch
rollback/replay attack
private/public registry conflict
cross-tenant vector result
release switch during 100k concurrent requests

Expected semantic behavior must be asserted, not merely availability.

Finally, perform long-duration soak tests—at least workload-duration sufficient to expose cache churn, WAL retention, memory fragmentation, index compaction, shard hotspots and release overlap—with at least 2× expected sustained load and dedicated burst tests at the chosen peak design envelope.

Final architecture assessment and bibliography

Final architectural assessment. The optimal architecture is not “pick the database that can hold one billion expressions.” It is to assign each type of information to the consistency domain it actually deserves.

The authoritative registry is a governed transactional system. It should be relational by default because identity, provenance, revision history, review state, ambiguity and publication have transactional relationships and invariants. PostgreSQL is the most pragmatic initial recommendation; Spanner or CockroachDB becomes interesting when global governance writes—not global reads—create a genuine need for geographically distributed serializable transactions. PostgreSQL provides Serializable isolation and WAL-based replication/PITR, while Spanner provides external consistency and multi-region quorum replication.

The runtime is a versioned distribution system. It should consume immutable signed registry generations, not continuously query mutable governance tables. That makes exact resolution extremely fast, globally distributable, easy to pin, reproducible, offline-capable and resilient to control-plane failures.

The exact lookup system is therefore closer to an immutable package/runtime database than to search. Its equality rules must be versioned, conservative and deterministic. Unicode canonical normalization and BCP 47 language semantics provide standards-based foundations, while fuzzy analysis belongs outside the authority path.

Search engines are derived discovery infrastructure. They are excellent for multilingual analyzers, prefix/fuzzy lookup, human registry browsing and lexical candidate generation. Their analyzer semantics and near-real-time update model are reasons not to make them the final exact authority.

Vector stores and ANN indexes are replaceable evidence machinery. HNSW, IVF, pgvector, OpenSearch, Qdrant, Milvus or a managed vector service can all be legitimate engineering choices; all make retrieval-performance, memory, consistency or recall trade-offs. Those choices are model infrastructure decisions, not decisions about what a ConceptCode means.

Caches are performance optimizers, made particularly safe by release-digest keying. Event streams and CDC are propagation mechanisms. Object storage is the distribution/archive substrate. Signed content-addressed releases are the unit of runtime coherence. None of these replaces governed source authority.

The end-state can therefore be summarized in one dependency rule:

Governance establishes identity.
Releases preserve identity.
Exact indexes accelerate identity.
Caches accelerate exact indexes.
Search discovers possibilities.
Vectors rank possibilities.
Models generate evidence.
None of the last three is allowed to redefine the first.

That is the production architecture most faithful to Embedded Semantics’ publicly stated goal that a ConceptCode survive changes in language, model version, retraining and vector coordinates.

Bibliography. The research basis below intentionally emphasizes primary project specifications and official vendor/standards documentation rather than secondary architectural commentary.

Embedded Semantics public architecture. “Stable concept identity across languages” establishes stable ConceptCodes, reviewed multilingual expression evidence, deterministic exact resolution, vectors-as-evidence and experimental candidate retrieval. “Research & Methodology” documents the production/research boundary, hard negatives, retrieval quality metrics, abstention and independent provenance/versioning. “Registry & Runtime Status” documents the currently deployed capability boundary, reviewed_exact_registry_first mode, inactive semantic runtime, zero active embedding profiles and the deterministic pre-release bundle digest. The project’s machine-readable llms.txt reiterates unknown_expression, ambiguous_expression, experimental vector retrieval and ConceptCode/definition authority.

Relational and distributed transactional stores. PostgreSQL, “Transaction Isolation,” for Serializable semantics. PostgreSQL, “Logical Replication” and “Logical Decoding Concepts,” for WAL-derived change streams and subscriber ordering. PostgreSQL, “Continuous Archiving and Point-in-Time Recovery” and pg_basebackup, for PITR and base/incremental backups. Google Cloud Spanner documentation on external consistency, multi-region replicas and write quorum trade-offs. CockroachDB transaction documentation for default Serializable behavior and retries. FoundationDB documentation for strict serializability.

Alternative stores and search infrastructure. AWS DynamoDB global-table documentation for MREC/MRSC and the lack of transaction APIs on MRSC global tables. MongoDB documentation for snapshot read concern and majority-backed distributed transactions. Elasticsearch official documentation for its search/full-text model. OpenSearch documentation for HNSW/IVF vector indexing and recall/latency search controls.

Vector infrastructure. pgvector official repository documentation on HNSW and IVFFlat trade-offs. Qdrant distributed-deployment and consistency documentation for sharding, replication and write consistency. Milvus consistency documentation for Strong, Bounded, Session and Eventually modes. Pinecone data-freshness documentation for eventual visibility of updates.

Text and language standards. Unicode Standard Annex #15, “Unicode Normalization Forms,” for canonical and compatibility normalization behavior. RFC 5646 for language-tag structure and semantics and RFC 4647 for language-tag filtering/lookup.

Streaming, CDC and cache infrastructure. Debezium PostgreSQL connector documentation for consistent snapshots followed by committed row-change capture, and Debezium’s outbox-pattern guidance for reliable DB/event coordination. Apache Kafka documentation for partitioned ordered append-only logs and idempotent/transactional producer capabilities. Redis documentation for memory-bound eviction and cache hit/eviction observability.

Artifacts, recovery and supply-chain integrity. Amazon S3 documentation for strong object consistency, versioning and WORM/Object Lock capabilities. The Update Framework specification for signed metadata and defenses against rollback, freeze and mix-and-match attacks.

Observability. OpenTelemetry documentation for traces, metrics, logs, context propagation and semantic conventions.