This blog explores the Commandments as seen on the Staff and Tablets Tabernacles items.


Over the past few weeks I have been dividing my time between design work in the mornings and shop work in the afternoons. After finishing code for at least a prototype of the ciphers I turned my attention to the Commandments.

Early this spring Ryan and I worked out the letter based string for the commandments. That letter string is important to the Shepherd's Staff and Tablets articles in the Tabernacle.

Ryan and I did that work together informally using Inkscape. That was OK for the process of discovery, but it was not in any sort of format that would lend itself to 3d printing.

So I needed to get software control of the letter string for the commandments. I needed those letters in a form ready to apply in the 3d design software so the commandments could be 3d printed.

I also realized that once I had that string inside better software I could use the commandments as a test case for the ciphers. Testing the ciphers against the commandments is a good way to confirm my general understanding of the entire process of manuscript multiplication.


The stone tablets that Moses brought down from the mountain were kept in a box called the ark of the Testimony. These Tablets and their box are yet another Tabernacle item. So they are on my list of items still to design.

The first question that caused me trouble was this: Why do the commandments naturally live on the Shepherd's Staff and also on the Tablets?

There is an economy to everything in this system and 2 copies in different places breaks my sense of overall design.

Furthermore, why are the tablets described as 2 stones inscribed on both the front and back of each?

So why are there 4 sides of carved writing on these stones?

Are the commandments on the tablets broken into 4 sections? If so why?

Then it dawned on me. Perhaps the staff alone carries the inspired commandments and then those stones carry the ciphered version of the commandments?

If that was the case, presumably Moses went up the mountain with his staff and returned down the mountain with the contents of his staff ciphered into all its various forms.

How Big?

There are of course different ways to arrange 32 sets of writing that are themselves the result of applying the 32 ciphers. But if we are working towards text that aligns back with the staff, then I tend to want to lay out 2 stones that evenly divide the length of the shepherd's staff. So that would be 4 feet wide for each of the 2 stones. They could then sit landscape style next to each other while under the staff itself.

There is an alternative way to do this. Because there are 4 writing sides, it would also be possible to divide the 32 ciphered versions across the 4 sides. Then each side of each stone would have 8 ciphered versions on each face of the 2 stones. In this scenario the stones could more easily stand up in something more like a portrait mode.

In terms of overall writing amount either layout works. Though I have seen what might be happening after the ciphers are run. Most of the ciphers appear to create text shorter than the original commandments. A few of the ciphers create text that is much longer.

So each ciphered version of the commandments does not appear to just line up evenly below 1 staff. So putting 8 different forms on each of the 4 sides will even out and provide room for various lengths.

The surface area of this still works out to stones that are round 4 feet on 1 axis, 2 feet on the other, and maybe 1.5 inches thick. Aside from the thickness, this is a standard size for 'flat grassers' in tombstone catalogs. These are not impossible to carry around, but they are not easy to carry when carved in granite.

I set out to see if I could build the software to do all the steps needed to convert the commandments strings into their ciphered, stone tablet, forms. I finished a first draft of that work early in the week before Tabernacles. Let me give you a status report of what I found.


I have seen other projects augment their 3d design work with regular software code. The first time I ever saw this was years ago at Boeing. The original 777 airplane wing was designed using 3d design software. But, that was the result of other software that precisely computed the shape based on expected airflow around the wing. Humans did not manually use 3d design software to manually match the expected profile of those wings. Specialized software created the exact geometry of the wings which was then fed into the 3d part design system.

Hydro electric turbines and simple gear libraries are other examples where code outside of the 3d design system is doing the same sort of thing.

All of these items are not designed by hand. They have intense mathematics that drive their shape.

The work to apply the ciphers is complex enough that I decided to use regular code to convert the commandments into their ciphered forms.

Of course if we were doing this 2000 years ago, there is a by-hand process of generating and applying the commandments. In this modern case the code makes this process go faster. I still need to manually check the ciphers themselves against a real fig tree model and I need to check the ciphered results.

I built up Javascript code that would take the commandments as simple input and then transform that string in various ways. After several steps, they get converted into all of the various ciphered forms. Essentially everything that would fill the tablets.

This code includes kerning the letters in the resulting strings. This is itself a tricky step. The 3d design system does not know how to write. It needs to know where to put 3d models for the letters. Those locations are computed via data in a Paleo alphabet kerning table.

The kerning table is perhaps yet another Tabernacle item. A rough draft of 3d models that show off the Paleo Alphabet's kerning table is also now done. The kerning rules will need to be tested against inspired text before they are known confidently.

