Pular para o conteúdo principal

Fronteira Atual do Produto

O Clinical Corvus opera dentro de um contrato de beta limitado. Esta página descreve o que o sistema suporta, o que não suporta, e onde clinician review é obrigatório.

Modelo de contrato

O sistema distingue entre três classes de requests:

ClasseComportamento
SuportadoResposta com evidência, rascunho ou síntese dentro do escopo
WarnedResposta provisória com incerteza declarada
BloqueadoRequest recusado com razão explícita

Suportado

  • Pergunta clínica com contexto de paciente ativo
  • Síntese de contexto e deltas para rounds
  • Rascunho de plano e lista de ações sob revisão do clínico
  • Expansão limitada de diferencial
  • I-PASS e handoff estruturado
  • Evidence retrieval com citação explícita
  • Smart Clipboard com ingestão de documentos e texto

Warned (incerteza explícita requerida)

  • Perguntas com contexto insuficiente
  • Requests onde evidência recuperada é fraca ou contraditória
  • Solicitações perto da fronteira do contrato de beta

Nessas situações, o sistema responde com incerteza declarada e não projeta confiança indevida.

Bloqueado

  • Diagnóstico autônomo final
  • Planejamento de tratamento automático
  • Advice irrestrito sem contexto clínico
  • Qualquer request que exija o sistema exceder o papel bounded de recomendação encoded no perfil de beta capability

Requisitos de revisão

Clínico review é parte do fluxo normal para todas as saídas, não uma excepcional.

  • Rascunhos de plano: você aceita, edita ou descarta
  • Evidence briefs: você abre as citações e valida contra protocolos locais
  • Handoffs: você revisa cada bloco antes de compartilhar

Fronteira não-autônoma

O Clinical Corvus não executa decisões clínicas de forma autônoma. O sistema não:

  • Finaliza diagnósticos sem revisão
  • Cria planos de tratamento que se auto-aprovam
  • Substitui o julgamento clínico
  • Opera como sistema de monitorização autônoma

A decisão final permanece com o clínico.

Validação e release

O sistema passa por uma gated validation antes de cada promotion:

  • Benchmark execution through canonical task pipeline
  • Dashboard replay review for alignment e uncertainty handling
  • Workflow e platform checks for state continuity
  • Operational signals check

Deployment decisions são staged e policy-aware, não benchmark-only.

Posicionamento para diligence

Esta fronteira não é um disclaimer temporário. É encoded nas routing e policy surfaces que determinam quais requests são allow, warn, ou block. Isso permite guarantees de segurança mais fortes do que seria possível em um sistema menos bounded.