O Método | The Method

adminizaiasgabriel -
fevereiro 1, 2026
EN-USPT-BRVoynich
Esta página descreve como eu transformo o texto do Voynich em análise: do dado bruto (transcrição) até uma saída funcional (rotulagem procedural), com versionamento e critérios de validação. O objetivo é simples e duro: evitar interpretação solta. Aqui, qualquer conclusão precisa nascer de um procedimento repetível.

1) Princípio operacional

Eu trato o Voynich como um sistema procedural. Isso muda o que “significado” quer dizer:

  • Eu não começo perguntando “que língua é?”.

  • Eu começo perguntando: “que função isso exerce dentro de uma sequência executável?”

Então eu trabalho em camadas:

  1. Transcrição → tokens

  2. Tokens → morfologia

  3. Morfologia → classes funcionais

  4. Classes → papéis procedurais (CSP)

  5. Sequências → validação por padrões, predições e métricas

2) Dados e rastreabilidade

2.1 Fonte primária (transcrição)

Eu uso uma transcrição padrão do Voynich (formato de linhas por fólio).
Regra de ouro: qualquer afirmação deve apontar para um endereço claro: folio.linha (ex.: f99r.15).

2.2 Recurso de trabalho (dicionário)

Eu mantenho um dicionário versionado com entradas estruturadas (classe, morfologia, aspecto, confiança, notas procedurais).
Regra de ouro: toda análise precisa declarar a versão do dicionário e da gramática usadas.

2.3 Citação interna obrigatória

Em cada post/caso, eu declaro:

  • Corpus/transcrição: qual versão

  • Dicionário: versão (ex.: v27.47)

  • Gramática/CSP: versão (ex.: CSP vX.Y)

  • Regras aplicadas: lista mínima (IDs das regras)

Sem isso, o post não entra no laboratório (fica como rascunho).

3) Pipeline de análise (do token ao “executável”)

3.1 Normalização e tokenização

Entrada: uma linha transcrita.
Saída: lista de tokens.

Regras fixas:

  • Token = sequência contínua separada por espaços na transcrição.

  • Eu não “corrijo” ortografia na entrada. Se houver variantes, elas viram variantes rastreadas, não substituições invisíveis.

  • Tokens ambíguos ficam marcados como AMB (ambíguo), nunca forçados.

Produto desta etapa:

  • Lista de tokens + contagem + posição (índice do token na linha)

3.2 Segmentação morfológica

Entrada: um token.
Saída: decomposição: (prefixos) + núcleo + (sufixos).

Aqui entra a ideia de que parte do “sentido” não está no núcleo inteiro, mas em marcadores (prefixos/sufixos) que operam como modo/aspecto/estado.

Regras fixas:

  • Todo token é analisado em busca de:

    • prefixos operativos (acionamento/execução, variações de comando)

    • núcleo lexical (a “raiz funcional”)

    • sufixos de estado/aspecto (fixação, continuidade, iteratividade etc.)

  • A segmentação não é “porque parece bonito”: ela precisa ser economicamente estável:

    • a mesma peça deve reaparecer em muitos tokens com comportamento semelhante

    • a remoção/adição da peça deve mudar o comportamento de forma previsível

Produto desta etapa:

  • Registro morfológico do token: PFX | NUC | SFX (+ variantes)

3.3 Classificação funcional (classes)

Entrada: token segmentado.
Saída: classe funcional principal.

As classes são uma camada intermediária: elas não “traduzem”, elas agrupam função.

Exemplo de classes típicas (você pode ajustar os nomes no seu sistema, mas mantenha o conceito):

  • OP: operação/ação (fazer, selar, aquecer, extrair…)

  • MAT: material/precursor/base (insumo, substrato, solvente…)

  • MOD: modulador (intensidade, repetição, quantidade, modo…)

  • STA: estado (fixo, em estase, saturado…)

  • CON: conector procedural (sequência/condição/transição)

  • INS: instrumento/recipiente (quando for aplicável)

  • UNK: desconhecido (não forçar)

Regra de ouro:
Se a classe não for defensável por estabilidade e recorrência, ela fica UNK ou com baixa confiança, e isso é considerado resultado válido (honestidade > encaixe).

Produto desta etapa:

  • token → CLASS com nível de confiança

3.4 CSP: Camada de Sintaxe Procedural

A CSP é onde o texto vira “executável”.

Entrada: sequência de tokens com classes.
Saída: papéis procedurais + dependências locais.

