Part 4 — Building and Operating

Governance, Risk, and Responsible Deployment

An LCM-powered regulatory analysis system flags a potential contradiction between two jurisdiction-specific requirements. The compliance officer asks: "How did the system identify this contradiction? What was its reasoning?" The system cannot produce a chain-of-thought. The reasoning happened in a 1,024-dimensional vector space. There is no token-level trace to read.

This is the governance challenge that LCMs introduce that LLM governance frameworks do not prepare you for. It is not hypothetical. Regulated industries — financial services, healthcare, energy, government — require explainability as a compliance condition. "The model found it in concept space" is not an explanation that satisfies an examiner.

This chapter covers the governance implications specific to LCMs, the risk categories that differ from LLM risk, and a governance checklist for LCM deployments in regulated enterprise environments.

What You Will Learn

• Identify the governance challenges specific to concept-space reasoning that LLM frameworks do not address
• Explain bias in SONAR embeddings and how it differs from token-level bias
• Design data lineage tracking for concept-encoded document corpora
• Apply auditability requirements from regulated industries to LCM deployments
• Complete the LCM governance checklist for your organization's deployment context

15.1 Explainability in Concept Space

The fundamental explainability challenge with LCMs is that the reasoning happens in concept space — a continuous, high-dimensional vector space — and not in a discrete, human-readable token sequence. When an LLM uses chain-of-thought reasoning, the intermediate steps are tokens: they can be read, evaluated, and used to explain the output. When a concept model reasons over concept embeddings, the intermediate states are vectors: they cannot be read directly.

What explainability means for LCMs. The practical standard for LCM explainability is not "show me the reasoning" (which requires a token-level trace) but "show me the evidence." For a contradiction detection output, the evidence is: the two source sentences that were flagged, their similarity score in concept space, and the semantic dimension on which they diverge. This is auditable evidence — a regulator can read the two flagged sentences and assess whether the contradiction finding is reasonable — even though the reasoning that produced the flag is not directly readable.

Proxy explainability through attribution. For any LCM output, maintain an attribution record that links each output sentence to the source concept embeddings that had the highest similarity to it. The attribution record does not explain the concept model's internal states, but it provides an evidence chain: this output sentence was generated from concept embeddings most similar to these source sentences. A human can read the source sentences and assess whether the output accurately represents them.

def generate_with_attribution(
    context_embeddings: list,
    context_metadata: list[dict],
    concept_model,
    decoder,
    output_lang: str = "eng_Latn",
    top_k_attributions: int = 3
) -> list[dict]:
    """
    Generate output with per-sentence source attribution.
    """
    output_embeddings = concept_model.generate(context_embeddings)

    results = []
    for out_emb in output_embeddings:
        # Decode output sentence
        output_sentence = decoder.predict([out_emb], target_lang=output_lang)[0]

        # Find top-k most similar source sentences
        out_arr = np.array(out_emb)
        similarities = [
            (meta, float(cosine_similarity(out_arr, np.array(ctx_emb))))
            for ctx_emb, meta in zip(context_embeddings, context_metadata)
        ]
        top_sources = sorted(similarities, key=lambda x: x[1], reverse=True)[:top_k_attributions]

        results.append({
            "output_sentence": output_sentence,
            "attributed_sources": [
                {"text": src[0]["text"], "doc_id": src[0]["doc_id"], "similarity": src[1]}
                for src in top_sources
            ]
        })

    return results

Regulatory standard for explainability. The attribution approach satisfies the evidence chain requirement for most regulatory explainability standards (EU AI Act, SR 11-7 model risk management guidance, FDA SaMD guidance). It does not satisfy standards that require a human-readable reasoning chain — the standard applied to some high-stakes individual decision systems (credit decisions, medical diagnoses). For those use cases, LCMs are currently not appropriate without additional interpretability tooling.

15.2 Bias in SONAR Embeddings

Bias in AI systems is well-understood at the token level: training data biases produce biased token probability distributions, which produce biased outputs. LCM bias operates differently and requires a different audit approach.

