# Kobow Studio Platform — Mock → Enterprise Migration Roadmap

**Versão:** 0.1 (draft)
**Data:** 2026-04-19
**Autor:** Juliano Machado + Claude (arquitetura)
**Escopo:** Plataforma Kobow completa — 5 studios (Finite Pool, Class III, Class II, Jackpots, RGS) + demo site + math pipeline

---

## 1. Resumo executivo

### Estado atual (MOCK)
Temos 5 studios funcionais como aplicações single-file HTML (~100KB cada), cada uma com IndexedDB local, dados de seed, e toda a lógica rodando client-side no navegador. Nenhum backend real, nenhuma autenticação real, nenhuma persistência multi-usuário. É um excelente **protótipo interativo de referência** — demonstra a arquitetura e serve de spec viva para implementação, mas **não é operável comercialmente**.

### Estado alvo (ENTERPRISE)
Plataforma multi-tenant regulada, operando em pelo menos 3 mercados-piloto (ex: Minnesota Tribal + Paraná Lottopar + um operador iGaming EU), com:
- RNG certificado (GLI-19/21, BMM ou iTechLabs)
- Database cluster Postgres 16 com TDE, RLS, DR cross-region
- CI/CD com rollback, canary deploys, artefatos assinados
- Observabilidade end-to-end (OpenTelemetry → Grafana/Loki/Tempo)
- Compliance LGPD + GDPR + NIGC + WLA-SCS + ISO-27001
- Runtime Kubernetes multi-region
- Segregation of duties entre math/compliance/ops/operator

### Timeline realista
**12–18 meses** do estado atual até o primeiro go-live comercial num mercado regulado, com 6–8 engenheiros em tempo integral, mais time de compliance/legal/regulatory separado.

### Budget aproximado (escala USA)
- **Engineering:** 6–8 pessoas × 12–18 meses = US$ 1.5M–3M
- **Infraestrutura:** US$ 15k–30k/mês em produção multi-region (≈ US$ 250k–500k/ano)
- **Certificações:** US$ 500k–1M (GLI-11/13/19/21 + WLA-SCS + ISO-27001 + por-jurisdição)
- **Legal/compliance:** US$ 200k–400k por mercado launch
- **Total estimado ano 1–2:** **US$ 3M–6M** antes de GTM

---

## 2. Inventário do que é mock hoje

### 2.1 Client-side only (tudo no navegador)
Hoje **100% da lógica roda client-side**. Isso inclui:
- Geração de paytables
- Shuffling de deals (Finite Pool)
- Simulação Monte Carlo
- Validação 5-layer
- Geração de jackpot contribution state
- Geração de artefatos (K8s, Helm, Terraform, .properties)
- Armazenamento de tudo em IndexedDB

**Risco regulatório:** em nenhuma jurisdição regulada você pode ter RNG ou geração de deals em cliente. Tudo precisa migrar para servidor auditado.

### 2.2 Dados
- **Persistência:** IndexedDB (isolado por navegador, apagável pelo usuário, sem sync, sem backup, sem audit real)
- **Multi-usuário:** inexistente — cada instância do navegador é uma cópia isolada
- **Audit log:** existe como tabela IDB mas não é WORM, não tem hash-chain enforced, não sobrevive a clear browser data

### 2.3 Autenticação
- Nome + email hardcoded como `{name:"Juliano Machado", email:"julianomachado@gmail.com"}`
- Zero RBAC
- Zero MFA
- Zero segregação de deveres

### 2.4 Math engine
- `Math.random()` (PRNG do V8/Chromium) — **reprovado em qualquer cert**
- Seed Monte Carlo determinístico (LCG) — ok para repro, não para jogo real
- Sem HSM, sem entropy source auditável

### 2.5 Integração entre studios
- "Integração" hoje = ler IDB `kobow_jackpots` de outro studio
- Cross-origin quando hospedado → não funciona
- Não há event bus, não há service mesh

### 2.6 Deploy
- `cp index.html` → pasta de outputs → VPS ou Cowork
- Sem CI, sem assinatura, sem rollback, sem canary

### 2.7 Compliance
- Regras declaradas na UI mas não enforçadas (ex: splits Lottopar 40/20/30/10 mostrados mas não aplicados a nenhum fluxo de dinheiro real)
- Certificações GLI listadas como requirements mas nenhum submission real feito
- LGPD/GDPR não endereçados (nome/email em plaintext no IDB)

