Guia de criação de adaptador

Propósito

Este documento define o ContractForge Core API público e o contrato comportamental necessário para construir um adaptador de plataforma totalmente funcional.

O leitor alvo é um engenheiro que constrói adaptadores como:

• contractforge-aws
• contractforge-fabric
• contractforge-snowflake
• contractforge-gcp
• futuros adaptadores privados/específicos do cliente

Um adaptador não é um fork do ContractForge Core. É uma implementação de plataforma que consome contratos principais, declara capacidades de plataforma, traduz planos abstratos em artefatos nativos, opcionalmente os executa e persiste evidências.

Responsabilidades do adaptador

Um adaptador deve fornecer estas superfícies:

Surface	Obrigatório	Propósito
Capability declaration	Yes	Diga ao planejador principal qual semântica ContractForge a plataforma pode preservar.
Ponte de planejamento	Yes	Execute o planejamento principal em relação aos recursos do adaptador e adicione avisos/bloqueadores específicos do adaptador quando necessário.
Artifact rendering	Yes	Produza SQL nativo, definições de trabalho, scripts, pipeline JSON, Terraform, revisão Markdown ou equivalente.
Mapeamento de evidências	Yes	Persista ou renderize estruturas de evidências/tabelas de controle para execuções, estado, qualidade, erros, linhagem, acesso e operações.
Execução em tempo de execução	Opcional, mas esperado para adaptadores de produção	Execute o plano renderizado/traduzido usando clientes de plataforma injetados ou identificadores de tempo de execução.
Tradução original	Esperado	Traduza os principais contratos de origem em leituras nativas, trabalhos, operações de cópia, consultas ou artefatos de revisão.
Catálogo de suporte de origem	Esperado	Publique metadados de suporte de propriedade do adaptador para cada família de origem, incluindo mapeamento nativo, status e notas de revisão.
Tradução de governança	Esperado para plataformas governadas	Traduza anotações, operações e contratos de acesso em metadados/controles de segurança nativos.
CLI integration	Necessário para adaptadores empacotados	Exponha o vocabulário de comandos do adaptador canônico de docs/cli.md; mantenha as opções específicas da plataforma sob esses comandos. Validação/esquema/init genérico continuam sendo preocupações centrais.

Os adaptadores não devem exigir que o núcleo importe SDKs da plataforma.

APIs de núcleo público para usar

Os autores do adaptador devem tratar os módulos a seguir como a superfície pública estável.

API	Import	Usar
Protocolo adaptador	contractforge_core.adapters	Implemente PlatformAdapter e retorne RenderedArtifacts.
Modelo de capacidade	contractforge_core.capabilities	Declare PlatformCapabilities.
Planner	contractforge_core.planner	Call plan_contract(contract, capabilities).
Planejando modelos de resultados	contractforge_core.planner	Return PlanningResult, PlanningBlocker, PlanningWarning, ExecutionPlan.
Modelo semântico	contractforge_core.semantic	Consumir SemanticContract e intenções imutáveis.
Análise/validação de contrato	contractforge_core.contracts	Valide os mapeamentos YAML/Python e normalize via semantic_contract_from_mapping.
Bundle composition	contractforge_core.contracts	Use load_contract_bundle e compose_contract_sections.
Metadados de origem	contractforge_core.connectors	Use taxonomia de origem, metadados editados e diagnósticos de portabilidade.
Diferença de esquema	contractforge_core.schema	Compare esquemas e valide strict, additive_only, permissive.
Resultados de qualidade	contractforge_core.quality	Retorna QualityRuleResult normalizado e status agregado.
Modelos neutros em tempo de execução	contractforge_core.runtime	Use PreparedInput, QuarantineReference, QueryOne quando útil.
Registros de evidências	contractforge_core.evidence	Use formas de registro neutras ao renderizar evidências do adaptador.
Resultado da execução	contractforge_core.execution	Retorne ExecutionOutcome dos auxiliares de gravação em tempo de execução.
Security/redaction	contractforge_core.security	Edite metadados de origem/autenticação/tempo de execução antes da evidência.
Naming/watermark helpers	contractforge_core.naming, contractforge_core.watermark	Use nomes portáteis e auxiliares de marca d’água tipados.

Não importe pacotes de adaptadores do core. Pacotes de adaptadores podem importar core.

Protocolo Adaptador Mínimo

O protocolo do adaptador principal é intencionalmente pequeno:

from contractforge_core.adapters import PlatformAdapter, RenderedArtifacts
from contractforge_core.capabilities import PlatformCapabilities
from contractforge_core.planner import ExecutionPlan, PlanningResult, plan_contract
from contractforge_core.semantic import SemanticContract


class MyPlatformAdapter:
    name = "my-platform"

    def capabilities(self) -> PlatformCapabilities:
        return PlatformCapabilities(
            platform=self.name,
            supports_append=True,
            supports_overwrite=True,
            supports_merge=True,
            evidence_stores=("audit_tables",),
        )

    def plan(self, contract: SemanticContract) -> PlanningResult:
        return plan_contract(contract, self.capabilities())

    def render(self, plan: ExecutionPlan) -> RenderedArtifacts:
        return RenderedArtifacts(
            artifacts={
                "review.md": "...",
                "job.sql": "...",
            }
        )

Um adaptador de produção geralmente adicionará métodos em torno deste protocolo, como render_contract(), ingest_bundle(), apply_access_contract() ou execute_plan(). Esses métodos pertencem ao adaptador e não devem ser exigidos pelo núcleo.

Contrato de Declaração de Capacidade

Os recursos são a promessa do adaptador para o núcleo. Eles devem ser conservadores.

PlatformCapabilities(
    platform="snowflake",
    supports_append=True,
    supports_overwrite=True,
    supports_merge=True,
    supports_hash_diff=True,
    supports_scd2=False,
    supports_snapshot_reconcile_soft_delete=False,
    supports_schema_evolution=True,
    supports_row_filters=True,
    supports_column_masks=True,
    supports_available_now_streaming=False,
    supports_expression_quality=True,
    supports_shape=False,
    supports_transform=True,
    evidence_stores=("audit_tables",),
    review_required_semantics=("historical", "snapshot_reconcile_soft_delete"),
)

Regras:

1. Declare supports_* = True somente quando o adaptador puder preservar a semântica ContractForge.
2. Use review_required_semantics quando a plataforma puder suportar o conceito, mas a equivalência depender do design.
3. Use supported_custom_write_modes apenas para manipuladores custom:<name> registrados no adaptador explícito.
4. Os adaptadores de produção devem fornecer pelo menos um valor evidence_stores.
5. Nunca defina um recurso como verdadeiro apenas porque a plataforma possui um recurso semelhante com comportamento diferente.

Semântica de resultados de planejamento

Os adaptadores devem preservar os quatro status de planejamento:

Status	Significado	Comportamento do adaptador
SUPPORTED	O contrato pode ser mapeado com comportamento equivalente.	Renderizar/executar normalmente.
SUPPORTED_WITH_WARNINGS	O contrato pode ser executado, mas existem ressalvas ininterruptas.	Transforme avisos em artefatos de revisão e evidências.
REVIEW_REQUIRED	A execução segura requer uma decisão de design humano/plataforma.	Renderizar artefatos de revisão; não execute automaticamente, a menos que o usuário permita explicitamente.
UNSUPPORTED	A semântica necessária não pode ser preservada.	Não renderize artefatos executáveis ​​como se fossem suportados.

Os adaptadores podem adicionar bloqueadores/avisos específicos da plataforma após o planejamento principal, mas não devem fazer downgrade silenciosamente.

Seções do contrato que os adaptadores devem compreender

O núcleo possui o vocabulário completo do contrato ContractForge. Os adaptadores estão em conformidade com isso.

Seção	Obrigação do adaptador
ingestion	Traduza origem, destino, modo de gravação, política de esquema, qualidade, formato e transformação.
annotations	Mapeie descrições de tabelas/colunas, tags, aliases, PII e metadados de ciclo de vida quando suportados.
operations	Persistir ou renderizar proprietário, SLA, criticidade, runbook e metadados operacionais.
access	Concessões de mapa, filtros de linha, máscaras de coluna e política de desvio ou revisão de retorno/sem suporte.
environment	Leia o adaptador, a localização das evidências e os parâmetros do adaptador. Nunca misture a semântica de ingestão com o ambiente.

Os adaptadores devem rejeitar ou avisar sobre contratos cujo environment.adapter tenha como alvo outra plataforma.

Requisitos de tradução de origem

A taxonomia da fonte principal é o ponto de partida:

