Esta página faz duas coisas:
-
Define a hipótese filológica: por que eu deduzo que a base estrutural (a “linguagem de criação” por trás do Voynich) se apoia em Italiano tardomedieval e Latim técnico/laboratorial (século XIV–XV).
-
Explica como essa linguagem teria sido montada: como uma palavra “original” (italiana/latina) poderia ser retalhada, compactada e reconfigurada até virar um token Voynich — preservando função e controle procedural.
Status: isto é uma hipótese de base (não “prova final”). A função desta página é deixar claro o que precisa ser verdadeiro para essa base se sustentar, e como eu tento validar.
1) O que eu quero dizer com “Italiano–Latim de laboratório”
Quando eu falo “Italiano de laboratório”, não é “italiano literário”. É o tipo de linguagem que aparece em práticas técnicas e artesanais pré-modernas:
-
mistura de vernáculo (italiano regional) com latim técnico;
-
preferência por verbos operativos (ações) e substantivos de processo;
-
vocabulário ligado a extração, destilação, maceração, dissolução, fixação, separação, etc.;
-
uso de abreviações, contrações e “atalhos” escritos (muito comum em manuscritos técnicos e de ofício).
Ou seja: é um terreno linguístico onde faz sentido existir um “dialeto” prático, híbrido, e onde a economia de escrita é uma vantagem operacional.
2) Por que Italiano e Latim (século XIV) são candidatos plausíveis
Aqui entram critérios, não opinião.
2.1 Critério A — “tipo de vocabulário” compatível com protocolo
Se o texto é procedural, então a base precisa suportar:
-
verbos de operação (muito produtivos, combináveis),
-
nominalizações de processo (ato de X, estado de X),
-
conectores e moduladores (“até”, “em seguida”, “mantendo”, “em dose/medida”),
-
termos de ofício (recipientes, banhos, selagens, fases).
Italiano tardomedieval e Latim técnico são especialmente bons nisso porque:
-
o latim fornece nomes de processos (padrões do tipo “-atio” / “-tio” conceitualmente),
-
o italiano fornece operadores verbais muito diretos (padrões do tipo “-are” / “-ire” como base de ação).
2.2 Critério B — “morfologia modular”
A sua própria análise morfológica (prefixos/sufixos/estado/aspecto) exige uma língua-base que seja modular, com peças reconhecíveis e reutilizáveis.
Línguas românicas + latim técnico têm exatamente isso:
-
raízes com alta recombinação,
-
processos de derivação previsíveis (ação ↔ estado ↔ resultado),
-
alternância verbo/substantivo de processo (muito útil para um “código” procedural).
2.3 Critério C — “ambiente cultural de codificação”
Século XIV é um ambiente onde:
-
há transmissão de ofícios por manuscrito,
-
há concorrência e sigilo (receitas, rotas, técnicas),
-
há falta de padronização universal de medidas e instrumentos,
-
e há tradição de escrita compacta.
Isso combina com a hipótese de “criptografia funcional”: codificar não só para esconder, mas para padronizar e proteger.
3) O que precisa ser validado para eu poder “defender” essa base
Eu não “declaro” Italiano/Latim. Eu tento validar por famílias de evidência.
3.1 Evidência 1 — Raízes/cognatos recuperáveis (após remover operadores)
Se eu tiro os operadores (prefixos/sufixos procedurais) e fico com o núcleo, os núcleos deveriam:
-
formar famílias que lembram raízes românicas/latinas (ainda que deformadas),
-
ter “parentesco” interno consistente (mesma família, funções vizinhas),
-
permitir hipóteses de reconstrução que gerem predições.
3.2 Evidência 2 — Comportamento de derivação semelhante ao romance/latim técnico
A diferença entre:
-
“ação em curso”,
-
“estado fixado”,
-
“derivado/pertencente”,
-
“medido/parametrizado”,
é muito parecida com o que receitas técnicas precisam codificar. A pergunta é: os seus sufixos (ex.: -AIIN, -Y/-EEY, -DY, -AM, -S) se comportam como uma camada que substitui derivação natural (tipo “-ato/-ata”, “-zione”, “-mente”, “de/di”, etc.)?
Se sim, isso fortalece a hipótese de base.
3.3 Evidência 3 — Sintaxe procedural “românica” (ordem e governança local)
Italiano/latim técnico de receita costuma organizar:
-
operação → alvo/material → condicionais → estados.
Se suas cadeias CSP têm padrões estáveis desse tipo, isso é compatível.
3.4 Evidência 4 — Reconstrução reversa com testes fora do conjunto
A regra mais importante:
Qualquer proposta de “palavra original” precisa prever ocorrências e comportamentos em trechos não usados para formular a hipótese.
4) Como essa linguagem poderia ter sido “montada”
Aqui é a parte mecânica: como alguém transforma uma base italo-latina numa linguagem fechada procedural.
4.1 Camada 1 — Vocabulário-base (itálico/latim técnico)
Pense em um estoque de lexemas de ofício, por exemplo (apenas como categoria):
-
operações: macerar, destilar, dissolver, fixar, filtrar, decantar, fermentar, cozer, secar…
-
estados/processos: solução, precipitado, estase, saturação, “lixívia”/lixiviação, fixação…
-
instrumentos/montagens: banho, vaso, tubo, selo, forno, alambique, filtro…
A base pode alternar entre:
-
verbo italiano (ação), e
-
substantivo/processo latinizado (ato/resultado).
Isso é normal em linguagem técnica medieval.
4.2 Camada 2 — “Retalhamento” (compressão e neutralização)
Para virar código fechado, o escriba pode:
-
reduzir vogais (ou codificar vogais de modo padronizado),
-
preservar um esqueleto (consonantal ou semi-consonantal),
-
fundir grafemas frequentes (ligaturas),
-
padronizar finais (um mesmo sufixo do código cobre várias terminações naturais).
Ou seja: você não precisa copiar “macerare” como está; você pode guardar só o “motor” da palavra.
4.3 Camada 3 — Operadores procedurais (prefixos e sufixos)
Aqui entram seus PFX/SFX:
-
prefixos como modo/escopo (executar, reinjetar, entrar em rotina),
-
sufixos como aspecto/estado (em curso, concluído, derivado, medido),
-
conectores compactos para fluxo (sequência/condição).
Resultado: a palavra vira um “comando parametrizado”.
5) Exemplos didáticos de “retalhamento e montagem”
Atenção: os exemplos abaixo são didáticos. Eles mostram o tipo de transformação que eu alego existir. Eles só viram “exemplo real” quando eu amarro a um token específico, em linhas específicas, com teste fora do conjunto.
Exemplo didático 1 — Verbo operativo → token com modo + aspecto
Base (italiano): macerare (ação técnica recorrente)
Retalhamento: selecionar um esqueleto funcional MCR (ou equivalente)
Montagem Voynich (modelo):
-
PFX (modo comando/ciclo):
QOT- -
NUC (raiz compactada):
mcr -
SFX (ação em curso):
-EEY(gerúndio operacional)
Leitura funcional resultante: “executar maceração em curso / manter macerando”
O ponto do exemplo: o verbo italiano “vira” uma unidade procedural com modo + aspecto, sem precisar carregar a forma plena.
Exemplo didático 2 — Processo/resultado latinizado → token como estado fixado
Base (latim técnico): fixatio / ideia de fixação
Retalhamento: raiz FIX (ou equivalente)
Montagem Voynich (modelo):
-
NUC:
fix -
SFX:
-AIIN(estado concluído/fixado)
Leitura funcional resultante: “estado fixado / fixação concluída (checkpoint)”
O ponto: o latim técnico fornece “estado/processo”, e o sufixo do código “fecha” o estado sem precisar da nominalização latina completa.
Exemplo didático 3 — Relação “de/da/origem” (di/de) → derivativo do código
Base (italiano/latim): relação de origem/pertencimento (di/de)
Montagem Voynich (modelo):
-
NUC:
X -
SFX:
-DY(derivativo/origem/ponte)
Leitura funcional resultante: “de X / derivado de X / ligado a X”
O ponto: o -DY pode funcionar como “cola sintática” onde o italiano usaria di/de, e o latim usaria genitivos/construções de origem.
Exemplo didático 4 — Parametrização (dose/medida) → sufixo de medida
Base (receita): “em tal medida”, “em tal condição”
Montagem Voynich (modelo):
-
NUC:
ais(qualquer núcleo que represente um insumo/ação) -
SFX:
-AM(medida/fecho/quantização)
Leitura funcional resultante: “X em medida/fecho AM” (parametrizado)
O ponto: receitas vivem de parametrização; um sufixo dedicado reduz ambiguidade.
This page does two things:
-
It defines the philological hypothesis: why I infer that the structural base (the “language of construction” behind the Voynich) relies on Late Medieval Italian and technical/laboratory Latin (14th–15th centuries).
-
It explains how such a language could have been assembled: how an “original” word (Italian/Latin) could be cut up, compacted, and reconfigured until it becomes a Voynich token—while preserving function and procedural control.
Status: this is a base hypothesis (not “final proof”). The purpose of this page is to make clear what must be true for this base to hold, and how I attempt to validate it.
1) What I mean by “laboratory Italian–Latin”
When I say “laboratory Italian,” I do not mean “literary Italian.” I mean the kind of language found in pre-modern technical and artisanal practices:
-
a mixture of vernacular (regional Italian) with technical Latin;
-
a preference for operative verbs (actions) and process nouns;
-
vocabulary tied to extraction, distillation, maceration, dissolution, fixation, separation, etc.;
-
use of abbreviations, contractions, and written “shortcuts” (very common in technical and craft manuscripts).
In other words: this is a linguistic terrain where a practical, hybrid “dialect” makes sense, and where economy of writing is an operational advantage.
2) Why Italian and Latin (14th century) are plausible candidates
Here we deal with criteria, not opinion.
2.1 Criterion A — “Vocabulary type” compatible with protocol
If the text is procedural, then the base must support:
-
operative verbs (highly productive, combinable),
-
process nominalizations (act of X, state of X),
-
connectors and modifiers (“until,” “then,” “while,” “in dose/measure”),
-
craft terms (vessels, baths, seals, phases).
Late Medieval Italian and technical Latin are especially good at this because:
-
Latin provides process names (conceptually patterns like “-atio” / “-tio”),
-
Italian provides very direct verbal operators (patterns like “-are” / “-ire” as action bases).
2.2 Criterion B — “Modular morphology”
Your own morphological analysis (prefixes/suffixes/state/aspect) requires a base language that is modular, with recognizable, reusable pieces.
Romance languages + technical Latin provide exactly that:
-
roots with high recombinability,
-
predictable derivational processes (action ↔ state ↔ result),
-
verb/process-noun alternation (very useful for a procedural “code”).
2.3 Criterion C — “Cultural environment of encoding”
The 14th century is an environment where:
-
craft knowledge is transmitted via manuscripts,
-
competition and secrecy exist (recipes, routes, techniques),
-
there is no universal standardization of measures and instruments,
-
and there is a tradition of compact writing.
This aligns with the hypothesis of “functional cryptography”: encoding not only to hide, but to standardize and protect.
3) What must be validated for me to “defend” this base
I do not simply “declare” Italian/Latin. I attempt to validate it through families of evidence.
3.1 Evidence 1 — Recoverable roots/cognates (after removing operators)
If I remove the operators (procedural prefixes/suffixes) and keep the core, the cores should:
-
form families reminiscent of Romance/Latin roots (even if deformed),
-
show consistent internal “kinship” (same family, neighboring functions),
-
allow reconstruction hypotheses that generate predictions.
3.2 Evidence 2 — Derivational behavior similar to Romance/technical Latin
The distinction between:
-
“action in progress,”
-
“fixed state,”
-
“derived/belonging,”
-
“measured/parameterized,”
is very close to what technical recipes need to encode. The question is: do your suffixes (e.g., -AIIN, -Y/-EEY, -DY, -AM, -S) behave like a layer that replaces natural derivation (such as “-ato/-ata,” “-zione,” “-mente,” “de/di,” etc.)?
If so, this strengthens the base hypothesis.
3.3 Evidence 3 — “Romance-like” procedural syntax (order and local governance)
Italian/technical-Latin recipes typically organize:
-
operation → target/material → conditionals → states.
If your CSP chains show stable patterns of this type, that is compatible.
3.4 Evidence 4 — Reverse reconstruction with out-of-sample testing
The most important rule:
Any proposed “original word” must predict occurrences and behaviors in passages not used to formulate the hypothesis.
4) How this language could have been “assembled”
This is the mechanical part: how someone transforms an Italo-Latin base into a closed procedural language.
4.1 Layer 1 — Base vocabulary (Italic / technical Latin)
Think of a stock of craft lexemes, for example (purely as categories):
-
operations: macerate, distill, dissolve, fix, filter, decant, ferment, cook, dry…
-
states/processes: solution, precipitate, stasis, saturation, “lye”/leaching, fixation…
-
instruments/assemblies: bath, vessel, tube, seal, furnace, alembic, filter…
The base can alternate between:
-
Italian verbs (action), and
-
Latinized process nouns (act/result).
This is normal in medieval technical language.
4.2 Layer 2 — “Cutting” (compression and neutralization)
To become closed code, the scribe may:
-
reduce vowels (or encode vowels in a standardized way),
-
preserve a functional skeleton (consonantal or semi-consonantal),
-
merge frequent graphemes (ligatures),
-
standardize endings (one code suffix covers multiple natural endings).
In other words: you do not need to copy “macerare” as-is; you can preserve only the word’s “engine.”
4.3 Layer 3 — Procedural operators (prefixes and suffixes)
This is where your PFX/SFX come in:
-
prefixes as mode/scope (execute, re-inject, enter routine),
-
suffixes as aspect/state (in progress, completed, derived, measured),
-
compact connectors for flow (sequence/condition).
Result: the word becomes a “parameterized command.”
5) Didactic examples of “cutting and assembly”
Attention: the examples below are didactic. They show the type of transformation I claim exists. They only become “real examples” when tied to a specific token, in specific lines, with out-of-sample testing.
Didactic example 1 — Operative verb → token with mode + aspect
Base (Italian): macerare (recurring technical action)
Cutting: select a functional skeleton MCR (or equivalent)
Voynich assembly (model):
-
PFX (command/cycle mode):
QOT- -
NUC (compacted root):
mcr -
SFX (action in progress):
-EEY(operational gerund)
Resulting functional reading: “execute maceration in progress / keep macerating”
The point of the example: the Italian verb becomes a procedural unit with mode + aspect, without carrying the full form.
Didactic example 2 — Latinized process/result → token as fixed state
Base (technical Latin): fixatio / idea of fixation
Cutting: root FIX (or equivalent)
Voynich assembly (model):
-
NUC:
fix -
SFX:
-AIIN(completed/fixed state)
Resulting functional reading: “fixed state / fixation completed (checkpoint)”
The point: technical Latin provides “state/process,” and the code suffix closes the state without needing the full Latin nominalization.
Didactic example 3 — “of/from/origin” relation (di/de) → code derivative
Base (Italian/Latin): relation of origin/belonging (di/de)
Voynich assembly (model):
-
NUC:
X -
SFX:
-DY(derivative/origin/bridge)
Resulting functional reading: “of X / derived from X / linked to X”
The point: -DY can function as a “syntactic glue” where Italian would use di/de, and Latin would use genitives or origin constructions.
Didactic example 4 — Parameterization (dose/measure) → measurement suffix
Base (recipe): “in such a measure,” “under such a condition”
Voynich assembly (model):
-
NUC:
ais(any core representing an input/action) -
SFX:
-AM(measure/closure/quantization)
Resulting functional reading: “X in measure/closure AM” (parameterized)
The point: recipes live on parameterization; a dedicated suffix reduces ambiguity.
Comments are closed