SONAR embeddings reflect training data semantics. SONAR was trained on large multilingual text corpora. The semantic relationships encoded in SONAR concept space reflect the semantic relationships in that training data — including any cultural, geographic, or demographic biases present in the data. "CEO" and "leadership" may be closer to "male" concepts in SONAR space if the training corpus contained more text associating leadership with male pronouns. This is not a SONAR-specific problem — it is the embedding version of the same bias that affects LLMs.

LCM-specific bias patterns. Two bias patterns are particular to LCM architectures:

1. Cross-lingual alignment bias. SONAR's concept space was built primarily on high-resource language text. The semantic relationships between concepts may be calibrated to the cultural and linguistic norms of those high-resource languages (predominantly European and East Asian). Concepts that have different connotations or relationships in low-resource language communities may be placed in concept space based on their closest high-resource language equivalent, losing culturally specific meaning. For enterprise use cases involving legal or policy content from communities represented by low-resource languages, this bias can produce systematically incorrect equivalence assessments.

2. Domain vocabulary bias. SONAR's general-purpose training may not accurately place specialized technical, legal, or financial terminology in concept space relative to its precise domain meaning. "Fair market value" and "book value" may be closer in concept space than their domain-specific distinction warrants. This affects contradiction detection and equivalence assessment in domain-specific use cases.

Bias audit protocol:

def audit_embedding_bias(
    concept_pairs: list[tuple[str, str]],
    expected_direction: list[int],  # 1 if first should be higher, -1 if second
    probe_dimension: np.ndarray,  # Direction vector for the dimension being audited
    lang: str = "eng_Latn"
) -> dict:
    """
    Audit SONAR embeddings for bias along a specified semantic dimension.
    Example: audit gender bias by setting probe_dimension to the
    male-female direction vector in SONAR space.
    """
    texts_a = [p[0] for p in concept_pairs]
    texts_b = [p[1] for p in concept_pairs]

    embeddings_a = encoder.predict(texts_a, source_lang=lang)
    embeddings_b = encoder.predict(texts_b, source_lang=lang)

    projections_a = [float(np.dot(emb, probe_dimension)) for emb in embeddings_a]
    projections_b = [float(np.dot(emb, probe_dimension)) for emb in embeddings_b]

    correct_direction = sum(
        1 for pa, pb, exp in zip(projections_a, projections_b, expected_direction)
        if (pa > pb) == (exp > 0)
    )

    return {
        "bias_alignment_rate": correct_direction / len(concept_pairs),
        "mean_projection_a": float(np.mean(projections_a)),
        "mean_projection_b": float(np.mean(projections_b)),
        "projection_pairs": list(zip(projections_a, projections_b))
    }

15.3 Data Lineage for Concept-Encoded Corpora

LCM systems process documents by encoding them into concept embeddings and storing those embeddings in a vector database. The data lineage question is: when a contradiction is flagged or an equivalence is identified, what is the provenance of the source concept embeddings?

Minimum viable data lineage record. For each concept embedding in the vector database, maintain:

• Source document identifier (unique ID, version, date)
• Source sentence text (the original text that was encoded)
• Encoding timestamp (when the encoding was performed)
• SONAR model version (which model produced the embedding)
• Preprocessing steps applied (chunking strategy, language detection results)

@dataclass
class ConceptEmbeddingRecord:
    embedding_id: str           # UUID for this embedding
    source_doc_id: str          # Document identifier
    source_doc_version: str     # Document version/date
    source_sentence: str        # Original sentence text
    source_lang: str            # Detected or specified language
    encoded_at: datetime        # Encoding timestamp
    sonar_model_version: str    # "text_sonar_basic_encoder_v1.0" etc.
    preprocessing_steps: list[str]  # ["sentence_splitting", "clause_boundary_split"]
    embedding: list[float]      # The 1,024-dimensional vector

This record enables full lineage from any LCM output back to the source document, sentence, and encoding conditions. When a regulator asks "where did this finding come from?", the attribution system (Section 15.1) provides the output-to-source mapping, and the data lineage record provides the source-to-document provenance.