---

## 3. Fundações da plataforma (bloqueia tudo mais abaixo)

Ordem importa: sem estes, nada mais avança.

### 3.1 Identity & Access Management (IAM)
- **Hoje:** hardcoded
- **Alvo:** SSO/OIDC (Auth0, Okta, Keycloak self-hosted, ou Clerk) + MFA obrigatório + RBAC com roles específicos de gaming (math_designer, compliance_officer, ops_engineer, operator_admin, auditor, regulator_readonly) + SCIM para provisioning + session timeout configurável + audit de login
- **Esforço:** 4–6 semanas, 1 SWE sênior
- **Blocker de:** multi-tenancy, audit real, submissions regulatórios

### 3.2 Database & persistence
- **Hoje:** IndexedDB
- **Alvo:** Postgres 16 cluster com:
  - Streaming replication + PITR (<5min RPO)
  - WAL archival para S3/MinIO com 7 anos de retenção
  - Transparent Data Encryption (TDE) at-rest
  - Row-Level Security por `operator_id` / `tribe_id` / `jurisdiction_id`
  - pgaudit → SIEM
  - PgBouncer em frente
  - Field-level encryption de CPF/SSN via KMS separado
  - Logical replication para read replicas analytics
  - Cross-region DR replica (hot standby + tested failover)
- **Esforço:** 8 semanas para setup + schema inicial, 2 SWE
- **Blocker de:** todos os studios migrarem para backend real

### 3.3 API & service layer
- **Hoje:** inexistente
- **Alvo:**
  - API Gateway (Kong, Envoy, ou AWS API Gateway)
  - REST + GraphQL public APIs
  - Internal service mesh com mTLS (Linkerd ou Istio)
  - gRPC entre serviços internos
  - Rate limiting, quota, API keys por operador
  - Swagger/OpenAPI specs geradas e publicadas
- **Esforço:** 6 semanas, 2 SWE
- **Blocker de:** integração cross-studio real, operator onboarding

### 3.4 Infrastructure as Code
- **Hoje:** `cp file.html` para VPS
- **Alvo:**
  - Terraform para toda infra (AWS ou GCP, multi-region)
  - Helm charts para cada serviço
  - ArgoCD ou Flux para GitOps
  - K8s cluster por region (us-east, us-west, sa-east pro Brasil, eu-west)
  - Network policies, PSP, Pod Security Standards
  - Cluster autoscaling + HPA
  - Secrets via external-secrets operator conectado a Vault/KMS
- **Esforço:** 6–8 semanas, 1 DevOps sênior
- **Blocker de:** staging real, production, DR drills

### 3.5 CI/CD pipeline
- **Hoje:** nenhum
- **Alvo:**
  - GitHub Actions ou GitLab CI
  - Build → unit tests → integration tests → security scan (Snyk/Trivy) → container build → signed artifact (cosign/sigstore) → staging deploy → smoke tests → manual approval → canary (5% → 25% → 100%) → prod
  - Automated rollback em SLO breach
  - SBOM por release
  - Deploy frequency target: daily para staging, semanal para prod
- **Esforço:** 4 semanas, 1 DevOps
- **Blocker de:** velocidade de entrega, response time de bug fix

### 3.6 Observability
- **Hoje:** `console.log`
- **Alvo:**
  - OpenTelemetry SDK em todo serviço
  - Logs: Loki + structured JSON
  - Metrics: Prometheus + recording rules + alerts via Alertmanager → PagerDuty
  - Traces: Tempo ou Jaeger, ≥10% sample rate em prod
  - Dashboards Grafana por serviço + golden signals por jurisdição
  - SLOs definidos: 99.9% availability pro RGS, 99.99% para wallet/settlement
  - Error budget tracking
  - SIEM (Splunk, Elastic, ou Chronicle) para security events
- **Esforço:** 6 semanas initial + ongoing, 1 SRE
- **Blocker de:** incident response real, regulator evidence

### 3.7 Secrets & KMS
- **Hoje:** nada
- **Alvo:**
  - Hashicorp Vault (ou AWS KMS + Secrets Manager, GCP KMS + Secret Manager)
  - Per-jurisdiction encryption keys (dados BR criptografados com chave BR, não compartilhada com EU)
  - Key rotation automatizada
  - HSM-backed para RNG seeds e signing keys
  - Zero secrets em código, config files ou envvars não criptografadas