This work also included code for running the audit pattern itself against any string of Paleo letters. This will likely need specialized 3d models to teach, but it already shows up in some of the 3d models to mark audit failures.

This work also included code that strips punctuation in preparation for the ciphers. Punctuation does not go through the cipher system. The trees are pruned so they can produce fruit. The fig tree is pruned before the ciphers are formed.

This also included code that shuffles letters following the lamp's design. Trouble here involved what to do when the inbound length does not properly pack the lamp. This is an area that will need samples from inspired text that prove how that packing should be done.

This also included code that uses the cipher tables to replace letters. There are still questions about details in this area too. Only the simplest possible cases are currently coded. In any case, all of the ciphers can be run against the commandments, generating all the various permutations.

This also included the start of code to 'wean' the ciphered letter strings back to regular Paleo. This involves inserting punctuation back into the result strings. The best I have done so far is shift letters forward so they always pass audit. This is crude and incorrect. More on that below.

Finally there is code to format all the ciphered output ready for use in the 3d system and essentially ready for carving on the tablets.

So the entire flow from the commandments to the tablets is prototyped, but with many steps along the way that will need careful study to understand if the steps are actually operating correctly.

Retesting Commandments

When we originally worked out the commandments we had some questions about a few details. Once this new code was mostly in place I could start testing around the areas where we had questions. All I had to do was type the alternatives and rerun. Very nice. Very fast. Code would kern and audit and display the results.

Other than getting a better grip on the trailing punctuation, I was unable to make any obvious simple changes to the commandments such that they still pass the audit pattern. There remains 1 word which could be spelled in 2 different ways, let me explain.

For the record, the first uninspired word in the commandments is duplicate copy of 'Wa-Ne-Wa.' Normally this pair is translated into English as a single phrase, "I am."

These 2 words must loose 1 of their duplicate copies and then loose either the opening or trailing Wa. Either spelling after dropping a Wa passes the audit system. So the first inspired word in the commandments is either 'Ne-Wa' (which may be the normal I am) or 'Wa-Ne' (normally the word when).

I am inclined to favor the Wa-Ne case. So the commandments might start with "When Joshua (is) God. Don't have gods outside me. Don't..."

This reading makes the commandments into a faith challenge. We prove our faith by doing what the rest of the commandments say to do.

This first word spelling choice is a detail that the cipher system will eventually clear up, but only once a bunch of other stuff comes together.

I don't see any other reasonable and possible spelling variation in the rest of the commandments. This is, of course, without breaking the audit anywhere else along the string while keeping the letters properly kerned.

Adding Back Punctuation

The step that is turning out to be very hard is adding back punctuation to the string that comes out of the ciphering step.

Someone who had complete command of the language would likely look at the string and be able to read it directly. For example, most readers of this blog could make out what I have written even if all the spaces were removed.

Humans are good enough at this that we can even see through letter based replacements. This is why early military letter-based ciphers were so bad.

We don't have enough skill in Paleo yet to be able to read the ciphered output as Paleo writing. We will need software to make this go. That software will need a list of all known words in the text. From such a list it can hint at what might be written in the output of the ciphers.

I hinted in the last blog that we are thinking about a concordance. We seem to hit this need all the time. It is probably time to get busy and go build one given the BRB and a complete Paleo Bible.

NIV Exhaustive Concordance

To this end I read the written introduction to our printed copy of The NIV Exhaustive Concordance by Goodrick and Kohlenberger, finished about 1990. It took 6 people about 7 years to finish this work. There was also software and systems help. They also had help with typesetting. Most of that team's work hours were spent in proof reading. A couple people hired as proof readers where later called out as Associate Editors because of the amount of work done at the proof reading stage.

Their work involved starting with the then newly published NIV English text. Then they took the Hebrew with limited Aramaic text of the Old Testament and the Greek text of the New Testament. They built a careful database that cross referenced all the words in those texts. So they keyed every word in every verse in the NIV English to every word in the same verse in the Hebrew, Aramaic or Greek base text used by the translators.

The key metric of their work is interesting to know. There were about 4,500,000 records in their eventual cross reference database. For each record they kept 5 distinct fields. Most of those fields cross between the original texts and the English.

One of those fields ties their own number system back to the Strongs Number system from the late 1800s. Strongs was done by hand and did not cover all the strange cases that show up in the text. So Strong's Numbers were not sufficient for all the details in their modern NIV Concordance.

Their database and those various fields are what show up in their printed NIV Concordance. It is basically a typeset form of a dump of their database.

We are not likely to actually print a concordance. So does this help reduce the work? The fundamental data structure would be about the same general size. It is a larger document than the original language and English language texts of the Bible combined.

