Contexto institucional

Este documento é a fonte de verdade institucional que ancora as decisões arquiteturais do roadmap. Sempre que uma decisão técnica for tomada, ela deve ser conectável ao que está aqui — caso contrário, é otimização local sem propósito.

CPPS — Centro de Pesquisa Política e Social (Unesp Franca)

Site oficial: cpps.franca.unesp.br

Missão: apoiar atividades de pesquisa de docentes e pós-graduandos da Unesp Franca, principalmente por meio do desenvolvimento e disponibilização de tecnologias digitais e infraestrutura computacional voltadas à pesquisa.

Herança institucional: o CPPS consolida trajetória prévia ligada ao LabRI (Laboratório de Relações Internacionais) da Unesp Franca, vinculado ao Departamento de Relações Internacionais (DERI). O LabRI já atuava na construção de soluções tecnológicas aplicadas às humanidades.

Vínculo no roadmap: site Franca (hosts pve-labri-*) é onde o CPPS opera fisicamente.

Lab Multiusuário do IPPRI — Instituto de Políticas Públicas e Relações Internacionais (SP, Praça da Sé)

Categoria: laboratório multiusuário — modelo internacional reconhecido por seu caráter compartilhado e interdisciplinar. Múltiplos grupos de pesquisa compartilham os mesmos recursos.

Origem do financiamento:

• Reserva técnica FAPESP pré-pandemia, vinculada ao INCT-INEU
• Ampliações por financiamentos institucionais
• Estruturação atual via projeto Equipamentos Multiusuários (EMU) da FAPESP, coordenado pelo Prof. Marcelo Mariano

Hardware viabilizado: servidores de alto desempenho com GPUs (A5000) e processadores AMD EPYC.

Finalidade: suporte tecnológico, metodológico e computacional para pesquisas em humanidades — com ênfase em Relações Internacionais, sem se restringir a essa área. Promove uso compartilhado de recursos e integração entre diferentes grupos de pesquisa.

Vínculo no roadmap: site SP/Praça da Sé (hosts pve-ippri-*) é onde o lab multiusuário do IPPRI opera.

Relação CPPS ↔ Lab Multiusuário do IPPRI

Articulação: complementar e integrada. Compartilham objetivo de fortalecer pesquisa em humanidades por meio de infraestrutura digital + colaboração interinstitucional.

Operação: integrada entre os campi de Franca e São Paulo — daí toda a discussão técnica de integração SP-Franca via UnespNet, ClusterMesh, ArgoCD por site, etc.

Iniciativa formal de consolidação: Colaboratório de Humanidades Digitais — visa consolidar a articulação entre os dois centros e abrir possibilidade de incorporação futura de outras unidades e grupos de pesquisa.

Personas e fluxos de uso

Persona	O que faz	Onde acessa
Pesquisador docente / pós-graduando	Pesquisa em humanidades; usa CAQDAS, OCR de acervos, análise textual, GraphRAG, treina/usa modelos GPU	Workstations Ryzen físicas + apps via web (Tutor, Invenio, OJS, Superset) + APIs de inference
Aluno em curso de pós-graduação	Consome conteúdo educacional, submete trabalhos	Tutor/Open edX (lms.colabh.org) via internet ou VLAN do lab
Grupo de pesquisa “convidado” (multi-grupo)	Pesquisador externo ao grupo proprietário usa lab multiusuário	Onboarding via SSO (Authentik) + recursos isolados por grupo
Coordenação institucional (Prof. Marcelo Mariano)	Acompanha uso, presta contas FAPESP	Relatórios de uso, dashboards de utilização
Admin de infra (você + colegas)	Opera, mantém, evolui	SSH, ArgoCD, Hubble, OpenObserve

Características institucionais que orientam a arquitetura

1. Multi-tenant cooperativo (não single-tenant)

Lab multiusuário FAPESP é categoria formal — vários grupos de pesquisa compartilham recursos. Não é “single-tenant trusted-but-curious”. É multi-grupo cooperativo com:

• Grupos com níveis variados de confiança entre si
• Compartilhamento controlado de recursos (GPU, storage, dados)
• Isolamento configurável entre projetos quando necessário

Implicação arquitetural: isolamento entre projetos importa. NetworkPolicy entre namespaces, RBAC granular, GPU sharing com quotas, audit por projeto deixam de ser “luxo de futuro” e viram MVP funcional.

2. Compromisso FAPESP (EMU) = accountability formal

Hardware adquirido via projeto FAPESP não é luxo — é entregável com prestação de contas:

• Relatórios de uso obrigatórios pra agência financiadora
• Demonstração efetiva de utilização = critério de continuidade
• Auditoria formal = realidade contratual, não hipótese

Implicação arquitetural: audit trail centralizado, métricas de uso por projeto/grupo, dashboards de utilização não são opcionais.

3. Foco em humanidades digitais

Casos de uso reais (não LLM inference genérica):