Família de origem	Exemplos principais	Obrigação do adaptador
Catalog/lakehouse	table, delta_table, iceberg_table, view, sql	Mapeie para leituras de tabelas/consultas nativas ou revise se não houver suporte. Resolva referências lógicas principais (source.ref, source.table_ref, {{ table_ref:layer.table }}) para nomes qualificados nativos da plataforma dentro do adaptador.
Files	csv, json, parquet, delta, orc, text, avro, xml	Mapeie formatos para leitores nativos, preservando esquemas e opções.
Object storage	s3, adls, azure_blob, gcs, object_storage	Mapeie caminhos e credenciais sem vazar detalhes do SDK para o núcleo.
Incremental files	incremental_files	Mapeie para o mecanismo de rastreamento de arquivos da plataforma, por ex. Carregador automático, marcadores Glue, padrão Dataflow ou revisão.
HTTP file	http_file, http_csv, http_json, http_text	Suporta busca limitada ou tarefa nativa de revisão de renderização.
JDBC batch	jdbc, postgres, mysql, sqlserver, oracle, redshift, db2, etc.	Mapa URL/tabela/query/particionamento/auth; documentar as responsabilidades do motorista.
Bounded streams	kafka_bounded, eventhubs_bounded	Implemente apenas a reprodução de atualização, a menos que o adaptador tenha um design de streaming explícito.
Passagem nativa	native_passthrough	Renderize artefatos de conector/serviço nativos e revise as evidências.

Nomes específicos de plataforma, como autoloader, não devem se tornar entradas principais. As ferramentas de conversão podem reescrevê-los antes da validação.

Os adaptadores devem expor um pequeno catálogo de suporte de origem para que os usuários e as ferramentas possam inspecionar o que uma plataforma pode fazer sem ler os componentes internos do renderizador. O catálogo pertence ao adaptador e não deve ser importado pelo núcleo.

Recommended public shape:

def <adapter>_source_support(source: dict | str) -> dict:
    return {
        "adapter": "<adapter>",
        "source_type": "incremental_files",
        "status": "SUPPORTED",  # or REVIEW_REQUIRED / UNSUPPORTED
        "native_mapping": "Auto Loader cloudFiles",
        "note": "Uses core incremental_files/file_stream intent.",
    }


def list_<adapter>_source_support() -> tuple[dict, ...]:
    ...

contractforge_databricks.sources.list_databricks_source_support() e contractforge_aws.sources.list_aws_source_support() são a referência implementações. Eles classificam o mesmo vocabulário fonte principal de maneira diferente: Databricks maps incremental_files to Auto Loader, while AWS maps eligible Contratos incremental_files para marcadores e retornos de trabalho Glue REVIEW_REQUIRED quando a semântica do marcador não pode ser preservada.

As chaves de extensão do adaptador devem estar na lista de permissões do adaptador. Chaves desconhecidas devem emitir um aviso de planejamento e não deve ser honrado silenciosamente. O aviso de referência os códigos são DATABRICKS_UNKNOWN_EXTENSION e AWS_UNKNOWN_EXTENSION.

Requisitos do modo de gravação

Os adaptadores devem classificar explicitamente cada modo de gravação.

Modo de gravação	Requisito de adaptador
append	Anexar linhas sem reconciliar o destino.
overwrite	Substitua o alvo ou o escopo do alvo declarado atomicamente o suficiente para a plataforma.
upsert	Atualize o estado atual por meio de chaves estáveis; requer semântica de mesclagem/upsert.
hash_diff_upsert	Preserve a semântica de hash de linha ContractForge e a comparação do destino mais recente.
historical	Preservar linhas do histórico, marcador de linha atual, janelas de validade e política de atraso.
snapshot_reconcile_soft_delete	Reconcilie o instantâneo completo e marque as chaves ausentes como inativas/excluídas.
custom:<name>	Execute somente por meio de manipuladores explícitos registrados no adaptador.

Os adaptadores nunca devem fazer fallback de historical para anexar, de mesclar para anexar ou de reconciliação de captura instantânea para substituir sem um resultado de bloqueador/revisão.

Esquema, forma e transformação

Os adaptadores devem usar auxiliares de esquema principal para diferenciação neutra:

• compare_schema(source_schema, target_schema, allow_type_widening=...)
• validate_schema_diff(diff, policy)

O adaptador possui inspeção física e aplicação DDL/API.

Forma e transformação são intenções semânticas do ContractForge:

• parse JSON
• flatten
• array handling
• zip arrays
• cast
• derive
• standardize
• deduplicate
• composite keys

Se a plataforma não puder executar uma etapa de forma/transformação nativamente ou por meio de seu tempo de execução, o adaptador deverá retornar REVIEW_REQUIRED ou renderizar um artefato de materialização.