Versioning and re-encoding. When documents are updated, re-encoding may change the concept embeddings for affected sentences, even if the text did not change. SONAR model updates also change embeddings for the same text. Maintain embedding version records to ensure that analyses are compared against embeddings from the same encoding version. Cross-version comparisons (using embeddings from different SONAR versions) may produce unreliable similarity scores.

15.4 Auditability Requirements by Regulated Industry

Financial services (SR 11-7 and OCC model risk guidance). Model risk management requirements apply to LCM systems used for credit, compliance, or risk decisions. Key requirements: model validation (independent evaluation of the LCM's performance on representative tasks), ongoing monitoring (tracking output quality metrics over time), documentation (model description, intended use, limitations), and inventory registration. The semantic similarity evaluation harness from Chapter 14 provides the quantitative performance evidence required for model validation.

Healthcare (FDA SaMD and HIPAA). AI systems used in clinical decision support must meet software as a medical device (SaMD) requirements if they influence clinical decisions. For LCM systems (e.g., multi-document clinical evidence synthesis), this requires: prospective clinical validation, version control on model weights and SONAR encoder, traceability from system output to source evidence, and documentation of intended use limitations. The attribution record from Section 15.1 supports the traceability requirement.

Government (FedRAMP and AI Executive Order). Federal government deployments face FedRAMP authorization requirements for cloud-hosted components and AI-specific requirements under the 2023 AI Executive Order and subsequent agency policies. Key requirements: data residency (concept embeddings must be stored in authorized infrastructure), model transparency (documentation of training data and model architecture), and human oversight (human review gates before LCM outputs influence decisions). The human-in-the-loop integration from Chapter 11 supports the human oversight requirement.

15.5 LCM Governance Checklist

Use this checklist before deploying any LCM system in a regulated enterprise environment.

Explainability

• Attribution records are generated for every LCM output, linking output sentences to source concept embeddings
• Source documents for every concept embedding are identifiable and accessible
• A human-readable summary of the evidence chain is available for every finding
• Explainability requirements for the specific regulatory context have been assessed and documented

Bias

• SONAR embedding bias audit has been completed for the dimensions relevant to the use case
• Cross-lingual alignment quality has been validated for all source languages in the corpus
• Domain vocabulary bias has been assessed on a representative domain vocabulary sample
• Bias mitigation strategies (domain adaptation, embedding calibration) are documented and applied where needed

Data Lineage

• Every concept embedding in the production system has a complete ConceptEmbeddingRecord
• SONAR model version is recorded with each embedding
• Re-encoding policy and versioning strategy are documented
• Data residency requirements are satisfied for all embedding storage

Model Risk Management

• Model documentation is complete: architecture, intended use, limitations, performance characteristics
• Validation has been completed: independent evaluation on representative tasks
• Ongoing monitoring metrics are defined and instrumented
• Model is registered in the organization's model inventory

Human Oversight

• Human review gates are defined for all high-stakes LCM outputs
• Review workflow is documented and integrated into the operational process
• Escalation paths for flagged findings are defined
• Human reviewers have been trained on the system's capabilities and limitations

Summary

LCMs introduce governance challenges not covered by LLM frameworks: concept-space reasoning is not directly interpretable, SONAR bias differs from token-level bias, and data lineage must be maintained at the embedding level. The governance checklist provides a structured approach to deploying LCMs in regulated environments.

• Attribution over interpretation. LCMs cannot produce chain-of-thought traces. The evidence chain — output sentence → source concept embeddings → source documents — is the practical explainability substitute.
• Bias is in the geometry. SONAR bias is about where concepts are placed in concept space, not what tokens follow what tokens. The audit approach must reflect this.
• Data lineage at the embedding level. Every concept embedding must be traceable to its source document, version, and encoding conditions.
• The checklist is the compliance artifact. Complete it before production deployment; maintain it as the system evolves.

Exercises