- **Esforço:** 3 semanas, 1 SWE + compliance review
- **Blocker de:** LGPD compliance, certificações

### 3.8 Security baseline
- **Hoje:** nada
- **Alvo:**
  - WAF (Cloudflare, AWS WAF, or equivalent)
  - DDoS mitigation
  - Bot detection em endpoints de player
  - Vulnerability scanning continuous
  - Pen-test anual + após grandes releases
  - ISO-27001 certification
  - SOC2 Type II (para B2B SaaS para operadores)
  - PCI-DSS Level 1 (se processar pagamentos, mesmo via adapter)
- **Esforço:** 12–16 semanas para ISO-27001, paralelo a tudo
- **Blocker de:** contratos enterprise, reguladores estrangeiros

### 3.9 Data governance & privacy
- **Hoje:** nada
- **Alvo:**
  - Pseudonymization de PII em analytics
  - Consent management (LGPD art. 7º, GDPR art. 6)
  - Data retention policies por tabela (ex: spins → 7 anos, sessions → 2 anos, marketing → 90 dias)
  - DSR (Data Subject Request) automation — portal para exercer direitos LGPD/GDPR
  - DPIA documentation
  - DPO (Data Protection Officer) designado
  - Cross-border transfer contracts (SCCs para EU-US)
- **Esforço:** 8 semanas tech + legal em paralelo
- **Blocker de:** launch em BR, EU

---

## 4. Por-studio migration

### 4.1 Finite Pool Studio

| Item mock | Alvo enterprise | Esforço |
|---|---|---|
| `Math.random()` para deal shuffle | Certified RNG service (GLI-19/21) com HSM-backed seed | 8 wks + cert 16 wks |
| IDB para paytables | Postgres schema `paytables` com versioning git-like + approval workflow | 3 wks |
| Monte Carlo no navegador | Compute farm (Dask/Ray) + queueing + audited results com signed reports | 6 wks |
| Validation client-side | Backend service stateless + policy engine (OPA) para enforcement | 4 wks |
| Delivery `.zip` download | Signed artifact vault (hash-chained), assinatura com key em HSM, delivery via SFTP ou signed S3 URL | 4 wks |
| Hardcoded user/org | Multi-tenant por `org_id`, RLS em todas queries | 2 wks (depois do IAM) |
| Jurisdiction rules UI-only | Policy enforcement server-side com OPA ou equivalente | 4 wks |
| Audit log IDB | WORM table em Postgres + hash-chain + SIEM tap | 3 wks |

**Total Finite Pool:** ~34 semanas engineering + 16 semanas certification (paralelo)

### 4.2 Class III Slots Studio

| Item mock | Alvo | Esforço |
|---|---|---|
| Reel editor client-side | Reel definition as server-validated artifact | 3 wks |
| Símbolos e weights | Postgres schema + versioning | 2 wks |
| Simulação de linhas | Server-side paylines engine (reuse RNG service) | 4 wks |
| RTP math client | Backend math worker com signed output | 3 wks |
| Asset linking | CDN-backed asset library com DRM | 4 wks |
| GLI-11 cert | Lab submission de cada jogo | 8–12 wks cert per game |

**Total Class III:** ~16 semanas eng + per-game cert

### 4.3 Class II Studio

| Item mock | Alvo | Esforço |
|---|---|---|
| VGT reel sim client | Server-side com bingo card draw engine NIGC-compliant | 8 wks |
| Bingo card gen (`k-card`) | Certified bingo card generator + signed card files | 4 wks + cert 8 wks |
| Multi-tribe UI | Real tribal tenant isolation + tribal gaming commission reporting | 6 wks |
| Ball draw animation | Real-time WebSocket game session + audited ball draws | 6 wks |
| Slot-from-bingo derivation | Server-side derivation, math validator enforcing NIGC Class II rules | 4 wks |

**Total Class II:** ~28 semanas eng + NIGC lab approval

### 4.4 Jackpot Studio

