1. How does Hazou know about logic gates?
In this case, logic gates are an abstraction I'm using because of my particular knowledge base. Hasou would almost certainly think of them completely differently. A lot of the operations we think of as logic gates are a natural byproduct of requiring a list of instructions to change based on input. "If someone triggers it, but it has already been triggered before, make it explode" etc.. Hasou would probably not think of a component as an "XOR" gate, he'd probably think of it as component that does something when only one of the inputs is "on".
He's already got "on" and "off", notions like "and" and "or" descend from that naturally. For basic analog operations, "greater than", "less than", "amplify", are already there conceptually even if his vocabulary would be much less concise than ours. He wouldn't have any of the frequency space operations, like low pass or high pass filters unless he notices components doing that to a signal, and that's a long shot at best.
What I'm not doing is assuming that he has an mathematical understanding of the logic he's working with. Even when I talk about a transition matrix, that's a term that we use because we know there's a number of mathematical operations that apply to such a matrix. Hazou wouldn't know that, he'd think of it as a lookup table, "If in this state, with this input, go to this other state, send this output".
This sort of thinking has to exist within legal codes, mission instructions, and various schools of tradecraft. Hazou has to realize that he can represent the same things without using natural language. I also fully expect sealing lore to come with a lot of the basic stuff, for reasons I talk about below,
2. How does he know about modularity at all? That's not a thing that exists at this tech level.
I very much doubt that. Mostly because of the nature of every single engineering discipline. People can't really hold an incredibly complex system in their heads at one, we have to create layers of abstraction.
Assuming that humans still think in broadly the same way, modularity has to be a part of sealing. Especially at the higher levels. The difference is in how that is modularity is expressed.
Take assembly programming for instance, especially if you're on a really old machine that's memory constrained. The development process, even back in the day before C and higher level programming languages, had people sketch out how their system will function as pseudo code. Then they turned portions of the pseudocode into actual sequences of instructions, and then optimized those sequences of instructions till it fit on the available memory.
Even then, their source is littered with comments on exactly what relation the final code had to the higher level abstractions. Likewise, with electrical engineering at the "we have discrete transistors or vacuum tubes" level. People sketched out block diagrams, then turned those block diagrams into gate assemblies while making sure power and other constraints were met. Then connected those gate assemblies and tried to find further optimizations.
Every last bit of this process was done on paper, because building circuits is hard, or the unfinished code wouldn't fit in memory. But the process was done, because humans can't handle more than a certain amount of complexity at once.
Modularity must exist in sealing, for it to be vaguely viable. Especially in a context where failure is so costly. There's some really cool stuff around software development in the apollo landing era, where programs had to be coded in by wrapping wire spools in careful patterns around ferrite cores, even then we needed modularity to keep things from going bad and making sure safety exists. That modularity only showed up on paper and was invisible when looking at the core loop memory, but it existed.
If sealing comes with some modularity, even if it's only really visible on paper, then it probably also comes with some basic notion of logic.
4. Seals have been around for hundreds if not thousands of years. Why has no one else ever thought of this?
The innovation here is not that Hazou is inventing modularity, it's that he's realized Iron Nerve's ability to reproduce images makes his modularity more powerful. Hazou is shifting his style to take better advantage of the power of Iron Nerve. He's moving the modularity from the on paper designs, to the ... err ... on paper designs. You know what I mean.
It's pretty much exactly what we do now when we have compute cycles to spare. Nobody optimizes assembly for their entire program, and the actual assembly generated high level code does tons of things that aren't actually neccesary to accomplish the task.
My theory is that everyone else's seals are like the core loop memory, they've taken time during design to remove every unnecessary stroke of the brush because each of those strokes is another place where they could make an error when writing the seal out. Hazou can trust iron nerve to make reproducible patterns, so he doesn't have to spend his time optimizing out every unnecessary edge case. He saves the time that others spend optimizing seals to make them more reliable because his bloodline already makes them reliable. He can probably also write them a good bit smaller without issue.
He also gets another advantage from this, which is that if he's reusing components anyway he can spend some extra time making sure they're all well designed, as efficient as possible, and design interfaces that are hard to break. That way he can actually treat the components as black boxes during design, trusting that they won't violate some fundamental constraint because he decided to merge part of the sealing system, and the logic controlling the sealing to save space. Which also helps design happen faster.
Normally those checks would have to be done for the entire seal at a high-level
and for the individual portions of a seal. If Hazou is reusing components, he's already done the low-level checks for each component, and only has to test the high level portions.
3. Why would a seal -- which, by definition, fails in chaotic and random ways -- become 'fail safe' (as opposed to 'fail Cthulhu') simply because it's modular? Each component is a separate seal.
Not quite, the 'fail Cthulhu' would still happen when developing components, and it wouldn't quite 'fail safe' in any case. The idea is that he's tested his components rigorously and, as long as he doesn't break his interface rules when designing seals, they would only do things the components should do individually.
When combining an explosive component with some logic to create a explosive seal. His tests may still explode at the wrong time, or otherwise function wrong, but components don't interact in unexpected ways to create new cthulhu failure modes. Which is not to say there might not be a mistake in the individual component making them 'fail cthulhu', but the probability is lower than before. In the end, he has a much reduced rate of 'fail cthulhu' for seal designs, and a similar rate of 'fail stupid' style logic errors, leading to a somewhat lower rate of overall error.
More predictable failure modes means that safety is easier too, since you can focus on protecting yourself from the most likely issues.
Edit:
On the one hand, chakrapunk information technology would be amazing to write. On the other hand, I don't think that seals work like this. I'll need to talk with
@Velorien about it.
I think that would be awesome too. It's not going to happen any time soon, even with this. Hazou'd develop stuff faster, since he doesn't have to optimize as much and can more easily reuse bits, but there's still a limit to the complexity he could handle.
My mental model is for even a simple computer, simply writing the entire seal out is like drawing the gate level diagram out by hand and never making a mistake. This is ludicrous, probably even with Iron Nerve something will be smudged. If we ever get enough to technique hacking or sealing to stamp out seals in an instant, then maybe. Though, even that is probably at least a few in-game years away for something as complex as a computer.
Anyway, that my current set of hypotheses and explanations. Feel free to word of god it into inaccuracy. Also, even if you think the general idea is sound, you should probably tweak the constants on the proposed crunch. They were not chosen with any real rigor.
Also, I state things like they're facts, but it's the world you designed. I'm not trying to tell you that you're doing it wrong or anything. It's just easier to write this way and not put caveats and conditions in front of bloody everything.
