Regra: Cálculo do Score BRAND para Nomes de Módulos Koder

Usar este spec sempre que for necessário sugerir, avaliar ou comparar nomes de módulos, produtos, serviços ou APIs Koder. O modelo é o mesmo implementado em tools/namer (https://namer.koder.dev) — este arquivo é a fonte normativa da lógica.

Visão geral

O Brand score é um número 0–100 (maior = melhor) que combina 4 dimensões, todas também 0–100 no mesmo sentido:

Os pesos não são globais — dependem de como o nome é consumido (§Perfis de peso).

Cada dimensão é calculada primeiro como penalty (0 = perfeito, cresce com violações) e depois convertida pra 0–100 via função exponencial suavizada.

Fórmula de conversão (penalty → score 0–100)

score100 = round(100 · e^(-k · penalty_per_letter))

Onde penalty_per_letter = penalty_total / número_de_letras_mapeadas e k é uma constante por dimensão, calibrada pra nomes curtos de marca:

Composição final:

Brand = round(w.type·Type + w.pron·Pron + w.son·Son + w.mem·Mem)

Perfis de peso (NAMER-009)

O composto era global — 0.35·Type + 0.30·Pron + 0.20·Son + 0.15·Mem — e a typability dominava um score de marca.

Medido: kapa pontua 100/100/100 em pron/son/mem e mesmo assim perdia para kamaleon (100/91/78), porque k-a-p-a é caro de digitar em QWERTY. O ranking estava sendo decidido por esforço de digitação.

Causa-raiz: o Namer nasceu ferramenta de typability (o koder.toml ainda registra: "scores words … across typability and soon pronunciability, sonority, memorability"). As outras três dimensões chegaram depois; o peso não acompanhou a mudança de propósito da ferramenta.

O 0.35 não estava errado — estava errado como default global. Um nome digitado o dia inteiro (kvs, kdb, CLI, import path) e um nome lido e falado (produto, landing, conversa) não têm o mesmo trade-off, e nenhum número único serve aos dois. Daí perfis, não um rebalanceamento global:

Todo perfil soma 1.00. tool preserva deliberadamente o 0.35 histórico: é o caso em que ele sempre fez sentido.

API: analyze(text, layout, lang, { profile: 'brand' }). Perfil desconhecido ou ausente cai em balanced. O resultado devolve profile e weights — o número nunca é interpretável sem saber sob qual peso saiu.

Resolução automática pelo path (NAMER-011)

Um perfil que só funciona quando quem chama lembra de passá-lo funciona por exceção, não por regra. analyze(nome, layout, lang, { path }) resolve sozinho pela taxonomia RFC-003:

A ordem de teste importa: products/dev/ é avaliado antes de products/, porque é a exceção genuína. É o caso ambíguo assumido do modelo — um produto de dev pesa nos dois lados, e a escolha foi pelo custo diário e repetido.

{ profile } explícito sempre vence { path } — quem conhece o caso concreto sabe mais que a heurística.

Alinhamento com §Alvos por tipo de módulo: as categorias de perfil e a tabela de alvos respondem perguntas diferentes — o perfil diz como pontuar, o alvo diz quanto basta. Um produto flagship usa perfil brand e alvo 75+; uma ferramenta de dev usa perfil tool e alvo 50+.

Efeito medido (140 nomes de módulo, balanced × pesos antigos): 113 subiram, 24 desceram, 10 nomes voltaram a cumprir o §305, 2 saíram (flash, s). kapa 78 → 88, agora acima de kamaleon (84) — a inversão que motivou o ticket.

Bandas de rating

Modo de leitura: grafema × fonema (NAMER-010)

Um nome é pontuado sobre duas representações. kdb nunca é lido como palavra — é soletrado (ka-de-be). Pontuar a escrita produzia quatro penalidades que só existem no papel (sem vogal, run de 3 consoantes, 0% de alternância CV, 0 sílabas).

realize(nome, lang, opt) → { mode, grafema, fonema }

Modo

O override explícito vence qualquer inferência e é obrigatório na API: a heurística erra em casos reais — NASA é escrita como sigla mas lida como palavra, enquanto SQL é lida como letras. Sem override, o modelo erraria com confiança. hybrid exige a forma falada declarada ({ mode, phoneme }), porque inferir "letra + palavra" transformaria kapa em "k+apa".

Nomes de letra (expansão)

en-US: a=ay b=bee c=see d=dee e=ee f=ef g=gee h=aitch i=eye j=jay k=kay l=el m=em n=en o=oh p=pee q=cue r=ar s=ess t=tee u=you v=vee w=doubleu x=ex y=why z=zee

pt-BR: a=a b=be c=ce d=de e=e f=efe g=ge h=aga i=i j=jota k=ka l=ele m=eme n=ene o=o p=pe q=que r=erre s=esse t=te u=u v=ve w=dablio x=xis y=ipsilon z=ze

⚠️ ASCII-normalizado por contrato. Caracteres acentuados são descartados pelo mapa de layout (com warning) e não entram na contagem de letras, que é o divisor de toda penalidade. ká-dê-bê corromperia o score; usa-se kadebe.

Roteamento — qual critério lê qual representação

Divisor: penalidade grafêmica divide pelo comprimento escrito; fonêmica, pelo falado (penalty / letras_da_representação).

Um eixo, um dono (NAMER-006)

O mesmo cluster era cobrado três vezes: memorability (CV alternation, global), sonority (pares CC/VV) e pronunciability (escada de run). Ruído correlacionado, não rigor. A propriedade agora é exclusiva:

O critério CV alternation foi removido da Memorability: era duplicata grosseira e global do que a Sonority agora mede por grupo.

effectiveVowels — y como núcleo

y é semivogal: vira núcleo quando a palavra não tem nenhuma vogal do conjunto da língua. Sem essa regra, krypt em pt-BR (cujo conjunto exclui y) seria lido como um grupo de 5 consoantes e levaria custo superlinear. A mesma razão pela qual a detecção de modo (§Modo de leitura) usa conjunto permissivo: o y carrega sílaba em nome.

Dimensão 1 — Typability (k = 0.65)

Modelo inspirado no Carpalx, calibrado pra nomes curtos de marca.

Custos por tecla (QWERTY US)

Row cost: home = 0 · upper = 1 · lower = 1.5 Finger cost (índices 0=L-pinky … 7=R-pinky):

[2, 1, 0.5, 0, 0, 0.5, 1, 2]

Cada letra soma row_cost[row] + finger_cost[finger] no base_effort.

Modificadores por par de letras consecutivas

1. Same-finger bigram (SFB) — duas letras no mesmo dedo:

• Penalty: 2 · max(1, |row_a − row_b|)
• Exemplos:
  • de (ambos L-middle, home→upper, rowDist=1) → +2
  • my (ambos R-index, home→upper, rowDist=1) → +2
  • br (ambos L-index, lower→upper, rowDist=2) → +4

2. Hand alternation bonus — letras em mãos diferentes: −0.5 por transição.

3. Common bigram bonus — pares na lista curada de ~50 bigrams mais comuns do inglês: −0.4 por ocorrência. Lista:

th, he, in, er, an, re, on, at, en, nd, ti, es, or, te,
of, ed, is, it, al, ar, st, to, nt, ng, se, ha, as, ou,
io, le, ve, co, me, de, hi, ri, ro, ic, ne, ea, be, di,
li, ra, sa, ma, ta, el, la, si, ch, no, fo

Fórmula

type_penalty = base_effort
             + Σ(SFB_penalty)
             − 0.5 · alternations
             − 0.4 · common_bigrams_hits

Type = round(100 · e^(-0.65 · type_penalty / letters))

Dimensão 2 — Pronunciability (k = 1.20)

Wellformedness fonotática em inglês.

Vogais (inclui y): a, e, i, o, u, y. Todo o resto é consoante.

Penalidades

Lista curada de bigrams raros (~55 pares awkward em inglês)

pf, mk, gb, kp, pk, td, dt, kt, tk, fk, kf, vk, kv,
bw, wb, gw, wg, pz, zp, dq, qd, xk, kx, qp, pq, zk, kz,
hj, jh, rj, jr, vn, nv, vm, mv, mj, jm, bm, mb, dg, gd,
lk, kl, sr, rs, fn, nf, pn, zh, fm, mf, zr, rz, wr, rw

Pron = round(100 · e^(-1.20 · pron_penalty / letters))

Dimensão 3 — Sonority (k = 1.50)

Sequenciamento silábico limpo. Ideal: consoantes separando vogais (CV, CV, CV).

Penalidades

Mede peso/fluência do encadeamento sobre GRUPOS (não pares), com escala superlinear, descontado quando o grupo é unidade legal de um gesto.

Son = round(100 · e^(-1.50 · max(0, son_penalty) / letters))

Fechamento silábico (NAMER-008)

A escada de coda já existia espalhada — o que faltava era o degrau de cima:

Por isso o critério não reimplementa a escada inteira (seria a tripla contagem que o §Um eixo, um dono acabou de eliminar): acrescenta só o degrau ausente.

Dono: Sonority. A pergunta é "quanto pesa?", não "é legal?" — consoante final é perfeitamente legal, apenas fecha a sílaba. A legalidade da coda continua sendo da Pronunciability. Um final ilegal paga nas duas, pelo mesmo motivo que um cluster ilegal já pagava (§Um eixo, um dono): são perguntas diferentes.

Por que é custo do fechamento, e não bônus da vogal

O ticket pedia bônus para terminação vocálica. O modelo não comporta bônus: score = 100·e^(−k·pen/len), logo penalidade 0 já é nota 100 — não há headroom acima. Um delta negativo em kapa/koda (cuja Sonority já é 0) some no piso max(0,·), e o incentivo sai invertido: só nome com cluster consegue gastar o bônus.

Medido: com a versão em bônus, kroma (tem kr pra abater) ganhava +1 e kapa/koda — os nomes que o critério existe pra premiar — não ganhavam nada.

A ordenação relativa desejada é idêntica cobrando o complemento. Vale como regra geral do modelo: todo "bônus" aqui precisa ser expresso como penalidade do oposto — a mesma razão pela qual o antigo bônus de repetição era largamente inerte (§Dimensão 4).

Constantes por idioma

• pt-BR 0.10 — vogal final é a norma, então fechar é levemente marcado. Pequeno de propósito: -r (infinitivos), -s (plurais), -l, -m são correntes em português; um peso alto puniria metade da língua.
• en-US 0 — consoante final é nativa (cover, skin, kit). Cobrar aqui importaria viés pt para a língua de autoria dos produtos Koder (policies/language.kmd). O critério é avaliado nos dois perfis — o custo é que é legitimamente zero em inglês.

finalOk para en-US — e por que clusters viraram flag

O perfil en-US não tinha finalOk nenhum: consoante final era irrestrita em inglês e rigorosamente avaliada em pt — legalidade de coda existia em metade dos perfis, o mesmo buraco que o NAMER-006 fechou nos onsets. Agora existe, e é permissivo: só j e q nunca são finais em inglês.

Mas "nenhum cluster final" é fato do português, não universal — virou a flag noFinalClusters do perfil pt em vez de ser o comportamento implícito de "tem finalOk".

Medido: uma primeira tentativa que enumerava clusters finais legais em inglês (whitelist) derrubou 13 nomes reais — pass 63→42, shell 73→55, dev 65→48. A fonotática final do inglês é permissiva demais para caber numa whitelist; quem filtra o que é genuinamente estranho lá já é RARE_BIGRAMS + a regra de coda ≥3.

Dimensão 4 — Memorability (k = 2.00)

Penalidades e bônus

Repetição adjacente ≠ distribuída (NAMER-007)

Eram um sinal só, 1 − únicas/total, posicionalmente cego — o que dava bônus pra letra dobrada e pontuava kappa e kalak igual. São dois fenômenos opostos:

A distribuída mede no fonema com os runs colapsados (kappa → kapa): pp é um som, não uma rima interna. Sem colapsar, a letra dobrada voltaria a virar bônus — o defeito original.

A adjacente mede no grafema porque o custo é ortográfico ("Kappa, com dois pês?"), não fônico: quem ouve o nome não sabe escrevê-lo. A escala é a mesma superlinear do clusterCost (§Dimensão 3): n=2 → 1×, n=3 → 3×, n=4 → 6× — a dúvida ao ditar cresce mais rápido que o run.

Isenção por geminada fonêmica

A penalidade não é cega ao idioma. Uma letra dobrada que muda o som não é ruído de soletração — e o que decide isso não é ser consoante ou vogal, é a língua:

A tabela é cruzada de propósito: cada língua isenta justamente o que a outra cobra. Uma isenção só-de-consoante (a primeira tentativa) derrubou zoo abaixo do §305 em en-US, tratando o dígrafo vocálico inglês como ruído.

A isenção vale só pro par: rrr não é dígrafo de língua nenhuma e é cobrado normalmente.

Isento ≠ bonificado. Uma geminada isenta não paga penalidade e não ganha bônus: ela colapsa antes da repetição distribuída ser medida, porque um fonema só não é rima interna. Foi por isso que zoo caiu em en-US (60 → 58) mesmo com oo isento — perdeu um bônus que nunca deveria ter tido.

Consequência esperada e correta: carro e zoo pontuam diferente nos dois perfis — o mesmo tipo de divergência multilíngue que o §305 já admite e que o §Contagem de sílabas chama de sinal de instabilidade.

Por que isto não duplica o SFB de Typability

Toda geminada é também um same-finger bigram (letra igual ⇒ dedo igual), então pp paga nas duas dimensões. Isso não viola §Um eixo, um dono, porque as perguntas são diferentes:

• Typability/SFB — quanto custa teclar? Custo motor, dependente de layout, e vale pra qualquer par de mesmo dedo (ed), não só duplicadas.
• Memorability/adjacente — vão escrever certo depois de ouvir? Custo ortográfico, independente de layout.

É por isso que o peso 0.6 é deliberadamente modesto — cerca de "uma letra fora da faixa ideal" (0.75). A geminada já paga em Typability; a Memorability cobra só a parcela que o SFB não enxerga.

Contagem de sílabas S (NAMER-005)

S = número de núcleos vocálicos. Percorre-se cada run de vogais consumindo gulosamente um ditongo legal na língua como um núcleo; o que não for ditongo é núcleo próprio (hiato).

• Ditongos — en-US: ai ay au aw ea ee ei ey eu ie oa oi oo ou ow oy ue ui; pt-BR: ai ei oi ui au eu iu ou ia ie io ua ue uo.
• e final mudo (só en-US) — palavra com ≥3 letras terminada em consoante+e perde o e antes da contagem (kase, kape, note).
• Vogais por perfil: en-US = aeiouy; pt-BR = aeiou (§Idiomas).

Por que sílabas E letras. As duas faixas coexistem medindo coisas diferentes: sílabas = comprimento fônico (quantos gestos pra falar), letras = comprimento visual (quanto ocupa lido/digitado). Por isso o peso da faixa de letras foi reduzido à metade (1.5→0.75 e 1.2→0.6) quando as sílabas entraram — sem isso, comprimento seria cobrado duas vezes.

Exemplo do porquê letras sozinhas não bastavam: kamaleon (8 letras, dentro da faixa ideal) tem 4 sílabas; krypt (5 letras, também dentro) tem 1. A faixa de letras não distinguia os dois.

Sinal de instabilidade: quando S diverge entre en-US e pt-BR, a palavra tem duas pronúncias convivendo — kase = 1 sílaba em en-US (e mudo) e 2 em pt-BR. A divergência aparece no score (en 76 × pt 84).

mem_penalty = max(0, Σ deltas)
Mem = round(100 · e^(-2.00 · mem_penalty / letters))

Exemplo trabalhado: koder

Type

base_effort = 5.5

Pares consecutivos:

type_penalty = 5.5 + 2 − 0.5·1 − 0.4 − 0.4 = 6.2
type_per    = 6.2 / 5 = 1.24
Type        = round(100 · e^(-0.65·1.24))
            = round(100 · 0.447)
            = 45  (Fair)

Pron

Tem vogais (o, e). Nenhum run consonantal ≥ 3. Nenhum bigram raro. Sem hard onset/coda.

pron_penalty = 0 → Pron = 100  (Excellent)

Son

Todos os 4 pares adjacentes alternam C/V (ko, od, de, er). Zero clusters CC ou VV.

son_penalty = 0 → Son = 100  (Excellent)

Mem

• Length 5 (ideal 4–8) → 0
• CV alternation: 4/4 = 100% → (1−1)·2 = 0
• Repetição: 5 letras únicas, repetition = 0 → 0

mem_penalty = 0 → Mem = 100  (Excellent)

Brand

Brand = round(0.35·45 + 0.30·100 + 0.20·100 + 0.15·100)
      = round(15.75 + 30 + 20 + 15)
      = round(80.75)
      = 81  (Great)

koder → Brand 81 (Great).

Checklist pra aplicar no naming de módulos Koder

Quando precisar sugerir nomes pra um novo módulo/produto/serviço:

1. Gere 5–10 candidatos livremente, capturando o conceito do produto. Não filtre na hora da geração.
2. Rode os scores — mentalmente (regras acima) ou via https://namer.koder.dev/?word=nome1,nome2,nome3.
3. Filtros rígidos (descartar imediatamente):
   • Brand < 50
   • Pron < 60 (difícil de pronunciar é difícil de viralizar)
   • Qualquer SFB com rowDist ≥ 2 em nome de ≤ 6 letras (impacto proporcional alto)
   • Length < 3 ou > 10 (fora da faixa confortável de marca)
4. Ranqueie os sobreviventes por Brand desc.
5. Filtros manuais (não-quantificáveis):
   • Colisão com marca existente conhecida (Google, Amazon, OpenAI, etc.)
   • Semântica ruim ou ofensiva em inglês, português, espanhol
   • Quebra a coerência da família Koder (nome muito distante do tom dos módulos vizinhos)
   • Domínio .dev ou .com já registrado por terceiros (checar antes de apresentar)
6. Apresente o top 3 ao usuário com o Brand score de cada um, em formato: koder-<nome> (Brand XX · <rating>).

Alvos por tipo de módulo

Referência

• Implementação canônica: tools/namer/site/script.js
• Ferramenta web interativa: https://namer.koder.dev
• Inspiração de typability: Carpalx (Krzywinski, 2005)

§Idiomas — scoring multi-idioma (en-US default + pt-BR)

O Brand score é dependente de idioma: Typability é por layout de teclado (QWERTY/ABNT2…) e Pronunciability + Sonority são por fonotática da língua. A API é analyze(text, layout, lang) com lang default en-US (American English). Implementado em tools/namer/site/script.js (registro LANGS).

Perfil pt-BR (Português Brasileiro)

• Vogais: a e i o u (y não é vogal em pt).
• Coda final válida: um único s/r/l/m/n/z. Cluster final (ex.: kiln → -ln, wright → -ght) é ilegal em pt → penalidade forte; consoante final fora do conjunto também penaliza. (É o que o brand-score inglês não vê: kiln é Pron 100 em inglês mas difícil pra um brasileiro.)
• Onsets: C+{l,r} são nativos → kl/kr não penalizam (o inglês penaliza kl como bigram raro). Onsets fora do conjunto pt (ex.: st,sp,sk iniciais — epentéticos em pt) penalizam.
• Bigrams estrangeiros (th/sh/ck/gh/wr/kn/dj…) penalizam.

R-LANG — Política de naming da Koder Stack (normativa)

A Koder Stack é desenvolvida por um cidadão brasileiro e será usada internacionalmente. As duas pernas do teste existem por razões diferentes, e por isso não são o mesmo tipo de teste (revisão 2026-07-19, NAMER-012):

1. en-US é uma BARRA DE QUALIDADE — ≥ 60 (Good+), condição NECESSÁRIA. A autoria da Koder é en-US (policies/language.kmd: "authoring source of truth stays en-US"), então é nesta língua que a marca existe e é aqui que o nome precisa ser bom. Ruim em inglês → descartar, sem segunda chance.
2. pt-BR é um PISO DE HOSTILIDADE — ≥ 46, não uma barra de qualidade. A Koder não faz marca em português. A pergunta aqui não é "é um bom nome em pt?", é "é hostil ao brasileiro que o escreve, digita e fala todo dia?". Abaixo do piso → descartar.
3. Só entra na leva quem passa nas duas — lembrando que são exigências de natureza distinta, não o mesmo número duas vezes.

Por que 46 e não 60 (medido, não arbitrado)

O 60 simétrico foi mantido até 2026-07-19 e parecia imparcial. Medido sobre os 189 slugs de componente do stack-manifest:

O motor pt-BR devolve sistematicamente ~7,6 pontos a menos para o mesmo nome — não por defeito, mas porque a fonotática portuguesa realmente pune coda consonantal, que o inglês usa nativamente. Logo, um piso idêntico nas duas línguas é ~4× mais seletivo em português: a régua lia como simétrica e se comportava como "en precisa ser bom; pt precisa ser excelente". Efeito medido: 57 nomes reprovavam só na perna pt contra 3 só na perna en (19:1).

46 é o piso equipercentil ao 60 do en-US — exige, em português, o mesmo rigor relativo que se exige em inglês. Resultado da mesma varredura sob a regra nova: conformidade sobe de 114/189 (60%) → 162/189 (86%), os bloqueios só-por-pt caem de 57 → 9, e a perna en volta a ser a dominante (11 bloqueios), que é o que "en é a barra de qualidade" deve produzir.

O piso continua mordendo onde deve. Sob ≥46 o pt ainda barra ads (38), sync-kit (38), recsys (39), shell (41), crypto (42) — casos genuinamente ásperos, não vítimas de escala.

Sim, 46 cai na banda Fair — e está correto. As bandas de rating (Poor/Fair/Good/Great/Excellent) são a escala de qualidade de marca; o piso pt-BR não é um requisito de qualidade de marca, é um piso de hostilidade (item 2). Exigir Good+ em pt seria justamente reintroduzir a barra de qualidade na perna errada — o defeito que esta revisão corrigiu. Nada no código mudou: o ≥ 60 do script.js é o início da banda Good, não o piso do R-LANG; o R-LANG é aplicado por quem lê esta spec.

O que a perna pt-BR NÃO é

Ela não mede "quão nativo-português o nome soa". Se medisse, reprovaria a metade do vocabulário técnico que brasileiros usam sem atrito — chat (pt 50), hub (51), web, link, site, deploy são ditos diariamente por falantes de português, com adaptação natural ("chát-i"), e nenhum deles é hostil. Empréstimo adotado é evidência empírica de que coda consonantal não impede uso. O que o piso existe pra pegar é o nome que o brasileiro tropeça pra dizer ou digitar — não o que apenas soa estrangeiro.

Fluxo (qualquer IA): analyze(nome, layout, 'en-US') → < 60 descarta; senão analyze(nome, layout, 'pt-BR') → < 46 descarta. A name-batch-presentation.kmd herda esta regra (gerar = checar os dois idiomas).

⚠️ Prospectivo, como sempre foi. Este gate filtra candidatos entrando numa leva. Nome já shipado não é renomeado por não passar — ver a nota de aplicação em name-batch-presentation.kmd §1b. A revisão de 2026-07-19 não cria dívida retroativa; ela conserta a régua daqui pra frente.