| Item mock | Alvo | Esforço |
|---|---|---|
| Pool state em IDB | Real-time jackpot service (Redis + Postgres) com atomic increments | 6 wks |
| Contribution state machine UI | Kafka/Redpanda event stream: `WagerRecorded` → `ContributionCalculated` → `PoolIncremented` | 6 wks |
| Cross-game attach via IDB | gRPC service com operador-level policy (ex: pool MA só em games na jurisdiction MA) | 4 wks |
| Trigger animation UI | Real wins com settlement: jackpot hit → operator wallet credit + ledger entry + regulator notification | 4 wks |
| Must-hit-by timer | Real countdown with persisted state, survive restart | 2 wks |
| Progressive math | Audited contribution splits + overflow handling + reserve pool | 4 wks |

**Total Jackpot:** ~26 semanas eng

### 4.5 RGS & Delivery Studio

| Item mock | Alvo | Esforço |
|---|---|---|
| Artifact generators in-browser | Real artifact pipeline: build from git → sign → push to artifact registry | 4 wks |
| Profile seed data | Profiles armazenados em Postgres, editáveis via RBAC | 2 wks |
| Node catalog estático | Real node registry conectado a Kubernetes cluster state | 4 wks |
| Topology diagram mock | Live topology derivada de cluster state (ArgoCD ApplicationSet → topology view) | 4 wks |
| Storage architecture docs | Docs live + runbooks + DR drill logs | 2 wks |
| Game deployment UI | Real deployment controller que pega signed artifact e deploya via ArgoCD | 6 wks |
| Migration state machine | Real location migration com Kafka events + downtime window + player notification | 6 wks |
| CMS reporting UI | Integração com sistemas CMS reais (Lottopar SIGAP API, NY Gaming Commission CMS, ADM Sogei) | 8 wks per market |
| Session monitor fake | Live session data via Kafka consumer | 4 wks |
| Certification tracking | Real cert submission portal integrations onde disponível + internal workflow | 4 wks |

**Total RGS:** ~44 semanas eng

---

## 5. Cross-studio integration

Estes são os fluxos que hoje são "mock" porque dependem de IDB sharing, mas precisam ser event-driven em produção:

### 5.1 Math → Delivery
- **Hoje:** designer exporta seed JSON, RGS artifact generator lê e cospe .properties
- **Alvo:** git-like flow: math PR → validation pipeline → approval → signed artifact → registry → RGS discovers → deploy a target profile via ArgoCD

### 5.2 Jogo → Jackpot
- **Hoje:** jogo escreve contribution em IDB compartilhada
- **Alvo:** jogo emite `WagerRecorded` via Kafka → Jackpot Service consume → atomic increment em Redis + Postgres → ack → jogo prossegue

### 5.3 Game Session → Wallet
- **Hoje:** inexistente
- **Alvo:** session manager emite `WagerRecorded` e `WinPaid` → wallet adapter específico do operador (Evolution, Pragmatic, Playtech, custom) → ledger entry + settlement batch nightly

### 5.4 Regulator reporting
- **Hoje:** UI mostra reports mas não envia
- **Alvo:** scheduled jobs geram reports assinados → entregues via SFTP/API para cada regulador (Lottopar SIGAP, NIGC MICS, ADM, UKGC, etc.) com audit trail

### 5.5 Incident → Postmortem
- **Hoje:** incidents view estático
- **Alvo:** PagerDuty → auto-create incident channel → postmortem template → compliance officer review → filed with regulator se required por SLA (ex: GLI-19 exige notificação de degradation <2h)

---

## 6. Regulatory & compliance work

Independente do tech, estes trabalhos legais/regulatórios têm timelines próprios e **não são paralelizáveis** com eng sprints normais.

### 6.1 Por mercado

| Mercado | Licenças/certificações | Timeline | Custo estimado |
|---|---|---|---|
| **Minnesota Tribal** | Tribal gaming agreement + NIGC approval + state compact | 6–12 meses | US$ 100k–250k |
| **Paraná (Lottopar)** | Licença Lottopar + homologação + sistema conectado SIGAP | 6–12 meses | R$ 500k–1M |
| **EU B2C** | MGA (Malta) ou UKGC | 9–18 meses | €200k–500k |
| **US iGaming (NJ/PA/MI)** | State-by-state licensing | 12–24 meses per state | US$ 500k–1M per state |
| **Italy VLT (ADM)** | Concessione ADM + connessione Sogei | 18–24 meses | €500k–1M |

