The StackChan firmware speaks 20 packet types. The bridge that connects it to Hermes speaks 6. The other 14 are in the firmware, documented, tested, available — and deliberately left alone. The design rule: prefer sparse, intentional motion over constant animation.
A decision table for ML tooling makes the same move. DSPy can optimize any stable LLM task and has documented conditions for use, but the table’s clearest guidance is for when to skip it. No real eval set means DSPy is premature. Most tasks have no eval sets. Most of the time, plain prompting is enough.
Same structure, different materials. A larger space of operations exists; the correct implementation uses a fraction of it. The gap between available and chosen is where the design lives.
Including everything is the lazy path: expose all packet types, wire up every framework from the start, add features when asked. Knowing which 6 of 20, which framework for which phase — and then holding to that when the other 14 are right there, supported, documented, available — is the actual work.
Protocol design calls this “expose what the peer actually needs”; firmware calls it “sparse, intentional motion.” Different fields, same discipline: leaving a capability unexploited because the cost of reaching it now is higher than waiting until you know why.