1. Decisão de projeto e hipótese de valor
Problema: os artefatos do LAC podem estar corretos isoladamente sem constituir uma experiência contínua e verificável. Hipótese: um aprendiz, com uma necessidade definida, pode percorrer uma representação estruturada, receber ajustes e orientação e demonstrar uma competência ao final, com evidências rastreáveis.
A aula particular invertida é o cenário piloto, não a definição ou o limite do LAC. Os resultados do piloto não comprovam automaticamente generalização para outros domínios.
2. Escopo e limites
Incluído no MVP
- Um tema e um objetivo de aprendizagem delimitados
- Conhecimento prévio e diagnóstico inicial
- Knowgrama com fontes, relações e explicações textuais alternativas
- Ao menos duas variantes de percurso por regra explícita
- Uma jornada de aprendizagem ponta a ponta
- Orientação humana e intervenção de IA opcional e identificada
- Avaliação antes/depois e registro de evidências
- Teste de usabilidade, acessibilidade básica e integridade
Fora do MVP
- Catálogo amplo de domínios e knowgramas
- Adaptação por EEG ou dados biométricos
- Agentes autônomos com ações não supervisionadas
- Personalização algorítmica complexa
- Integração obrigatória com LMS, CRM ou sistemas externos
- Certificação formal de aprendizagem
- Generalização comprovada para todos os perfis
Decisão pendente: selecionar o tema piloto, a população de teste e a forma de consentimento. Nenhuma métrica deve ser apresentada como resultado observado antes da execução.
3. Requisitos priorizados
| ID | Requisito verificável | Prioridade | Verificação |
|---|---|---|---|
| RF-01 | Registrar objetivo e necessidade do aprendiz no início da jornada. | Obrigatório | Teste de fluxo |
| RF-02 | Apresentar conhecimento prévio e diagnóstico inicial. | Obrigatório | Caso de teste |
| RF-03 | Exibir knowgrama navegável, explicações e fontes/proveniência. | Obrigatório | Inspeção e navegação |
| RF-04 | Selecionar ao menos dois percursos distintos por critérios explícitos. | Obrigatório | Testes com perfis distintos |
| RF-05 | Executar atividade, feedback e avaliação final. | Obrigatório | Jornada ponta a ponta |
| RF-06 | Registrar evento, percurso, versão de conteúdo e resultado sem exigir identificação pessoal. | Obrigatório | Auditoria de registros |
| RF-07 | Explicitar intervenção e limitações da IA; manter alternativa sem IA. | Obrigatório | Teste com IA ativada/desativada |
| RNF-01 | Operar com teclado, rótulos legíveis e texto alternativo à representação visual. | Obrigatório | Checklist de acessibilidade |
| RNF-02 | Evitar dados sensíveis; consentimento, minimização e retenção definida quando houver participantes. | Obrigatório | Revisão de privacidade |
| RNF-03 | Garantir integridade de links, referências e identificação de versões. | Obrigatório | Validação automatizada/manual |
| RF-08 | Exportar relatório consolidado de execução e evidências. | Desejável | Teste de exportação |
| RF-09 | Registrar e recuperar decisões, execução, evidências, pendências e homologações, vinculadas a requisitos e entregáveis. | Obrigatório | Teste de persistência e recuperação |
4. Dependências e interfaces
| Dependência | Origem / artefato de referência | Condição para integrar |
|---|---|---|
| Conceitos e metamodelo | Fundação do LAC / Modelo Conceitual de Referência / Metamodelo Estrutural | Entidades e relações estáveis para o piloto |
| Representação | Método de construção de knowgramas | Knowgrama revisado e proveniência explícita |
| Experiência | Mapa de jornada UX, blueprint do professor e do sistema | Interações e responsabilidades compatíveis |
| Instrução | Plano instrucional da aula invertida | Objetivo, atividade e avaliação alinhados |
| Qualidade | projeto/qualidade/plano_teste_jornadas.html; matriz_cobertura_jornadas.html | Casos de teste e critérios vinculados |
| Governança | Políticas de IA, privacidade, publicação e versionamento | Revisão e autorização para teste/publicação |
Referências arquiteturais indicativas: confirmar nomes, versões e existência dos arquivos antes de criar links operacionais.
5. Entregáveis e sequência
| ID | Entrega | Predecessor | Evidência de conclusão |
|---|---|---|---|
| E01 | Termo de escopo e caso piloto | — | Tema, público, objetivo e limites aprovados |
| E02 | Modelo mínimo integrado | E01 | Entidades, estados e interfaces documentados |
| E03 | Knowgrama validado | E02 | Fontes e relações revisadas |
| E04 | Motor de percurso por regras | E02, E03 | Dois perfis levam a caminhos distintos |
| E05 | Jornada executável e plano instrucional | E03, E04 | Fluxo integral demonstrável |
| E06 | Registro de eventos e avaliações | E05 | Trilha de evidências recuperável |
| E07 | Relatório de testes e melhorias | E06 | Falhas classificadas e decisões documentadas |
| E08 | Pacote piloto publicado | E07 | Homologação registrada |
| E09 | Modelo e estrutura de registros do MVP | E01, E02 | Registros identificados, recuperáveis e vinculados ao plano |
6. Papéis e responsáveis
Esta é uma proposta de responsabilidades por papel, não a designação de pessoas ou compromissos já assumidos. Uma mesma pessoa pode acumular papéis, desde que a revisão independente seja preservada quando viável.
| Atividade | Responsável pela execução (R) | Quem aprova (A) | Consultados (C) |
|---|---|---|---|
| Escopo e prioridades | Arquiteto do LAC | Autor / responsável pelo LAC | Professor, aprendiz |
| Modelo de conhecimento | Autor / modelador | Curador de conteúdo | Especialista do domínio |
| Plano instrucional | Designer instrucional | Professor | Mentor, aprendiz |
| Implementação e integração | Desenvolvedor / integrador | Responsável técnico | Arquiteto, UX |
| Orientação na jornada | Professor e/ou mentor | Professor | Aprendiz |
| IA assistiva | Serviço de IA sob configuração humana | Responsável pelo processo | Professor, governança |
| Testes e homologação | Testador / avaliador | Responsável pelo LAC | Aprendiz, professor, UX |
| Gestão de registros e evidências | Responsável pelo projeto / registrador | Responsável pelo LAC | Qualidade, governança, responsáveis pelas entregas |
A IA não assume responsabilidade institucional nem aprovação autônoma.
7. Critérios de aceitação e métricas
Os limiares abaixo são metas propostas para o piloto, a homologar antes do teste, e não resultados obtidos.
| ID | Critério de aceite | Como medir | Meta proposta |
|---|---|---|---|
| CA-01 | Jornada completa sem bloqueio crítico | Roteiro E2E | 100% dos cenários críticos aprovados |
| CA-02 | Adaptação demonstrada | Dois perfis e decisões registradas | 2 percursos diferentes, justificados |
| CA-03 | Rastreabilidade ponta a ponta | Amostra de execuções | 100% das execuções de teste vinculadas a objetivo, versão e avaliação |
| CA-04 | Aprendizagem observável | Pré/pós-teste e tarefa de aplicação | Melhoria ou domínio demonstrado segundo rubrica definida antes do piloto |
| CA-05 | Usabilidade observada | Tarefas com participantes e registro de dificuldades | Sem impeditivos graves pendentes |
| CA-06 | Acessibilidade mínima | Teclado, contraste, alternativas textuais | Checklist crítico integralmente aprovado |
| CA-07 | Conformidade de IA e privacidade | Auditoria de dados e interações | Nenhuma não conformidade crítica |
| CA-08 | Publicação íntegra | Validação de links e arquivos | Zero links internos quebrados no pacote piloto |
| CA-09 | Persistência e rastreabilidade dos registros | Criar, recuperar e relacionar DEC/EXE/EVD/PEN/HOM | 100% dos registros de teste recuperáveis e ligados a requisito ou entrega |
Uma melhora no pós-teste não prova causalidade isoladamente. Registrar limitações, perfil dos participantes, tamanho da amostra e condições de execução.
8. Registro de riscos
| ID | Risco | Impacto | Mitigação | Responsável por acompanhar |
|---|---|---|---|---|
| R01 | Expansão de escopo | Alto | Congelar tema e requisitos obrigatórios do piloto | Arquiteto |
| R02 | Modelos divergentes | Alto | Vocabulário e contratos mínimos compartilhados | Modelador |
| R03 | Adaptação apenas aparente | Alto | Registrar critérios e comparar percursos de perfis | Responsável técnico |
| R04 | IA gerar orientação incorreta | Alto | Fontes, limites, revisão humana e modo sem IA | Professor / curador |
| R05 | Ausência de evidência de aprendizagem | Alto | Rubrica e pré/pós-teste definidos antes da implementação | Designer instrucional |
| R06 | Problemas de acessibilidade | Médio/alto | Alternativa textual e teste com teclado desde o protótipo | UX / testador |
| R07 | Coleta indevida de dados | Alto | Minimização, anonimização e consentimento quando aplicável | Governança |
| R08 | Links e versões inconsistentes | Médio | Verificação antes da homologação | Integrador |
| R09 | Perda, inconsistência ou ausência de registros | Alto | Definir armazenamento, cópias, validação e controle de acesso | Responsável técnico / governança |
9. Matriz de rastreabilidade
Vincula necessidade → requisito → entrega → teste → critério de aceitação. Os identificadores de testes são propostos e devem ser sincronizados com os artefatos de qualidade existentes.
| Necessidade | Requisito | Entrega | Teste planejado | Aceite |
|---|---|---|---|---|
| N01 Compreender necessidade | RF-01, RF-02 | E01, E05 | CT-01 Entrada e diagnóstico | CA-01 |
| N02 Conhecimento confiável | RF-03 | E03 | CT-02 Conteúdo e fontes | CA-03 |
| N03 Ajustar percurso | RF-04 | E04 | CT-03 Comparação de perfis | CA-02 |
| N04 Aprender e aplicar | RF-05 | E05, E06 | CT-04 Jornada e pré/pós-teste | CA-01, CA-04 |
| N05 Auditar resultado | RF-06 | E06 | CT-05 Trilha de eventos | CA-03 |
| N06 Uso responsável de IA | RF-07, RNF-02 | E05, E07 | CT-06 IA com/sem serviço | CA-07 |
| N07 Uso acessível | RNF-01 | E05, E07 | CT-07 Teclado e texto | CA-05, CA-06 |
| N08 Publicar com integridade | RNF-03 | E08 | CT-08 Links e versões | CA-08 |
| N09 Preservar decisões e evidências | RF-09 | E09 | CT-09 Persistência, recuperação e vínculos | CA-09 |
10. Plano de execução e portas de decisão
Fase A · Delimitar
E01–E02: selecionar caso, atores, objetivo, critérios e contratos mínimos.
Porta A: escopo aprovado.Fase B · Construir
E03–E06: knowgrama, motor de percurso, jornada, avaliação e registros.
Porta B: execução ponta a ponta.Fase C · Verificar
E07: testes funcionais, instrucionais, UX, acessibilidade e privacidade.
Porta C: critérios críticos atendidos.Fase D · Publicar
E08: documentação, homologação e publicação controlada.
Porta D: pacote piloto íntegro.Checklist de acompanhamento local
Marque itens conforme avançar. O navegador não armazena o estado das marcações: registre a situação em documento de acompanhamento versionado.
0 de 8 itens marcados
11. Governança da versão e próximas decisões
Estado: proposta para revisão. Versão: 1.0. Data: 11/10/2026. Proprietário da decisão: responsável pelo LAC, a confirmar formalmente.
Decisões necessárias: escolher tema piloto; validar a rubrica; nomear responsáveis; confirmar contratos de dados; selecionar participantes e protocolo de teste; aprovar critérios de homologação.
Definição de sucesso: o LAC deixa de ser somente um conjunto de artefatos relacionados quando um usuário completa uma jornada integrada e o sistema consegue demonstrar, com registros e testes, o vínculo entre conhecimento, representação, adaptação, atividade e resultado.
12. Gestão de registros, evidências e rastreabilidade
Objetivo: documentar o que foi decidido, executado, observado e homologado, preservando vínculos verificáveis com requisitos, entregáveis, testes e critérios de aceitação. O plano estabelece as exigências; os registros demonstram a execução.
12.1. Classificação e localização
| Classe | Identificador | Local proposto | Conteúdo mínimo |
|---|---|---|---|
| Abertura do piloto | E01 | projeto/mvp_lac/planejamento/termo_abertura_piloto.html | Caso, objetivo, público, limites, autorização |
| Decisões | DEC-001… | projeto/mvp_lac/registros/registro_decisoes.html | Decisão, justificativa, autor, data, estado |
| Execução | EXE-001… | projeto/mvp_lac/registros/registro_execucao.html | Atividade, responsável, data, versão, resultado |
| Evidências | EVD-001… | projeto/mvp_lac/registros/registro_evidencias.html | Fonte/artefato, requisito, teste, resultado, localização |
| Pendências | PEN-001… | projeto/mvp_lac/registros/registro_pendencias.html | Problema, impacto, responsável, prazo/estado |
| Homologação | HOM-001… | projeto/mvp_lac/homologacao/relatorio_homologacao.html | Critérios, evidências, decisão, aprovador, data |
Atenção: os caminhos acima são destinos propostos, não arquivos já implementados. Um formulário HTML isolado não garante persistência; armazenamento, exportação, integridade e recuperação precisam ser definidos e testados.
12.2. Regras mínimas de gestão
- Identificação: código único, data, autor/responsável, estado, versão e histórico de alterações.
- Vínculos: requisito (RF/RNF), entrega (E), caso de teste (CT), critério de aceite (CA) e evidência (EVD), conforme aplicável.
- Responsabilidades: produtor registra, responsável pela entrega revisa, responsável pelo LAC homologa; quando viável, separar produção e aprovação.
- Persistência: selecionar posteriormente armazenamento adequado (por exemplo JSON versionado ou banco de dados), com cópia de segurança, recuperação e controle de alterações.
- Privacidade: separar registros de gestão dos registros de aprendizagem; limitar coleta de dados pessoais, acesso e retenção.
- Auditoria: permitir reconstruir o caminho decisão → execução → evidência → homologação.
12.3. Primeiro registro obrigatório
registro_decisoes.html e formalizar escopo e autorização no termo de abertura E01, antes de iniciar a implementação.12.4. Critério de aceite desta seção
Para homologar o MVP, uma amostra de registros deve ser criada, persistida, recuperada e associada aos requisitos, entregas e testes correspondentes (RF-09, E09, CT-09, CA-09). A existência da estrutura de pastas, por si só, não comprova o atendimento.