### 6.2 Testing labs (GLI, BMM, iTechLabs)

| Standard | Escopo | Lab | Duração | Custo |
|---|---|---|---|---|
| GLI-11 | Gaming devices | GLI/BMM/iTech | 8–12 wks per device | US$ 30k–80k |
| GLI-13 | Electronic bingo | GLI/BMM | 8–12 wks | US$ 30k–60k |
| GLI-19 | Interactive gaming | GLI | 12–16 wks | US$ 50k–100k |
| GLI-21 | Client-server systems | GLI | 12–16 wks | US$ 50k–100k |
| GLI-33 | Event wagering | GLI | 12–16 wks | US$ 40k–80k |
| WLA-SCS | World Lottery Security Controls | WLA | 16–24 wks | US$ 100k–200k |

### 6.3 Standards corporativos
- **ISO-27001:** 12–18 meses, ~US$ 80k–200k
- **SOC2 Type II:** 12 meses window + audit, ~US$ 60k–120k
- **PCI-DSS Level 1:** 6–9 meses, ~US$ 40k–100k + ongoing
- **LGPD:** audit + implementation ~US$ 50k–150k
- **GDPR:** similar, overlap com LGPD

---

## 7. Operações (run book)

### 7.1 SRE
- 24/7 on-call rotation (mínimo 4 SREs para rotação humana sustentável)
- Runbooks publicados para cada alerta
- DR drill trimestral
- Chaos engineering em staging (GameDay)

### 7.2 Security ops
- SIEM monitoring 24/7 (ou terceirizado via MDR)
- Vulnerability management cadence semanal
- Access review trimestral (revogar acesso de ex-funcionários etc.)
- Threat modeling para cada feature nova

### 7.3 Compliance ops
- Compliance officer dedicado por jurisdição grande
- Monthly compliance review
- Quarterly self-assessment
- Annual external audit

### 7.4 Finance / settlement
- Daily reconciliation operator ledger ↔ Kobow ledger
- Monthly settlement
- Fraud detection (ML model + rules engine)
- Chargeback handling

---

## 8. Go-to-Market

### 8.1 Operator onboarding
- Self-service portal (com manual review antes de go-live)
- Sandbox environment pra testes pré-produção
- Integration support team
- SLA contracts

### 8.2 Player data & analytics
- Integrar com seu player archetype framework (14 famílias + R1–R4) como real-time scoring
- RFM/ADT como serviço pros operadores
- BI dashboard pros operadores

### 8.3 Sales / partnerships
- Regional sales leads
- Channel partners (integrators, consultancies)
- Regulator relations

---

## 9. Priorização proposta — Fases

### Fase 0 — Fundações (mês 0–3)
Sem isso, **nada** mais pode ir pra produção.

- [ ] IAM / SSO
- [ ] Postgres cluster + schema base
- [ ] Vault / KMS
- [ ] Terraform + Kubernetes base
- [ ] CI/CD pipeline
- [ ] Observability stack
- [ ] API gateway
- [ ] Security baseline (WAF, vuln scan)

**Entregável:** "hello world" serviço deployed via pipeline completo, monitorado, rollback tested.

### Fase 1 — Migração de studios (mês 3–9)
Mover cada studio de IDB para backend real, mantendo a mesma UX.

- [ ] Finite Pool → backend
- [ ] Class III → backend
- [ ] Class II → backend
- [ ] Jackpot → backend (mais crítico — real-time)
- [ ] RGS → backend

**Entregável:** todos os studios rodando contra Postgres + API, multi-user, com audit real.

### Fase 2 — Runtime de jogo (mês 6–12, paralelo com Fase 1)
Certified RNG + game session manager + wallet adapters.

- [ ] Certified RNG service (GLI-19 cert em paralelo)
- [ ] Game session state machine
- [ ] Wallet adapter framework (pelo menos 2 adapters para piloto)
- [ ] Settlement engine
- [ ] Fraud detection básico

**Entregável:** jogos rodando contra runtime real, com dinheiro de play-money, auditable.

### Fase 3 — Integração real (mês 9–15)
Kafka event streaming entre serviços + real jackpot pools + real regulator feeds.

- [ ] Kafka/Redpanda deployment
- [ ] Event schemas + schema registry
- [ ] Jackpot service real-time
- [ ] Regulator report generators (SIGAP, CMS, etc.)
- [ ] Cross-studio flows end-to-end

