The Mason Who Built Everything From Scratch
Before Modin arrived, every palace was built from raw stone. Each builder cut their own bricks from whatever rock they found. The south palace's bricks were slightly too large. The north palace's arches were slightly too narrow. They looked alike from a distance, but no part from one palace could be moved to the other. When the Rajah said "add a tower like the one on the south palace," a month of work began. Modin watched this for a season and thought: "There is a better way."
“Inconsistency is waste that hides in similarity.”
The Art of the Pre-Formed Block
Modin built the first module: a pre-formed gateway arch. It had three parameters — width, height, and stone colour. Give Modin those three values and he returned a finished arch, identical every time. He put the arch's blueprints in a file called gateway.bicep. Then he built a module for a tower, one for a well, one for a great hall. Each module was a complete, tested, reusable piece. Roopa the architect discovered she could describe a palace by naming modules and providing their parameters. Her main blueprint became short — a list of modules and their settings.
“A library of tested pieces is faster than a mountain of raw stone.”
Inputs and Outputs
Every module had an entrance and an exit. The entrance was its parameters — what you gave it. The exit was its outputs — what it gave back. When Roopa called the gateway module, she gave it width and colour. The module gave back the gateway's resource identity. Roopa passed that identity to the wall module: "Build a wall attached to this gateway." The wall module took the identity as its own parameter. Outputs from one module became inputs to the next. The palace was a chain of connected pieces, each piece knowing only its own job.
“A module that cannot report what it built cannot be connected to what comes after.”
The Registry
Modin's modules proved so useful that other architects from distant provinces wanted them. He sent his files to the Registry — Bhandar, the great stone library. Any architect who knew the address could fetch the arch module with a single line: "From Bhandar, the gateway module, version two, painted white, width ten." The address pinned the version. An architect could trust that next year's arch would be the same as this year's arch, because she had pinned "version two." Bhandar held the public modules of all guilds, and Modin's guild hosted their own private registry for internal designs.
“A shared registry is the difference between a personal tool and a guild standard.”
Conditions and Loops
One day the Rajah asked for a palace with wells — but only in the drought provinces, not in the river provinces. And he wanted seven stables, not one. Roopa showed Modin how modules could be conditional: "if drought, include the well module." And they could loop: "for each of seven names, call the stable module with that name." The same palace blueprint now described palaces for all provinces and all stable-counts, without a separate blueprint for each. The module absorbed the variation. The architect's file stayed small.
“A module that accepts conditions and loops replaces a shelf of blueprints.”
The Gift to the Next Generation
A decade passed. Roopa retired. Her apprentice, Chetan, inherited the palace blueprints. He opened the main file and found thirty lines — module calls, each with four or five parameters. He found no tangled dependencies, no repeated stone measurements, no guesswork about what "width" meant (each module had a description on every parameter). In an afternoon Chetan understood every palace Roopa had ever built. He added a new module for a clock tower, published it to Bhandar, and the entire guild had a clock tower available the next morning.
“The true test of a module library is whether the next builder can read it alone.”
🪔 Deepak — the lamp of meaning · what this fable means in code
Bicep modules are reusable .bicep files with parameters (inputs) and outputs. They can be called from a parent Bicep file, with outputs chained as parameters to subsequent modules. Module sources range from local paths to the public Bicep Registry (like Bhandar) to private Azure Container Registry. Conditions (if) and loops (for) let a single module handle variation. The param decorator system provides descriptions and validation on every input. The result: composable, documented, version-pinned infrastructure you can share across teams.