Aqui eu trato a linha como um trecho de protocolo:

  • Operações governam materiais e estados

  • Moduladores ajustam operações/estados

  • Conectores encadeiam (antes/depois/até/se-então/enquanto)

Eu evito inventar “gramática completa” cedo demais. Em vez disso:

  • começo com padrões curtos (2 a 5 tokens)

  • testo em páginas que não participaram do desenho da regra

  • só depois generalizo

Produto desta etapa:

  • rótulos CSP por token (papel)

  • vínculos simples (quem modifica quem; quem governa quem)

This page describes how I transform Voynich text into analysis: from raw data (transcription) to a functional output (procedural labeling), with versioning and validation criteria. The goal is simple and uncompromising: to avoid loose interpretation. Here, any conclusion must be born from a repeatable procedure.

1) Operational principle

I treat the Voynich as a procedural system. This changes what “meaning” actually means:

  • I do not start by asking “what language is this?”.

  • I start by asking: “what function does this perform within an executable sequence?”

Then I work in layers:

  1. Transcription → tokens

  2. Tokens → morphology

  3. Morphology → functional classes

  4. Classes → procedural roles (CSP)

  5. Sequences → validation through patterns, predictions, and metrics

2) Data and traceability

2.1 Primary source (transcription)

I use a standard Voynich transcription (folio-by-line format).
Golden rule: any claim must point to a clear address: folio.line (e.g., f99r.15).

2.2 Working resource (dictionary)

I maintain a versioned dictionary with structured entries (class, morphology, aspect, confidence, procedural notes).
Golden rule: every analysis must declare the version of the dictionary and grammar used.

2.3 Mandatory internal citation

In every post/case, I declare:

  • Corpus/transcription: which version

  • Dictionary: version (e.g., v27.47)

  • Grammar/CSP: version (e.g., CSP vX.Y)

  • Applied rules: minimal list (rule IDs)

Without this, the post does not enter the lab (it remains a draft).

3) Analysis pipeline (from token to “executable”)

3.1 Normalization and tokenization

Input: a transcribed line.
Output: list of tokens.

Fixed rules:

  • Token = a continuous sequence separated by spaces in the transcription.

  • I do not “correct” spelling at input. If variants exist, they become tracked variants, not invisible substitutions.

  • Ambiguous tokens are marked as AMB (ambiguous), never forced.

Product of this stage:

  • Token list + count + position (token index in the line)

3.2 Morphological segmentation

Input: a token.
Output: decomposition: (prefixes) + core + (suffixes).

Here comes the idea that part of the “sense” is not in the full core, but in markers (prefixes/suffixes) that operate as mode/aspect/state.

Fixed rules:

  • Every token is analyzed in search of:

    • operative prefixes (triggering/execution, command variations)

    • lexical core (the “functional root”)

    • state/aspect suffixes (fixation, continuity, iterativity, etc.)

  • Segmentation is not “because it looks nice”: it must be economically stable:

    • the same piece must reappear in many tokens with similar behavior

    • adding/removing the piece must change behavior in a predictable way

Product of this stage:

  • Morphological record of the token: PFX | NUC | SFX (+ variants)

3.3 Functional classification (classes)

Input: segmented token.
Output: primary functional class.

Classes are an intermediate layer: they do not “translate”, they group function.

Examples of typical classes (you may adjust the names in your system, but keep the concept):

  • OP: operation/action (do, seal, heat, extract…)

  • MAT: material/precursor/base (input, substrate, solvent…)

  • MOD: modifier (intensity, repetition, quantity, mode…)

  • STA: state (fixed, in stasis, saturated…)

  • CON: procedural connector (sequence/condition/transition)

  • INS: instrument/container (when applicable)

  • UNK: unknown (do not force)

Golden rule:
If a class is not defensible by stability and recurrence, it remains UNK or marked with low confidence, and this is considered a valid result (honesty > fit).

Product of this stage:

  • token → CLASS with confidence level

3.4 CSP: Procedural Syntax Layer

CSP is where the text becomes “executable”.

Input: sequence of tokens with classes.
Output: procedural roles + local dependencies.

Here I treat the line as a protocol fragment:

  • Operations govern materials and states

  • Modifiers adjust operations/states

  • Connectors chain (before/after/until/if–then/while)

I avoid inventing a “complete grammar” too early. Instead:

  • I start with short patterns (2 to 5 tokens)

  • I test on pages that did not participate in the rule design

  • only then do I generalize

Product of this stage:

  • CSP labels per token (role)

  • simple links (who modifies whom; who governs whom)

#No Tag

Comments are closed