There is another point that stood out to me when I read their introduction. That team considered their concordance to be the proper lexicon for all the words found in the original Hebrew and Greek texts. This is a profound insight. The variation in words as actually used in English shows how real modern translators treated the meaning of the original language terms.

They believed this was more powerful than a lexicon because the actual uses show all the ways the actual original words in the text were ultimately translated into English. They did not see much need for an independent printed Lexicon given their concordance.

In our case, especially with words we can eventually show to be inspired, the spelling itself provides a primary and secondary pair of word definitions. That system belongs in our eventual database for every word in the text.

In our BRB case, we work hard to reduce the wide variation that we know modern translators use in their politically correct translations. So variability is an interesting metric, but any variability found while creating a concordance would likely get removed from the BRB itself.

Their introduction also explains their notation. I like much of their notation, especially how they treat numbers. Most numbers in the modern text are coming from several different original words. They use a very nice notation to show this. They have notations for compound words and for words that assist in translation. They also index all NIV words, which was not done with Strongs.

Building Our Own

The fundamental need is to be able to hint de-ciphered text given a large pile of possible Paleo vocabulary words. There are many other uses of this that go with the BRB text and will go with the inspired TT text.

In particular, it is easy to imagine how the BRB and TT tools could be augmented with notations and popups that would show off what is going on with English word choices. It would also provide the basis for understanding the English that goes with all Paleo words.

So the question is how to go about building such a thing? Especially given our resources.

The first point is to plan to build this in stages. What can we do first that would be useful for manuscript recovery and for cracking the output coming from application of the ciphers?

On the Paleo side we need to pick a stable Paleo Bible text, this is mostly done. On the English side we need to augment the existing BRB text with tags that point at the Paleo words used behind the English that shows up in the BRB. Those tags ultimately key into the concordance.

We will build up the database for the concordance even if all the various fields are not yet filled in. We will make building that database a natural compliment to the work we are already doing.

Ryan and I had a long conversation over Tabernacles Week about how to go about this. We have a plan that involves a few immediate steps, mostly code changes within our existing tool chains.

The big step is to rebuild some very old code that handles the tagging system for the BRB text itself. That old code has been a thorn in my side for a long time already. Every time I need to touch it I cringe.

I will be rewriting that system. First step is to make it a 2+ pass system as modern computers have plenty of room. The old code is so hard because it was built as a 1 pass system.

Once that is done it will get new tags for marking the Paleo words that go with the English there. At the same time Ryan needs an address system that runs sub-verse and he also needs poetry formatting. Those will also get added at the same time.

The Paleo Bible text will also get stabilized so there is a Paleo language verse to go with every English verse. This will also give us a stable list of all known words in the Bible itself.

Number assignment is always a big problem in concordances. It was a big problem for Strongs in the 1800s and it was for the NIV work too. I will assign numbers to every Paleo word in a way that is driven by the spelling of those words. So it will be a sparse list of numbers. It will allow the future creation of numbers for inspired words that are not found in any of the texts passed by history.

With the recent work from the commandments now turned into Javascript, we should be able to kern and audit all the words across the entire text of the Paleo Bible. We should also be able to audit all sentences. In many cases words are legal, but they are not legal in relation to other words. We should be able to see this for the first time across the entire text.

From there we should be able to generate possible word lists that can be used for understanding the text that comes out of the ciphers and then goes on to the Tablets.

This is not going to be a quick work, but we have a plan for the next several steps.

New 3D Printer

A few weeks ago I woke with an intense vision of getting a Voron printer in order to make printing large 3d objects easier to do. That vision would not clear until I asked in the blog for help getting one of those printers. A reader here saw my request and helped out by shipping one of them here. That printer is now in the shop. This work has become a big group effort. Thank you to everyone who is helping this work advance.

The new Voron 3d printer is a kit, waiting for assembly. Most of the plastic parts for that printer need to be 3d printed. One of the older printers in the shop is now doing that 3d printing work. I found a list that shows a possible print sequence for those parts that matches the assembly order, so those parts will be 3d printed "Just In Time" for the assembly steps.

Once Tabernacles is over I will return to normal work. My intent is to continue with design and computer work in the mornings and then do shop work in the afternoons. This split in my personal work time is working out pretty well.

For office time, after the new tag library for the BRB is done, I will continue to work designs for Tabernacles Items. For shop time, once the new 3d Printer is running, I will finish printing the Fig Tree.

When I generated the ciphers that are central to much of this work, I made some assumptions about how the ciphers are generated that might or might not be witnessed by the actual 3d models of the Fig Tree. So that is where I am slowly headed.

More Later,