Requisitos de qualidade

As principais intenções de qualidade incluem:

• colunas obrigatórias
• não nulo
• unique key
• accepted values
• row count minimum
• max null ratio
• expression
• regras opacas personalizadas

Os adaptadores devem:

1. Avalie regras de qualidade suportadas ou renderize artefatos nativos de SQL/revisão.
2. Retorne QualityRuleResult com status/gravidade/contagens normalizadas.
3. Respeite o on_quality_fail em nível de contrato.
4. Persistir evidências de qualidade.
5. Preservar o comportamento de quarentena quando a gravidade for quarantine ou retornar um resultado de bloqueio/revisão.

Os registros de regras de qualidade customizados são de propriedade do adaptador porque podem depender de dialetos SQL, DataFrames ou APIs da plataforma.

Requisitos de governança

Os adaptadores devem apoiar estes contratos quando a plataforma tiver controles equivalentes:

ContractForge concept	Exemplos de mapeamento de adaptador
Descrições de tabela/coluna	Catalog comments, metadata API, data catalog descriptions.
Tags e apelidos	Tags nativas, rótulos, tags de política, metadados de classificação.
PII/sensitivity	Tags, taxonomia de políticas, revisão de políticas de mascaramento ou catálogo de segurança.
Grants	Permissões nativas GRANT/IAM/Lake Formation/Fabric.
Row filters	Políticas de acesso a linhas, filtros de dados, políticas de segurança.
Column masks	Políticas de mascaramento, tags de política, segurança em nível de coluna.
Drift/revoke unmanaged	Compare o estado declarado/atual e exija confirmação destrutiva explícita.

Se a herança de segurança ou a semântica da política forem diferentes, retorne REVIEW_REQUIRED.

Tabelas de evidências e controle

Cada adaptador de produção deve documentar sua estratégia de persistência para o modelo de evidência.

Os conceitos de evidência canônica são:

• run
• state
• lock/idempotency guard
• resultado de qualidade
• quarantine reference
• error
• mudança de esquema
• stream/bounded replay summary
• lineage event
• annotation application
• aplicação de acesso/governança
• metadados de operações
• diagnostics/explain
• cost signal
• metadados de estrutura/fonte

O adaptador Databricks usa tabelas de controle Delta com nomes ctrl_ingestion_*. Outros adaptadores podem usar tabelas de auditoria Iceberg, BigQuery, Snowflake, tabelas Fabric Lakehouse, artefatos de armazenamento de objetos ou armazenamentos de estado nativos. Os campos semânticos permanecem os mesmos.

No mínimo, os adaptadores de produção devem fornecer:

Superfície de evidência	Minimum requirement
Run ledger	Registros de execução consultáveis ​​com status, origem, destino, modo, métricas, carimbos de data/hora e resumo de erros.
State	Última marca d'água/estado bem-sucedido por destino.
Errors	Mensagem de erro e detalhes de diagnóstico redigidos.
Qualidade	Rule-level results.
Mudanças de esquema	Evidência de deriva detectada/aplicada.
Metadados de origem	Detalhes de origem e metadados de capacidade do conector editados.
Evidências de governança	Necessário quando o adaptador aplica anotações/acesso/operações.

Os adaptadores devem redigir os segredos antes da persistência.

Contrato Ambiental

O contrato de ambiente seleciona o contexto de execução e os parâmetros do adaptador.

environment:
  name: prod
  adapter: snowflake
  evidence:
    database: AUDIT
    schema: CONTRACTFORGE
  runtime:
    kind: warehouse
  parameters:
    snowflake:
      warehouse: INGEST_WH
      query_tag_prefix: contractforge

Regras:

1. environment.adapter deve corresponder ao pacote do adaptador.
2. environment.evidence informa ao adaptador onde armazenar as evidências.
3. environment.parameters.<adapter> é o mapa de parâmetros nativos de propriedade do adaptador.
4. O ambiente não deve conter origem, destino, modo, qualidade, anotações, operações ou semântica de acesso.
5. Os adaptadores devem ignorar blocos de parâmetros para outros adaptadores.

Renderizando artefatos

Os adaptadores devem renderizar artefatos executáveis ​​e de revisão.

Recommended artifact categories:

