eduKateSG · VOYNICH RESEARCH LIBRARY · TANGENTIAL VOYNICH V
Tangential Voynich | Treat the Manuscript as a Database
Records without tables. Keys without names. Joins without known entities. What happens when an unread manuscript is forced to behave like stored, related, queryable information?
← Tangential Voynich: The Wrong-System Protocol · Previous False World: Compiler · Voynich Research Library
There is a way to read a book that assumes the book wants to be read from beginning to end.
There is another way to use information.
You do not read a database.
You ask it questions.
You ask which records match.
You ask which fields repeat.
You ask which objects are connected.
You ask what is missing.
You ask whether two apparently separate records refer to the same entity.
You ask whether one identifier connects several tables.
You ask whether the structure has changed over time.
This creates a radically different wrong world for the Voynich Manuscript.
What if we temporarily stop treating Voynich as a message and treat it as stored relationships?
Not because it is a database.
It is not a modern database. No historical claim is being made. The manuscript was not written in SQL, and a fifteenth-century scribe was not maintaining PostgreSQL on parchment.
The absurdity protects the experiment.
A database engineer arrives with a different obsession from a cryptographer, linguist, compiler engineer or railway controller.
The database engineer wants to know what the entities are, how records are delimited, which fields are stable, which values can be absent, what acts like an identifier, which relationships are one-to-one or many-to-many, where duplication occurs, what an index makes retrievable, and whether the same schema survives across the whole collection.
That obsession may force the manuscript to reveal different structural properties.
FALSE-WORLD CONTRACT
Voynich Is Not a Database
- A page is not a table.
- A short entry is not a record.
- A recurring form is not a primary key.
- A label is not a field name.
- A drawing is not an entity row.
- A repeated plant-like image is not a database object merely because it recurs.
- An absent form is not automatically NULL.
- A foldout is not a dashboard.
- A visual resemblance is not a join.
- A structured entry layout does not establish inventory, catalogue or database function.
The database vocabulary exists only to generate tests.
Relation is not identity. Repetition is not a key. Entry-like geometry is not a catalogue.
What a Database Adds That the First Three False Worlds Did Not
The railway taught us to think about routing.
The operating system taught us to think about state.
The compiler taught us to distrust our units.
The database introduces something different:
identity across separation.
A person can appear in one table as a customer, another as a payment owner and another as a delivery recipient. The records are separate. The underlying entity can be the same.
Likewise, a database can represent one object through several views. One view may show names. Another dates. Another relationships. None is the object itself.
This suggests a profound Voynich question:
Could apparently separate textual, visual and codicological structures be different projections of shared underlying entities or relations?
That is not the same as saying a plant picture and its nearby label form a database row.
It asks whether repeated co-variation across layers can reveal latent identity more reliably than resemblance alone.
For the database mechanics themselves, see How Databases Work | From Data Models and Constraints to Queries, Transactions, Indexes and Reliable State.
Records: Where Does One Thing End and Another Begin?
A database record is a bounded unit containing related fields.
The Voynich Manuscript contains several places that tempt record-like thinking: short entries, star-marked lines, label clusters, repeated page layouts and the M5 morphology class with its entry-like geometry.
But the existing hostile genre work already teaches restraint. Entry-like morphology can be strong while semantic function remains unestablished.
The database tangent therefore asks a narrower question:
Are there recurring structural bundles that behave as bounded units even when we refuse to name their genre?
Possible record boundaries could be tested through:
- repeated start patterns;
- repeated end patterns;
- stable internal position classes;
- consistent label-to-prose ratios;
- recurring visual adjacency;
- similar length distributions;
- reset effects between neighbouring bundles.
If the bundles have no stable internal structure, the record analogy fails.
If they do, the neutral return is simply:
Some manuscript regions may contain repeatable bounded entry structures.
That still does not tell us whether the entries are recipes, names, observations, instructions or something else.
Fields: Does Position Carry Role?
A record contains fields.
Field position or field name determines how a value should be interpreted.
This gives us a useful attack on recurring short entries.
If an entry-like unit has several local positions, ask whether the populations occupying those positions differ reproducibly.
For example:
- Does the first position draw from one restricted family?
- Do middle positions show wider variation?
- Do endings use a different terminal class?
- Are labels associated with one position more than others?
- Do diagram-adjacent strings occupy distinct positional roles?
This is not a claim that the first item is a “name field” or the second a “quantity field.”
The neutral claim is only that position may define structural role.
The compiler tangent already found positional classes inside strings. The database tangent widens the scale and asks whether larger entry structures also contain stable role positions.
Primary Keys: What Repeats Because It Identifies?
A primary key uniquely identifies a record.
This is one of the most seductive database analogies because the Voynich Manuscript contains many recurring forms.
Most recurrent forms are almost certainly not identifiers.
A true key-like candidate must satisfy much stronger conditions.
- It should occupy a relatively stable structural slot.
- It should distinguish one bundle from another rather than simply occur everywhere.
- Repeated appearances should correlate with other repeated properties.
- The relationship should survive page and transcription controls.
- Its apparent identity should not arise merely from high frequency.
Suppose one label-like form appears beside visually related components on several pages. That is not yet a key.
But if the same form repeatedly predicts the same independent structural or visual class, then the form may be acting as a stable identifier, category marker, or repeated relation.
The neutral question is:
Do any recurrent forms identify recurring cross-layer bundles more reliably than chance?
That is a far harder test than “this label occurs more than once.”
Composite Keys: Identity May Require More Than One Feature
Many real databases cannot identify an entity with one field.
Identity may require a combination: account number plus date; country plus local code; product plus batch.
This may be a much better analogy for an unknown manuscript.
A recurring glyph sequence alone may be too weak.
But a combination of:
- text family;
- line position;
- visual component;
- page morphology;
- proposed hand;
- label/prose interface
may define a much more stable entity class.
This suggests a high-value test:
Does cross-layer identity become substantially more stable when several neutral features are combined?
This is exactly the sort of question the frozen multi-axis matrix prepares us to ask.
One axis did not capture the manuscript.
Perhaps identity itself is multi-axis.
Foreign Keys: Which Things Point Outside Themselves?
A foreign key links one record to another table.
This is a useful model for labels and cross-interface relations.
A short string beside a diagram may not contain the diagram’s full information. It may simply point to an entity or category represented elsewhere.
Likewise, a repeated form in prose may refer to a visual class, procedure class or other local object without being interpretable in isolation.
The database tangent asks:
- Which short forms recur across interface types?
- Do they associate with stable visual classes?
- Do their neighbourhoods differ in labels versus running text?
- Do they bridge page populations more often than expected?
- Do they connect otherwise separate structural communities?
This overlaps with railway interchanges and operating-system IPC bridges, but database thinking adds one new possibility:
A short form may be informative because it refers outward, not because it carries a complete local meaning.
After metaphor removal, we have a class of potential cross-interface reference forms.
That is worth testing directly against Labels Versus Running Text.
Joins: Can Separate Parts of the Manuscript Be Related Without Being Adjacent?
A database join connects records through shared fields.
Physical adjacency is irrelevant.
Two rows can live in different tables and still belong together.
This is a very useful conceptual attack on codex order.
We know the present manuscript may not preserve original sequence perfectly. Some bifolia, missing leaves and later binding operations complicate reading order.
The join tangent asks us to search for relationships that do not depend on present adjacency.
- Repeated text families across distant pages.
- Repeated visual components associated with related text populations.
- Shared label families across diagrams.
- Hand-specific recurring structures.
- Rare cross-page components that appear in matched structural contexts.
If two distant pages share a distinctive multi-axis signature, they may be more structurally related than two pages now bound beside one another.
Functional relation need not equal physical adjacency.
The database has generated a method for reconstructing relationship space separately from codex order.
Inner Joins and Outer Joins: Missing Matches Are Evidence Too
Database joins are useful partly because they distinguish matched and unmatched records.
An inner join keeps only records with matches.
An outer join can preserve records even when the counterpart is missing.
This generates a new Voynich question:
Which structures repeatedly expect a counterpart that is absent?
Examples might include:
- a visual family that usually carries labels but occasionally does not;
- a recurring short-entry structure missing one usual component;
- a bifolio pattern broken by a missing leaf;
- a label family whose corresponding visual class disappears in one region;
- a textual bundle whose expected continuation is absent at a damaged edge.
The absence may be meaningful, accidental, damaged, omitted or simply a flaw in the model.
But the database tangent gives us a disciplined way to record expected-but-unmatched relations.
This is more informative than simply calling them anomalies.
NULL: Absence, Unknown and Not Applicable Are Not the Same Thing
Databases are forced to confront missingness explicitly.
A missing value may mean unknown.
It may mean not recorded.
It may mean not applicable.
It may mean damaged.
Those states are not interchangeable.
Voynich analysis often suffers when absence is flattened.
If a page lacks a particular feature, why?
- The feature may genuinely not belong there.
- The page may be damaged.
- The transcription may omit an uncertain form.
- The relevant field may not apply to that interface type.
- The original counterpart may have been on a missing leaf.
- The assumed schema may be wrong.
The neutral return is one of the strongest lessons in the database tangent:
Missingness must be typed.
“Not observed,” “unknown,” “not applicable,” “damaged” and “not expected” should not share one analytical bucket.
This can improve every later statistical test.
Duplicate Records: Repetition May Be Copying, Not Multiple Entities
Databases struggle with duplicates.
Two rows may describe the same person under slightly different spellings. Two customer files may refer to one human. One entity can be accidentally counted twice.
Voynich research has a parallel danger.
Two repeated forms or images may represent:
- two distinct entities of one class;
- two copies of one exemplar;
- one repeated template;
- one scribal formula;
- one structural marker used many times;
- two unrelated objects that only resemble each other.
The database tangent therefore asks for entity resolution before counting repeated entities.
Do repeated visual components share text relationships?
Do repeated strings occur in the same role?
Do apparent duplicates preserve enough independent features to justify identity?
Resemblance alone is not sufficient.
This is another path toward preventing visual recurrence from silently becoming semantic recurrence.
Normalization: Separate Things That We Keep Collapsing Together
Database normalization separates concepts so that one fact is not duplicated unnecessarily across many records.
Tangential Voynich can borrow the intellectual move without pretending the manuscript was normalized.
Several research objects are often collapsed too early:
- glyph shape and glyph function;
- visual resemblance and object identity;
- page class and topic;
- scribal hand and authorship;
- physical adjacency and functional relationship;
- historical capability and provenance;
- repeated structure and repeated meaning.
Normalization thinking says: store these as separate variables until evidence justifies joining them.
Do not encode an interpretation inside the field that is supposed to measure it.
This is database language for the same epistemic discipline already protecting the Voynich programme.
Denormalization: Repetition Can Be Deliberate for Retrieval
Good database design sometimes deliberately duplicates information to make retrieval faster or simpler.
This generates a counterweight to the duplicate-record problem.
Repeated forms in Voynich may not always be inefficiency, linguistic redundancy or accidental copying.
Some repetition could support retrieval.
A page may repeat a marker because the reader needs local access without consulting another page.
A short label may repeat because each diagram must remain locally legible.
A formula may recur because it anchors independent entries.
The neutral test is:
Does repeated material disproportionately occur where local retrieval would otherwise require non-local context?
This does not establish that the repetition was designed for retrieval.
But it offers a new discriminator between arbitrary repetition and interface-supporting repetition.
Schema: Does the Manuscript Have Stable Expectations About What Belongs Together?
A database schema defines what kinds of fields, relationships and constraints exist.
The database tangent asks whether Voynich page populations possess repeatable structural schemas.
For a given neutral morphology, ask:
- Which interface elements are usually present?
- Which text populations recur?
- Which visual component families recur?
- Which boundaries appear?
- Which combinations are absent?
- Which elements are optional?
A schema-like model becomes useful only if it predicts held-out pages.
If the proposed page class requires endless exceptions, there may be no compact schema.
If a small set of structural expectations repeatedly predicts what kinds of elements appear together, we have a neutral page-architecture model.
This is much safer than assigning semantic section names.
Schema Drift: What If the Rules Changed During Production?
Real databases evolve.
Fields are added.
Constraints change.
Old records may follow an earlier schema.
This creates an important alternative to the idea that every structural difference must be a different topic or language.
What if some variation reflects production-time evolution?
Different scribes may inherit a common system and modify it.
Later quires may introduce new conventions.
A visual programme may change its entry architecture while preserving deeper relationships.
The test is not chronological storytelling.
We need independent production anchors.
- Does structural change align with hand transitions?
- With bifolio or quire boundaries?
- With material production differences?
- With distributional cluster changes?
- With visual morphology transitions?
If several independent axes align, schema evolution becomes a testable production hypothesis.
If not, the database metaphor dies.
Migration: A Structure Can Survive a Change of Host
Databases can be migrated between systems.
The same underlying information can change representation during transfer.
This is a useful high-distance analogy for manuscript copying.
A copied exemplar may preserve relationships while changing:
- script;
- abbreviation;
- layout;
- illustration style;
- ordering;
- language;
- local labels.
The database tangent asks which features are likely to survive migration because they encode relationships rather than surface form.
This produces a useful comparator strategy:
Search for invariant relational structure across known manuscript copies, not only visual similarity.
A plant image may change substantially while its position within a repeated sequence or its association with particular labels remains stable.
This gives image-descent research a new quantitative angle.
Views: The Same Underlying System Can Produce Different Pages
A database view presents selected information from underlying tables.
Different views can expose different subsets or arrangements without changing the stored entities.
This is one of the most fertile Tangential ideas for the Voynich Manuscript.
What if apparently different visual “sections” are not separate subjects but different interfaces onto overlapping information?
One page population may privilege whole forms.
Another may privilege components.
Another may organise cycles.
Another may organise short entries.
This would predict cross-view correspondences.
- shared text families;
- shared label families;
- shared visual subcomponents;
- shared ordering relations;
- shared positional markers.
If no cross-view correspondences exist, the view analogy weakens.
If they do, the neutral return is:
Distinct page architectures may expose overlapping underlying structural populations.
This is a more subtle alternative to “six semantic sections.”
Indexes: Retrieval Structure Can Exist Without Being Content
An index is not the data itself.
It is a structure that helps find the data.
This matters enormously for a manuscript because marks can have navigational roles.
Stars, paragraph-initial forms, marginal marks, numbering and repeated labels may organise retrieval rather than contribute directly to propositional content.
The database tangent asks whether any recurrent marker improves access to repeated structural classes.
- Does a marker predict entry boundaries?
- Does it correlate with a stable page class?
- Does it recur at predictable retrieval points?
- Does it partition material more effectively than random markers?
- Does the structure survive independent pages?
If yes, the marker may function as navigation, category signalling or another interface device.
That does not tell us what category it indexes.
It tells us to stop treating every visible sign as content.
Query Thinking: Ask for Relations Instead of Translations
A database is valuable because it can answer structured questions.
Imagine replacing the question:
What does this word mean?
with queries such as:
- Show every occurrence of this component family at line starts.
- Show all pages where this label family co-occurs with this neutral visual component.
- Show all bifolia where Currier regime changes but visual morphology does not.
- Show all repeated structures that cross proposed scribal hands.
- Show every entry-like bundle missing one otherwise common element.
- Show all forms whose neighbour distribution changes by interface type.
This is more than a computational convenience.
It changes the epistemology.
A good query can discover a relationship before anyone knows what the relationship means.
Tangential Voynich should become increasingly query-driven.
Query Plans: Different Routes Can Answer the Same Question
Databases can answer one query through different execution plans.
This generates a useful methodological analogy.
Suppose we want to know whether a repeated visual family is associated with a text family.
We could search:
- page-by-page;
- by visual cluster first;
- by text cluster first;
- by hand;
- by quire;
- by interface class.
If only one analytical route produces the relationship, the result may be fragile.
If several independent query plans recover the same relation, confidence rises.
The neutral principle is:
Important relationships should survive reasonable changes in retrieval path.
This is a database form of sensitivity analysis.
Constraints: The Database Cares About What Must Be True
Databases use constraints to protect consistency.
A field may require uniqueness.
A relation may require a valid counterpart.
A value may be prohibited from being empty.
This extends the stable-exclusion work already emerging across the first three false worlds.
But database constraints add something new: cross-record consistency.
A local sequence can be individually legal while violating a relationship elsewhere.
For Voynich, possible tests include:
- If label family X appears, must visual component family Y usually appear?
- If entry architecture A exists, must one of component families B/C be present?
- If a rare form occurs in one interface, must it also occur in a related prose population?
- Do repeated structures maintain stable cross-layer pairings?
A violation of a cross-layer relationship may be more informative than an unusual local token.
Referential Integrity: Does the Manuscript Contain Broken Relationships?
In a relational database, a reference should normally point to something that exists.
A broken foreign key creates an orphan.
The manuscript may contain the codicological equivalent of broken references because leaves are missing or order changed.
Imagine a repeated label class whose associated visual counterpart is present almost everywhere except one damaged region.
Or an entry-like structure whose expected companion appears on the conjugate leaf rather than nearby.
Database thinking encourages us to mark such cases as orphan candidates rather than forcing an interpretation.
Then test whether the missing relationship can be explained by:
- damage;
- missing leaf;
- rebinding;
- different local schema;
- false relation hypothesis.
This creates a new way to combine codicology with text and image structure.
Transactions: Which Changes Belong Together?
Database transactions group several changes into one logical operation.
The manuscript does not execute transactions.
But production events often occur in bundles.
A scribe may add text and labels in one campaign.
Colour may be added later.
Folio numbering may be later still.
The transaction tangent asks whether several physical or scribal changes should be treated as one production event rather than independent facts.
Possible grouped evidence:
- same ink behaviour;
- same hand;
- same sequence of layer overlap;
- same page region;
- same correction pattern;
- same material phase.
This creates a more disciplined production history.
One should not assume every visible layer was written at one moment merely because it now occupies one page.
ACID as an Alien Stress Test
Modern databases often describe transaction guarantees through atomicity, consistency, isolation and durability.
Voynich is not transactional software. But the four words generate useful research questions.
| Borrowed concept | Tangential Voynich question |
|---|---|
| Atomicity | Which observed changes are best treated as one production event rather than separate ones? |
| Consistency | Which structural constraints survive across pages and production layers? |
| Isolation | Can one layer—text, drawing, paint, later foliation—be analysed without contaminating another? |
| Durability | Which structural relations survive copying, damage, rebinding and later handling? |
All four computing terms vanish after metaphor removal.
The four measurement problems remain surprisingly useful.
Eventual Consistency: Not Every Part Needs to Match Immediately
Distributed databases sometimes permit temporary local disagreement while converging later.
This offers an alien model for collaborative or multi-scribe production.
Several scribes may work within a shared convention without producing identical local distributions.
Shared rule does not require local uniformity.
The test becomes:
Do local hand-specific variations converge on common higher-level constraints?
If yes, local differences may reflect implementation variation rather than wholly separate systems.
If no, the shared-system hypothesis weakens.
This complements operating-system kernel thinking but frames the problem through data consistency rather than execution.
Relational Database vs Document Database: One Model May Be Too Rigid
Not all databases are relational.
A document database can store records with flexible fields. A graph database can foreground relationships. A key-value store can minimise schema.
This matters because forcing Voynich into a single tabular representation may reproduce the same mistake as forcing it into one semantic section map.
Different representations should compete.
| Database world | Voynich question it generates |
|---|---|
| Relational | Are there stable records, fields, keys and joins? |
| Document | Do local page units share partial structure without identical fields? |
| Graph | Are relationships more stable than record boundaries? |
| Key-value | Do some short forms map consistently to larger structural bundles? |
The winning representation is not the one that sounds most elegant.
It is the one that predicts unseen structure with the least semantic leakage.
Graph Database: What If Relationships Matter More Than Entries?
A graph database treats nodes and relations as first-class objects.
This gives us a powerful fallback if record boundaries remain ambiguous.
Perhaps the manuscript is structurally easier to describe as relations among:
- pages;
- bifolia;
- hands;
- text families;
- visual component families;
- boundary types;
- interface types;
- distributional clusters.
A single page can belong to many relationships at once.
This aligns naturally with the hypergraph interpretation emerging from the mathematics article.
Database thinking therefore reaches an unexpected conclusion:
The manuscript may be more faithfully modelled by relationships among overlapping entities than by one hierarchical catalogue of sections.
Again: this is a modelling choice, not a historical claim.
Data Lineage: Every Derived Claim Should Know Where It Came From
Modern data systems track lineage: where a value originated, which transformations produced it and which downstream outputs depend on it.
Voynich desperately needs the same discipline.
Suppose a claim says a token family is associated with a visual class.
Its lineage should preserve:
- transcription source;
- segmentation scheme;
- page inclusion list;
- visual coding version;
- statistical transformation;
- threshold choice;
- known exclusions.
If the result changes when one upstream assumption changes, that dependency should remain visible.
A result without lineage is difficult to audit and easy to overstate.
The database tangent therefore strengthens evidence custody across the whole Voynich programme.
Provenance and Data Lineage Are Not the Same Question
This distinction matters because the word provenance appears in both manuscript studies and data systems.
Historical provenance asks where the physical manuscript came from and who owned or produced it.
Analytical lineage asks where a modern research claim came from.
They must not be collapsed.
A database-style research pipeline can improve claim lineage without adding one gram of evidence for Padua, Prague, Vienna or anywhere else.
This protects the existing Padua firewall:
Better analytical organisation does not become historical localisation.
The M5 Temptation: Entry-Like Is Not Inventory
The database false world becomes especially seductive around the manuscript’s short-entry populations.
The frozen neutral morphology programme isolates an M5 class characterised by small plant-part and container-like forms, with much of the associated layout behaving as short entry-like structures.
That is exactly where an analyst could leap from geometry to genre:
Entries → records → catalogue → inventory → pharmacy.
Tangential Voynich forbids that chain.
The database tangent may ask whether the entries possess repeated fields, stable boundary patterns, key-like forms or missing-value behaviour.
Even if all those survive, the conclusion remains structural.
Entry-like architecture can be measured without naming the entries.
Historically plausible genres can be tested later against real comparator manuscripts, including Apothecary Inventories and Wellcome MS.5262.
The modern database comes first as a high-distance question generator. The medieval comparator comes later as the historically legitimate genre test.
Orphan Records: Missing Leaves Become a Relational Problem
One of the strongest database transfers concerns missing leaves.
If one page type repeatedly has a structural partner and a surviving page lacks that partner, there are two broad possibilities:
- the relational model is wrong;
- the counterpart has been lost, displaced or damaged.
Database thinking gives us a method for ranking these possibilities.
Build expected relations from surviving high-confidence examples.
Then search for unmatched survivors.
Finally compare the orphans against codicological evidence for missing material.
Textual and visual orphanhood can become an independent clue in quire reconstruction.
This is a genuinely new bridge between the physical manuscript and abstract relational modelling.
Cardinality: One-to-One, One-to-Many, Many-to-Many
Database relationships have cardinality.
One person can have many orders.
One order can contain many products.
Many students can take many courses.
This creates a much more precise way to describe recurring Voynich associations.
Suppose visual family A appears with label family X.
Is the relation:
- almost one-to-one;
- one visual family to many labels;
- many visual families to one label;
- many-to-many?
Those patterns carry very different implications.
A nearly one-to-one mapping may support identification or direct labelling more strongly than a diffuse many-to-many association.
A many-to-many relation may indicate category, context, reuse or weak association.
Cardinality gives us a way to quantify relationship specificity before semantics.
Functional Dependencies: If X Is Known, Does Y Become Predictable?
In relational theory, a functional dependency exists when one attribute determines another.
Written abstractly:
X → Y
The database tangent asks whether any neutral Voynich features behave this way.
Examples:
- Does page morphology strongly constrain geometry class?
- Does line-start state strongly constrain one glyph family?
- Does a visual component family predict a label class?
- Does hand identity constrain Currier regime?
- Does one interface class predict boundary behaviour?
The existing Test 1b matrix already gives us several descriptive associations, but database thinking asks for stronger directional predictability.
Association is symmetric.
Dependency asks whether knowing X materially reduces uncertainty about Y.
This is a useful upgrade in question precision.
Candidate Keys and Superkeys: Several Things May Identify the Same Structural Class
A database can possess several candidate keys.
More than one set of attributes can identify the same record.
This may help us think about the manuscript’s overlapping classifications.
A page could potentially be identified by:
- hand + morphology;
- Currier regime + geometry;
- quire + visual component family;
- interface type + distributional cluster.
If several independent combinations repeatedly pick out the same population, that population becomes more robust.
This does not tell us its meaning.
It tells us that multiple neutral routes converge on one structural object.
That is valuable.
Data Quality: A Beautiful Query Over Bad Data Is Still Bad Research
Database systems are only as reliable as their data.
Voynich analysis inherits uncertainty from transcription, damaged glyphs, ambiguous spacing, uncertain order and visual coding.
The database tangent turns this into explicit data-quality dimensions:
- Completeness: how much of the relevant manuscript population is represented?
- Accuracy: how reliable is the transcription or coding?
- Consistency: are coding rules stable across pages and coders?
- Uniqueness: are duplicate records or duplicate interpretations being counted twice?
- Timeliness: does the dataset reflect the latest corrected transcription or codicological reconstruction?
A sophisticated model on a contaminated transcription can produce precise nonsense.
Database precision cannot repair uncertain source reality.
Reverse Tangential Test: Hide the Schema of a Real Database
The database tangent becomes properly scientific when we reverse it.
Take a known database.
Remove table names.
Remove column names.
Replace values with anonymised symbols or categories while preserving relational structure.
Then ask whether Voynich-style methods can recover:
- record boundaries;
- field classes;
- candidate keys;
- foreign-key relationships;
- cardinality;
- schema families;
- duplicate entities;
- missing-value regimes;
- orphan records;
- indexes or retrieval markers;
- schema evolution.
Then make the test harder.
Export the same underlying database into different representations: relational tables, JSON documents and graph edges.
Can our methods recover the same hidden relations despite representation changes?
If our method cannot rediscover known relations after labels are hidden, it should not be trusted to invent relations in Voynich.
What Would Make the Database World Fail?
| Database projection | Failure condition | Neutral residue |
|---|---|---|
| Record | Entry boundaries do not predict stable internal structure. | No robust record-like unit. |
| Field | Position classes are unstable or indistinguishable. | No repeatable field-like roles. |
| Key | Candidate identifier relationships disappear under frequency and cross-validation controls. | No key-like class. |
| Join | Cross-page associations do not survive matched nulls. | Physical or local relations may dominate. |
| Schema | Page architectures require extensive exceptions. | No compact schema under tested representation. |
| NULL regime | Missingness categories cannot be distinguished reliably. | Absence remains unresolved. |
| Index | Markers do not improve retrieval or partition stable classes. | No index-like role. |
| Schema drift | Structural changes do not align with independent production axes. | Variation may not reflect production evolution. |
| Orphan relation | Expected counterparts are not more common near damaged or missing regions. | Relation model may be wrong. |
As always, the false world is allowed to die.
Its job is to produce measurements, not survive.
The Database Experiment Pack
- Record-boundary scan: test whether repeated entry-like bundles possess stable starts, ends and internal positions.
- Field-role analysis: test whether positions within bundles draw from distinct structural populations.
- Candidate-key scan: search for recurrent forms that identify stable cross-layer bundles beyond frequency.
- Composite-key analysis: test whether multi-axis feature combinations identify populations more reliably than single features.
- Foreign-reference test: identify short forms that bridge visual, label and running-text interfaces.
- Join analysis: search for stable relationships across non-adjacent pages and populations.
- Typed-missingness register: separate not observed, unknown, damaged, not applicable and not expected.
- Duplicate/entity-resolution test: distinguish copied templates, recurring classes and candidate repeated entities.
- Schema induction: infer page-architecture expectations without semantic section names.
- Schema-drift test: compare structural changes against hand, quire, bifolio and morphology boundaries.
- Index-marker test: ask whether recurring markers improve partition or retrieval of structural classes.
- Cardinality analysis: quantify one-to-one, one-to-many and many-to-many cross-layer relations.
- Functional-dependency scan: measure which neutral features strongly reduce uncertainty about others.
- Orphan-relation test: compare unmatched expected counterparts against damage and missing-leaf evidence.
- Reverse database calibration: anonymise known databases and test whether the same methods recover schema and relations.
- Representation challenge: compare relational, document and graph encodings of the same control data.
- Held-out Voynich gate: freeze unseen pages before relation thresholds are tuned.
- Metaphor removal: restate every surviving result without database terminology.
Four Wrong Worlds, One Growing Invariant Suite
Tangential Voynich now has four active false worlds.
Railway control.
Operating systems.
Compilers.
Databases.
The database adds several new neutral measurements while reinforcing older ones.
| Neutral measurement | Railway | Operating system | Compiler | Database |
|---|---|---|---|---|
| Boundary-conditioned change | Terminal | Boot / shutdown | Scope / statement boundary | Record boundary |
| Structural bridge | Interchange | IPC / system call | Transition mediator | Foreign key / join |
| Stable exclusion | Route conflict | Permission / mutex | Syntax prohibition | Constraint violation |
| Persistent local influence | Delay propagation | Memory | Recovery length | Cross-record dependency |
| Shared deeper rules | Lines share network | Processes share kernel | Strings share grammar | Records share schema |
| Representation sensitivity | Node definition | State definition | Lexer choice | Relational/document/graph model |
| Missingness | Closed route / absent service | Unavailable state | Missing token / error | Typed NULL / orphan relation |
| Known-world calibration | Anonymised railway | Anonymised OS trace | Anonymised code | Anonymised database |
Something important is happening.
The metaphors continue to diverge.
The measurements continue to converge.
The more unrelated the wrong worlds become, the more interesting their shared residue becomes.
Metaphor Removal
Now delete the database.
Remove tables.
Remove rows.
Remove keys, joins, indexes, NULLs and schemas.
What remains?
- Some manuscript regions may contain repeatable bounded entry structures.
- Positions inside larger bundles may carry stable structural roles.
- Recurrent forms may be tested for cross-layer identification rather than assumed lexical meaning.
- Identity may require combinations of several neutral features.
- Non-adjacent pages can be structurally related despite present codex order.
- Missingness should be separated into distinct evidence states.
- Repeated structures require entity-resolution tests before they are counted as repeated objects.
- Page populations may follow repeatable architectures without earning semantic section names.
- Structural conventions may change across production phases.
- Markers may organise retrieval rather than encode content.
- Relationship specificity can be quantified through cardinality.
- Cross-layer predictive dependencies may be more informative than simple association.
- Expected-but-missing counterparts can contribute to physical reconstruction.
- Research claims should preserve analytical lineage.
- Different representations of the same evidence should compete on predictive survival.
Those are all legitimate research questions without a database.
The database has disappeared.
The relational questions remain.
World Return
The Voynich Manuscript is not a database.
But database thinking has changed the shape of the unknown.
It asks whether we are looking at records before we know their genre.
Whether some forms identify recurring structural bundles.
Whether labels point outward rather than explain locally.
Whether distant pages belong together despite present binding.
Whether absence is unknown, damaged, inapplicable or genuinely prohibited.
Whether repeated page architectures are different topics—or different views.
Whether a missing leaf can be detected partly because relationships elsewhere imply an orphan.
And perhaps most importantly, it asks us to separate the object from the query we happen to be running against it.
The manuscript may not be a message waiting for one correct reading path. It may be an object whose relationships have to be reconstructed before any reading path becomes trustworthy.
That is not a database claim.
It is the residue the database leaves behind.
Tangential Voynich: The Wrong-System Protocol → · Compiler Experiment → · Operating-System Experiment → · Railway Control Experiment → · Voynich Research Library →
Next Tangent: treat the manuscript as a filesystem. Directories, paths, inheritance, fragmentation, links, orphan blocks, permissions and mount points will force the question of whether the codex’s visible order is the same thing as its logical organisation.
NEXT FALSE WORLD · FILESYSTEM
The database established that distant elements may share relations. The filesystem asks the harder reconstruction question: could physically separated survivors belong to one logical structure, while present neighbours do not?
Continue to Tangential Voynich | Treat the Manuscript as a Filesystem →