**Entregável:** plataforma funcional end-to-end em play-money.

### Fase 4 — Certificação + primeiro mercado (mês 12–18)
- [ ] GLI labs submissions
- [ ] ISO-27001 cert
- [ ] LGPD / GDPR audit clean
- [ ] Primeiro mercado regulatory approval (sugestão: MN Tribal ou Paraná Lottopar)
- [ ] Operator integration com pelo menos 1 operator piloto
- [ ] Security pen-test + remediation

**Entregável:** **primeiro mercado go-live com money real**.

### Fase 5 — Escalar (mês 18+)
- [ ] Mercados adicionais
- [ ] Mais operadores
- [ ] Expansão de produto (scratch, sports betting, etc.)

---

## 10. Riscos principais

1. **Certificação atrasa** — GLI-19 pode demorar 6+ meses. Começar cedo.
2. **Regulator approval unpredictable** — Lottopar e NIGC têm timelines próprios, sem SLA.
3. **Talent scarcity** — engenheiros com experiência em RNG certificado, gaming regulado, são raros. Provisão 30% buffer.
4. **Funding runway** — US$ 3M–6M em ano 1–2 sem receita. Precisa captação ou bridge financing.
5. **Regulatory drift** — leis mudam (ex: SIGAP evolui, LGPD Data Protection Authority ainda define guidance). Budget legal contingency.
6. **Security incident pre-cert** — mesmo em staging, breach pode atrasar certification 6+ meses.
7. **Scope creep** — tentação de adicionar feature antes de terminar fundação. Disciplina importante.

---

## 11. Perguntas abertas (precisam decisão antes de começar)

1. **Qual mercado piloto?** Minnesota Tribal (relacionamento existente via Diamond), Paraná Lottopar (mercado doméstico), ou EU via Malta (mercado internacional mais fácil)?
2. **Modelo de receita?** B2B SaaS (supplier model — Kobow licencia software para operadores), rev-share (Kobow é parte de cada aposta), ou híbrido?
3. **Build vs buy?** Ex: usar um RGS existente (White Hat, SBTech) ou continuar com Kobow RGS? Usar wallet de terceiros ou próprio?
4. **Cloud provider?** AWS (mais integrações de gaming, mas tax implications BR), GCP (melhor pricing LatAm), ou multi-cloud?
5. **Data residency?** BR users → BR (LGPD art. 33), EU users → EU (GDPR). Custo de multi-region.
6. **Open source strategy?** Publicar componentes (ex: o validator de paytables) open-source pra credibilidade regulatória, ou fechar tudo?
7. **Team structure?** Centralized eng ou distributed (math team, platform team, compliance team, per-market team)?
8. **Founders em tempo integral?** Atualmente você está solo. Precisa CTO full-time em algum momento da Fase 0–1.

---

## 12. Próximos passos recomendados

**Semana 1–2:**
1. Alinhar com stakeholders (se houver) em qual mercado piloto
2. Orçamento detalhado de Fase 0 (3 primeiros meses)
3. Hiring plan: quem precisamos em qual ordem

**Semana 3–4:**
1. Technical ADR writeup pra cada decisão grande (cloud, DB, runtime, etc.) — podemos usar o skill `engineering:architecture`
2. RFI para GLI lab (começar conversa cedo)
3. Talk to Lottopar ou NIGC informalmente pra entender processo

**Mês 2–3:**
1. Arrancar Fase 0 com um time de 3–4 SWE + 1 DevOps
2. Paralelo: iniciar ISO-27001 pre-audit gap analysis

---

## 13. Como esse doc deve ser usado

Este é um **living document**. Recomendo:

1. Migrar pra uma view nova no **RGS Studio** chamada "Enterprise Migration" pra consultar rapidamente
2. Cada linha do Fase 0/1/2/3/4/5 vira um épico no tracker (GitHub Projects, Linear, Jira)
3. Revisar mensalmente e reduzir estimativas conforme aprendemos
4. Usar como pitch deck base pra investidor (slides 7–15 dum fundraise deck)

---

*Documento gerado com base no estado atual das 5 apps em `/app-rebuild/`, documentação histórica (Distributor 2019–2023), requirements Lottopar/NIGC/GLI públicos, e experiência de arquitetura em sistemas regulados.*