Artifact	Exemplos
Review report	Markdown explicando o status do plano, avisos, bloqueadores e limites de portabilidade.
Evidência de capacidade	Declaração de capacidade JSON e evidência de tempo de execução.
Artefatos de origem	SQL/leitura de scripts, configurações de conector, cópia de definições de trabalho.
Escrever artefatos	SQL MERGE, COPY, pipeline steps, job scripts.
Evidência DDL	Tabela de auditoria/controle DDL ou layout de armazenamento.
Artefatos de governança	Grants, tags, policies, row filters, masks.
Artefatos de implantação	Databricks Asset Bundle, Glue job script, Fabric pipeline JSON, Terraform.

A renderização não deve implicar execução quando o status de planejamento for REVIEW_REQUIRED ou UNSUPPORTED.

Padrão de execução em tempo de execução

A execução em tempo de execução deve ser de propriedade do adaptador e injetada com dependência.

Recommended pattern:

def ingest_platform_contract(
    contract: dict | SemanticContract,
    *,
    runner: PlatformRunner,
    options: PlatformIngestOptions | None = None,
    query_one: QueryOne | None = None,
) -> dict:
    ...

Regras:

• Aceite SemanticContract ou mapeamento validado.
• Normalize mapeamentos com semantic_contract_from_mapping.
• Planeje antes da execução.
• Require explicit override before executing REVIEW_REQUIRED plans.
• Use executores/clientes injetados em vez de importar sessões globais no momento da importação do pacote.
• Persistir evidências de execução/erro mesmo em caso de falha, quando possível.
• Retorne um resultado estruturado compatível com o tratamento de falhas principais.

Layout de pacote sugerido

Os adaptadores devem permanecer modulares e evitar arquivos divinos.

contractforge_<platform>/
  __init__.py
  adapter.py
  api.py
  environment.py
  capabilities/
    models.py
    evaluate.py
    mapping.py
  sources/
    artifacts.py
    runtime.py
  execution/
    append.py
    overwrite.py
    merge.py
    scd2.py
    snapshot.py
    results.py
  schema/
    diff.py
    sync.py
  quality/
    evaluation.py
    sql.py
    registry.py
  governance/
    annotations.py
    access.py
    drift.py
  evidence/
    schemas.py
    ddl.py
    writer.py
  runtime/
    orchestrator.py
    options.py
    finalization.py
  rendering/
    markdown.py
    bundle.py
  tests/

Os módulos adaptadores devem ser separados por domínio: origem, execução, governança, evidência, tempo de execução, renderização, capacidades e CLI.

Embalagem e publicação

Cada adaptador é publicado como sua própria distribuição Python. A roda adaptadora depende do contractforge-core; a roda central nunca depende ou empacota adaptadores.

Por exemplo, contractforge-databricks possui contractforge_databricks e o script de console contractforge-databricks. Ele não deve ser incluído na roda contractforge-core.

As regras de empacotamento do adaptador são definidas em publication-packaging.md.

Requisitos de teste para um adaptador funcional

Um adaptador minimamente confiável precisa de testes puros para planejamento e renderização, além de testes de tempo de execução com executores falsos.

Grupos de teste necessários:

Test group	Casos obrigatórios
Limite central	Núcleo de importação de adaptadores; core nunca importa adaptador.
Planejamento de capacidade	anexar, substituir, mesclar, histórico/revisão, suporte de governança e exigência de evidência.
Análise de contrato	ingestão, anotações, operações, acesso e ambiente.
Renderização de origem	catálogo, armazenamento de arquivos/objetos, JDBC, HTTP/passagem nativa quando suportado.
Gravar renderização/execução	todos os modos de gravação declarados e nenhum substituto silencioso.
Política de esquema	caminhos estritos, aditivos, de ampliação de tipo e bloqueadores.
Qualidade	evidências de aprovação/reprovação/aviso/quarentena.
Governança	anotações, concessões, filtros/máscaras de linha ou revisão obrigatória.
Evidência DDL	todo conceito de evidência canônica é representado ou explicitamente documentado como revisado/sem suporte.
Redaction	segredos e URLs confidenciais não são persistidos em evidências.
Failure handling	erros criam evidências e retornam/aumentam consistentemente.

Requisitos de documentação

Cada adaptador deve enviar documentação para:

1. Semântica ContractForge suportada.
2. Matriz de capacidade da plataforma.
3. Mapeamento de parâmetros de contrato.
4. Mapeamento de evidências/tabela de controle.
5. Suporte ao conector de origem.
6. Comportamento e limitações do modo de gravação.
7. Comportamento de governança/acesso.
8. Pré-requisitos e credenciais de tempo de execução.
9. Semântica conhecida de necessidade de revisão.
10. Unsupported semantics.