• Análise qualitativa de corpus (CAQDAS) — pesquisador na bancada
• OCR em larga escala de acervos, teses, microfilmes — batch jobs longos
• GraphRAG sobre textos acadêmicos — embeddings + vector search + RAG
• Repositório institucional (Invenio) — preservação digital
• LMS de pós-graduação (Tutor) — cursos com público real
• OJS — periódicos científicos com revisão por pares

Implicação arquitetural: plataforma GPU + plataforma de dados são meios pra fim acadêmico específico, não experimentos de tecnologia.

4. Colaboratório de Humanidades Digitais — expansão planejada

Não termina em 2 sites. Futuro inclui outras unidades e grupos de pesquisa.

Implicação arquitetural: replicabilidade da stack importa. Pulumi + Ansible + ArgoCD multi-cluster + IaC versionada viram requisito (não preferência estética).

5. Coordenação institucional (não só técnica)

Há professor coordenador formal (Marcelo Mariano), comitês UNESP, agência financiadora.

Implicação arquitetural: documentação tem público externo leitor (FAPESP, comitês, novos integrantes do Colaboratório). O Starlight existe parcialmente por causa disso. Decisões precisam ser explicáveis fora do time SRE.

Hierarquia de prioridades arquiteturais

Antes do contexto institucional, eu venha priorizando técnica:

1. Estabilidade operacional
2. Modularidade entre camadas
3. Frugalidade
4. Future-proof
5. Resiliência

Com o contexto institucional, a hierarquia muda:

1. Garantir uso efetivo do hardware EMU FAPESP
2. Multi-tenancy + isolamento entre grupos de pesquisa
3. Audit + reportabilidade (FAPESP, UNESP)
4. Onboarding fácil pra pesquisador externo (modelo multiusuário)
5. Replicabilidade pra Colaboratório expansão
6. Resiliência operacional
7. Frugalidade
8. Modularidade

Decisões puramente técnicas (Cilium vs Linkerd, LXC vs VM) ficam subordinadas à missão. O que importa antes é: o pesquisador do grupo X consegue rodar OCR no acervo Y sem brigar com o grupo Z, e o relatório FAPESP sai limpo no fim do ano.

Implicações que mudam decisões existentes

Várias decisões prévias precisam revisão à luz desse contexto:

ADR / decisão prévia	Reavaliação	Direção
ADR-002 — Cilium em LXC privileged	”Single-tenant institucional” não vale — lab é multi-grupo cooperativo	Reabrir trade-off com peso multi-tenant + audit
ADR-007 — Security stack deferida	Audit FAPESP é requisito, não hipótese	Hubble + audit log centralizado podem entrar antes
ADR-005 — GPU LXC standalone	OK como cluster separado, mas com multi-tenancy explícita	Adicionar GPU sharing fairness (HAMi/Kueue), quotas por grupo
Karmada deferido (ADR-004)	Mantém — ApplicationSet + ClusterMesh cobrem 2-3 sites	Reabrir se Colaboratório passar de 5 unidades
Backstage deferido	Reabrir — onboarding multi-grupo é caso de uso real	Considerar pra Fase 8 (em vez de “futuro indefinido”)
OpenCost futuro	Adiantar — attribution FAPESP por projeto	Entrar junto com observability MVP

Capacidades transversais que ganham peso novo

Coisas que eu venha tratando como “opcionais” agora viram prioritárias:

Capacidade	Status anterior	Status revisado
IAM granular por grupo (Authentik + RBAC + grupos de projeto)	Fase 8	MVP
Audit logs centralizados (Hubble + K8s audit + LINSTOR access)	“Quando precisar”	MVP (FAPESP)
Cost/usage attribution (OpenCost com tags por projeto)	Futuro	Antes da plataforma GPU em produção
NetworkPolicy entre namespaces (isolar projetos cooperantes)	“Defense-in-depth opcional”	Requisito multi-tenant
Self-service onboarding (Backstage ou similar)	Deferido	Avaliar com peso novo
Documentação pra leitor externo (FAPESP, comitês UNESP)	Implícito	Necessidade explícita
Métricas de uso por projeto/grupo (Prometheus labels, dashboards)	Operacional interno	Insumo de prestação de contas

Critério de decisão arquitetural

Antes de tomar qualquer decisão técnica, perguntar:

1. Como isso atende a missão do CPPS (apoio à pesquisa em humanidades)?
2. Como isso atende a finalidade do lab multiusuário (compartilhamento + interdisciplinaridade)?
3. Como isso suporta prestação de contas FAPESP (audit, métricas, reportabilidade)?
4. Como isso permite expansão futura (Colaboratório de Humanidades Digitais)?
5. Quem é o público externo leitor dessa decisão (FAPESP, comitês, novos parceiros)?

Decisão que não responde nenhuma dessas é otimização local — vale revisar.

Referências

• CPPS Unesp Franca — cpps.franca.unesp.br
• LabRI — Laboratório de Relações Internacionais (Unesp Franca, DERI)
• IPPRI — Instituto de Políticas Públicas e Relações Internacionais (Unesp São Paulo, Praça da Sé)
• INCT-INEU — Instituto Nacional de Ciência e Tecnologia para Estudos sobre Estados Unidos
• FAPESP EMU — Programa de Equipamentos Multiusuários da FAPESP