Para uso empresarial, não confie apenas em exemplos. Inclua tabelas explícitas mostrando como cada conceito canônico do ContractForge é mapeado para a plataforma.

Lista de verificação de aceitação do adaptador

Um adaptador é considerado funcional quando:

• It implements PlatformAdapter.
• It declares conservative PlatformCapabilities.
• Pode planejar um SemanticContract canônico.
• Ele renderiza artefatos de revisão para cada resultado de planejamento.
• Ele renderiza ou cria armazenamento de evidências.
• Ele mapeia todos os modos de gravação suportados sem downgrade silencioso.
• Ele pode persistir em um registro de execução, erros, resultados de qualidade e alterações de esquema.
• Ele documenta a semântica não suportada/requer revisão.
• Possui testes que comprovam que o núcleo permanece livre de plataforma.
• Ele expõe APIs públicos sem exigir importações de tempo de execução da plataforma no momento da importação do pacote.

Níveis de maturidade do adaptador

Funcional e estável são reivindicações diferentes. Use esses níveis de maturidade quando documentando um adaptador:

Level	Significado	Evidência necessária
Somente renderização	Produz artefatos de revisão/nativos, mas não executa trabalhos de plataforma.	Planejamento/renderização de testes e revisão de artefatos.
Runnable	Executa contratos simples com código de tempo de execução de propriedade do adaptador.	Testes de execução falsa e pelo menos um teste de smoke em tempo de execução real.
Validated	Executa fontes representativas, gravações, verificações de qualidade e caminhos de evidências de ponta a ponta.	Evidência repetível de ponta a ponta usando contratos e vinculações de ambiente documentadas.
Estável	Possui uma superfície suportada explícita, evidências repetidas de sucesso, tratamento de falhas, redação e limites de revisão documentados.	Matriz de capacidade pública, registros de evidências reais e nenhum rebaixamento semântico silencioso.
Production-certified	Adiciona runbooks operacionais, atribuição de custos, revisão de segurança, política de suporte e garantias de atualização.	Evidência operacional, aprovação de segurança e processo de suporte/reversão.

Estável não significa que todos os recursos da plataforma estejam implementados. Significa o superfície suportada documentada é explícita, testada, repetível e honesta sobre comportamento não suportado ou que requer revisão.

Pontos de partida específicos da plataforma

Plataforma	Provavelmente artefatos nativos	High-risk semantics
AWS	Trabalhos Glue, scripts EMR sem servidor, tabelas Iceberg, concessões Lake Formation, artefatos de auditoria S3, Terraform.	equivalência histórica, bloqueios/estado, filtros de linha, evolução de esquema, semântica de streaming.
Fabric	Data Pipelines, Lakehouse tables, Dataflow Gen2, OneLake paths, Purview/Fabric metadata.	Comportamento de mesclagem/SCD, máscaras/filtros, idempotência de pipeline, streaming e atribuição de custos.
Snowflake	Scripts SQL, tarefas, fluxos, armazéns, políticas de mascaramento, políticas de acesso de linha, tabelas de auditoria.	Semântica de exclusão reversível de instantâneo, política histórica de atraso, conectores de origem, atribuição de custos por consulta/tarefa.
GCP	BigQuery SQL/jobs, trabalhos de carga GCS, tabelas BigLake Iceberg, comando/leitura de registro Iceberg BigLake bruto, tabelas de evidências BigQuery, planejamento de política de esquema e aplicação limitada em tempo real, artefatos avançados de revisão de modo de gravação, políticas de acesso de linha, políticas de dados, tags de política, planejamento de reconciliação/ledger de governança, reconciliação de governança sem mutação leitura, gravação/leitura de evidências, criação de qualidade de dados Dataplex e planejamento de execução/leitura, execução/leitura explícita de comando de linhagem/aspecto Dataplex e um executor de implantação certificado do Google Workflows.	Streaming, modos de gravação avançados, ampliação/mutação automática de tipo, emissão automática de linhagem/aspecto Dataplex durante cada execução de contrato, executores de implantação não-Workflows, execução direta de caminho Iceberg bruto sem registro, auto-reparo/exclusão de governança e certificação de retenção de substituição permanecem fora da superfície estável do escopo até ser certificada separadamente.

O comportamento correto do adaptador não é "fazer funcionar de alguma forma". É preservar a semântica, alertar, exigir revisão ou rejeitar com clareza.