From e2df21e210cbc13fe6f573403050ae8fcf035e97 Mon Sep 17 00:00:00 2001
From: Zane Meyers <zanemeyers@gmail.com>
Date: Thu, 25 Sep 2025 16:45:58 -0400
Subject: [PATCH] vault backup: 2025-09-25 16:45:58

---
 .../plugins/recent-files-obsidian/data.json   | 140 +++++++++---------
 estimating-as-code.md                         |   5 +
 estimating-methodologies.md                   | 104 +++++++++++++
 functional-estimating.md                      | 139 +++++++++++++++++
 grounding.md                                  |   4 +
 risk-oriented-estimating.md                   | 102 ++++++++++++-
 traditional-estimating-methods.md             |  36 +++++
 7 files changed, 454 insertions(+), 76 deletions(-)
 create mode 100644 estimating-methodologies.md
 create mode 100644 functional-estimating.md

diff --git a/.obsidian/plugins/recent-files-obsidian/data.json b/.obsidian/plugins/recent-files-obsidian/data.json
index 19d6e2e..f33d58f 100644
--- a/.obsidian/plugins/recent-files-obsidian/data.json
+++ b/.obsidian/plugins/recent-files-obsidian/data.json
@@ -1,12 +1,80 @@
 {
   "recentFiles": [
+    {
+      "basename": "grounding",
+      "path": "grounding.md"
+    },
+    {
+      "basename": "README",
+      "path": "README.md"
+    },
+    {
+      "basename": "feeders",
+      "path": "feeders.md"
+    },
+    {
+      "basename": "estimating-as-code",
+      "path": "estimating-as-code.md"
+    },
     {
       "basename": "full-takeoff",
       "path": "full-takeoff.md"
     },
     {
-      "basename": "README",
-      "path": "README.md"
+      "basename": "construction-estimating-software",
+      "path": "construction-estimating-software.md"
+    },
+    {
+      "basename": "3-phase-power",
+      "path": "3-phase-power.md"
+    },
+    {
+      "basename": "90-day-performance-review",
+      "path": "90-day-performance-review.md"
+    },
+    {
+      "basename": "breakdowns",
+      "path": "breakdowns.md"
+    },
+    {
+      "basename": "functional-estimating",
+      "path": "functional-estimating.md"
+    },
+    {
+      "basename": "uncertainty",
+      "path": "uncertainty.md"
+    },
+    {
+      "basename": "raceway-terms",
+      "path": "raceway-terms.md"
+    },
+    {
+      "basename": "risk",
+      "path": "risk.md"
+    },
+    {
+      "basename": "risk-oriented-estimating",
+      "path": "risk-oriented-estimating.md"
+    },
+    {
+      "basename": "functional-labor-factoring",
+      "path": "functional-labor-factoring.md"
+    },
+    {
+      "basename": "traditional-estimating-methods",
+      "path": "traditional-estimating-methods.md"
+    },
+    {
+      "basename": "standalone-systems",
+      "path": "standalone-systems.md"
+    },
+    {
+      "basename": "sleeving",
+      "path": "sleeving.md"
+    },
+    {
+      "basename": "estimating-methodologies",
+      "path": "estimating-methodologies.md"
     },
     {
       "basename": "realism-vs-instrumentalism",
@@ -36,18 +104,10 @@
       "basename": "breakdown-objects",
       "path": "breakdown-objects.md"
     },
-    {
-      "basename": "feeders",
-      "path": "feeders.md"
-    },
     {
       "basename": "pre-takeoff-confirmation",
       "path": "pre-takeoff-confirmation.md"
     },
-    {
-      "basename": "breakdowns",
-      "path": "breakdowns.md"
-    },
     {
       "basename": "subfeeds",
       "path": "subfeeds.md"
@@ -60,10 +120,6 @@
       "basename": "2025-07-18_estimating-isnt-engineering",
       "path": "2025-07-18_estimating-isnt-engineering.md"
     },
-    {
-      "basename": "estimating-as-code",
-      "path": "estimating-as-code.md"
-    },
     {
       "basename": "markdown-formatter-cli",
       "path": "markdown-formatter-cli.md"
@@ -112,10 +168,6 @@
       "basename": "distributed-antenna-systems",
       "path": "distributed-antenna-systems.md"
     },
-    {
-      "basename": "standalone-systems",
-      "path": "standalone-systems.md"
-    },
     {
       "basename": "area-of-refuge",
       "path": "area-of-refuge.md"
@@ -147,58 +199,6 @@
     {
       "basename": "electrical",
       "path": "electrical.md"
-    },
-    {
-      "basename": "electrical-estimating-methods",
-      "path": "electrical-estimating-methods.md"
-    },
-    {
-      "basename": "electrical-estimators-manual",
-      "path": "electrical-estimators-manual.md"
-    },
-    {
-      "basename": "excel-macros",
-      "path": "excel-macros.md"
-    },
-    {
-      "basename": "estimator-skills",
-      "path": "estimator-skills.md"
-    },
-    {
-      "basename": "estimating-philosophy",
-      "path": "estimating-philosophy.md"
-    },
-    {
-      "basename": "grounding",
-      "path": "grounding.md"
-    },
-    {
-      "basename": "material-pricing",
-      "path": "material-pricing.md"
-    },
-    {
-      "basename": "me",
-      "path": "me.md"
-    },
-    {
-      "basename": "project-management-tm",
-      "path": "project-management-tm.md"
-    },
-    {
-      "basename": "psn-distribution-list",
-      "path": "psn-distribution-list.md"
-    },
-    {
-      "basename": "raceway-terms",
-      "path": "raceway-terms.md"
-    },
-    {
-      "basename": "requirement-precedence",
-      "path": "requirement-precedence.md"
-    },
-    {
-      "basename": "gold-plating",
-      "path": "gold-plating.md"
     }
   ],
   "omittedPaths": [],
diff --git a/estimating-as-code.md b/estimating-as-code.md
index 451cf5b..d28f0da 100644
--- a/estimating-as-code.md
+++ b/estimating-as-code.md
@@ -9,6 +9,11 @@ tags:
 ---
 # Estimating as Code
 
+## Compared to Existing Frameworks
+
+Traditional methods interact with an existing database.
+EaC builds a static database at runtime.
+
 ## Project Structure
 
 Organizational info (items, assemblies) as submodules.
diff --git a/estimating-methodologies.md b/estimating-methodologies.md
new file mode 100644
index 0000000..f096cbe
--- /dev/null
+++ b/estimating-methodologies.md
@@ -0,0 +1,104 @@
+# Estimating Methodologies
+
+## The 4 Traditional Methodologies
+
+> [!quote] Defense Acquisition University
+> There are four principal cost estimating methodologies:
+> 1. Comparison/analogy,
+> 2. Parametric,
+> 3. Detailed engineering/bottom up, and
+> 4. Extrapolation from actual costs.
+
+### Comparison / Analogy
+
+**Pros:**
+* simple to implement
+* quick in practice
+
+**Cons:**
+* unsatisfying input
+* unsatisfying output
+--
+
+### Parametric
+
+**Pros:**
+* quick in practice
+* nuanced input
+* accounts for incomplete input
+* effectively accurate through the entire estimate process
+* well-suited for automation
+
+**Cons:**
+* complex to implement
+
+### Detailed Engineering / "Bottom-Up"
+
+**Pros:**
+* simple to implement
+* satisfying output
+
+**Cons:**
+* slow in practice
+* unsatisfying input
+* accuracy and risk depend solely on estimator
+* output dependent on complete input
+* ill-suited to automation
+
+### Extrapolation from Actual Costs
+
+Depending on the application this is one is either
+* better described as the previous 3
+* or not estimating at all.
+
+## In Other Industries
+
+There exist articles from software development project management resources
+stating essentially what I believe to be true,
+that parametric estimating is _more_ accurate than bottom-up,
+in contrast to common assumption.
+
+I suspect that industry tolerance for cost-modeling
+is related to the cost of estimation.
+Software is largely impractical to estimate bottom-up,
+whereas anyone can take off construction scope.
+
+Alternate theory:
+tolerance is related to the industry's ability to understand the model.
+
+Regardless, a continuum emerges:
+
+```
+^
+| Software
+| Defense
+| Construction
+v
+```
+
+Industries that would benefit the most from cost-modeling
+are least likely to consider it a valid method.
+
+These methods are actually the same, just different levels of abstraction.
+This can be observed in the _very_ subtle distinction
+between parametric and analogous estimating,
+which also exists in my history-oriented/risk-oriented definitions.
+
+```
+# of Parameters
+^
+| Bottom-Up     (100+)
+| Parametric     (10)
+| Analogous       (1)
+| Extrapolation   (0)
+```
+
+These different methods are just a response
+to different levels of requirement specificity.
+Parametric is obviously more accurate and precise than analogous,
+however the question not being asked
+is if there are diminishing returns to estimate specificity.
+
+Suppose there are, at some point then,
+there must then be a point at which **risk of human error**
+outweighs the value of more perfect information.
diff --git a/functional-estimating.md b/functional-estimating.md
new file mode 100644
index 0000000..fab123b
--- /dev/null
+++ b/functional-estimating.md
@@ -0,0 +1,139 @@
+# Functional Estimating
+
+Suppose a function
+
+$$
+f: ℝ^n \to ℝ
+$$
+
+That is, $f$ takes $n$ real parameters (an $n$-tuple) and returns a single real number.
+
+Suppose we want to determine the number of specified parameters necessary to
+reduce uncertainty of the output to some acceptable range.
+
+There are multiple possible approaches with varying levels of appropriateness.
+
+### [Multisets](https://en.wikipedia.org/wiki/Multiset)
+
+Focused on statistics, we determine we want a _population_ of all values of $f$.
+A true _set_ is insufficient for this use case as duplicate values are not respected.
+
+$$
+g: ℝ^m \to (\text{multisets of real numbers}) \\
+
+g(x_1,...,x_m) = \{\!\{ f(x_1,...,x_m,y_m+1,...y_n) | (y_m+1,...y_n) \in ℝ^{n-m} \}\!\}
+$$
+
+$g(x_1,...,x_m)$ is the uncountably infinite length _multiset_ of all possible
+outputs of $f(x_1,...,x_n)$
+
+### [Partial Application](https://en.wikipedia.org/wiki/Partial_application)
+
+It seems that the more common way of doing what I'm trying to would be to
+partially apply $(x_1,...,x_m)$ to $f(x_1,...,x_n)$
+
+$$
+f: ( X × Y × Z ) \to N \\
+
+\text{partial}(f): (Y × Z) \to N
+$$
+
+then work with the level set of $f_{\text{partial}}$
+
+<https://en.wikipedia.org/wiki/Currying>
+
+
+### [Pushforward Measure](https://en.wikipedia.org/wiki/Pushforward_measure)
+
+Start with a function $f:X \to Y$.
+Think of $X$ as the domain and $Y$ as the codomain.
+
+Pick a [measure](https://en.wikipedia.org/wiki/Measure_(mathematics)) $\mu$ on $X$.
+In general, a measure $\mu$ is a systematic way of assigning a "weight" to subsets of $X$.
+
+In continuous scenarios,
+$\mu$ might be something like the length/area/volume measure (Lebesgue measure)
+or a probability distribution
+(which also assigns a total measure of 1 to the entire domain).
+
+In discrete scenarios, $\mu$ is a count measure:
+each point in $X$ has weight 1,
+so the measure of a finite set is just how many points it has.
+
+Let $f : X \to Y$ be a measurable function and $\mu$ a measure on $X$.
+
+The pushforward measure $f_{\ast}\mu$ is the measure on $Y$ defined by
+
+$$
+\forall B \subseteq Y \text{(measurable)}, \quad
+
+(f_{\ast}\mu)(B) = \mu(\{x \in X : f(x) \in B\})
+$$
+
+In other words, "The measure of a subset $B$ of the codomain ($Y$)
+equals the measure (in $X$) of all points that map into $B$."
+
+$\mu(f^{−1}(\{y\})) =$ the weight (in this case count) assigned to $Y$
+
+If the domain $X$ is finite and $\mu$ is just counting measure:
+
+The pushforward measure $f_{\ast}\mu$ on the codomain $Y$ literally says something like:
+$(f_{\ast}\mu)(\{y\}) =$ the number of times $Y$ appears as an output.
+Equivalent to the multiset $\{\!\{ f(x): x \in X \}\!\}$
+
+When $X$ is infinite (countably or uncountably so),
+we move beyond plain
+"multisets" to a more general concept of "measure on $Y$."
+But it's the same intuitive idea:
+
+Instead of a simple integer count of duplicates, we have a "weight"
+(which could be infinite or fractional, depending on the measure).
+$μ(f−1({y}))$ is how "large" or "frequent" the set of points mapping to $Y$ is,
+according to $\mu$.
+
+## Abstractions
+
+There are two competing abstractions for measure analysis of the project price function:
+
+### Ignoring Aleatory Uncertainty
+
+We assume that price is certain for any defined scope, that _any_ variation in
+price reflects influence of a measurable parameter.
+
+```none
+   f(a_1,...,*,...,a_n)
+ _ ├                
+ │ ├              / 
+ █ ├       ______/  
+ █ ├    __/         
+ │ ├  _/            
+ ▔ ├                
+   └──┴──┴──┴──┴──┴─x_k
+```
+
+$$
+f: ℝ^n \to ℝ
+$$
+
+**Pros:**
+
+* In theory far simpler.
+
+### Accounting for Aleatory Uncertainty
+
+We assume that price is subject to some inherent randomness
+
+```none
+   f(a_1,...,*,...,a_n)
+ ┬ ├           ┬  ┬ 
+ │ ├        ┬  │  █ 
+ █ ├     ┬  █  █  │ 
+ █ ├  ▁  ┿  │  ┴  ┴ 
+ │ ├  ┿  ┴  ┴       
+ ▔ ├  ▔             
+   └──┴──┴──┴──┴──┴─x_k
+```
+
+**Pros:**
+
+* Likely more accurate
diff --git a/grounding.md b/grounding.md
index 4c0eeb1..8fdfe09 100644
--- a/grounding.md
+++ b/grounding.md
@@ -11,6 +11,10 @@ tags:
 This script is intended to cover both electrical and telecom grounding
 in lieu of detail sufficient for standard takeoff (e.g. a grounding riser).
 
+Note that the material provided in this system
+is intended to be budgetary,
+not especially consistent with the actual install.
+
 ## Sequence
 
 ### 1. Estimate preparation
diff --git a/risk-oriented-estimating.md b/risk-oriented-estimating.md
index e5dcfad..e5422d3 100644
--- a/risk-oriented-estimating.md
+++ b/risk-oriented-estimating.md
@@ -7,7 +7,8 @@ tags:
 ---
 # Risk Oriented Estimating
 
-Risk-Oriented Estimating (ROE), is a methodology for [[construction-estimating]] which
+Risk-Oriented Estimating (ROE), is a methodology for [[construction-estimating]]
+which:
 * prioritizes estimating tasks,
 * determines necessary [[estimating-detail]]
 
@@ -27,15 +28,21 @@ Bid risk may fit a [Taleb distribution](https://en.wikipedia.org/wiki/Taleb_dist
 
 Actuarial Science
 
-Estimating as risk mitigation,
-resources allocated by Return on Mitigation (RoM)
-
 %%
 
 ## Prioritizing Tasks
 
 ROE prioritizes estimating tasks by their contribution to _cost certainty_.
 
+### Estimating as Risk Mitigation
+
+* reduce risk of wasted estimation effort due to bid loss
+  (prefer lower bid)
+* reduce risk of project overrun
+  (prefer higher bid)
+
+Estimating resources are allocated by Return on Mitigation (RoM)
+
 ## Determining Necessary Detail
 
 ROE determines the appropriate level of [[estimating-detail]]
@@ -62,6 +69,7 @@ Optimizing the takeoff process means:
 > Recent events have complicated my philosophy above.
 > It appears that similar efforts have already been made here,
 > their success being a matter of perspective.
+> Is it acceptable that optimal 
 
 #### Naming Conventions (Use Case vs. Description)
 
@@ -74,6 +82,88 @@ will inevitably _treat them as descriptive_.
 | Hi-Hat              | Daisy-Chain   |
 | Furnished By Others | Rough-In Only |
 
-## Going Further
+## Potential Objections
 
-[[functional-labor-factoring]]
+Objections to the use of historical data in new estimates are not unfounded. A
+framework to do so competently and consistently does not currently exist.
+
+> [!info]
+> Nor does the software necessary to utilize such a framework efficiently.
+
+The goal in and of itself ought not be controversial, however.
+Businesses regularly make far riskier decisions based on projections
+informed by the same data.
+
+By definition, if one could adjust historical pricing accurately for all dependent factors,
+the adjusted price would be accurate to the new job.
+
+The issue is that there are hundreds to thousands of potential dependent factors.
+A nonstarter for uncreative minds,
+but a worthwhile challenge for estimators truly passionate about their field.
+
+It is unique of construction estimating among similar fields
+that analysis and discussion of risk is largely absent from pre-approval review.
+The tools common of our trade almost always lack the means
+to quantify the dollar amount implications of our assumptions.
+
+There is an enormous gap in complexity between pure square foot pricing and
+[[traditional-estimating-methods]] that tools do not exist to bridge.
+
+> [!aside]
+> The refusal to acknowledge the potential for more "complex" estimate models
+> hints at issues of organizational ignorance described ~~elsewhere in this vault~~.
+
+At all points in the estimating process,
+It should be possible to give a confident budget.
+
+## In Comparison
+
+For most contractors, there is not usually a minimum amount of project detail
+required to provide a budget for a project
+Estimators know what the most likely and most expensive options are for a given scope
+and can fill in the detail required for item-oriented takeoff.
+This is called an **assumption** and is the basis of cost estimation.
+
+Assumptions are fundamentally incompatible with item-oriented estimating as it is commonly implemented.
+It is not possible to compare price possibilities
+except by creating separate takeoffs and breakdowns for each one.
+
+Rather than building the job one `WOOD NAIL - GALV STEEL - #10 - 5-INCH` at a time,
+risk-oriented estimating focuses on reducing risk of a decent budget.
+
+Risk-oriented estimating understands a `NAIL` like an estimator:
+an abstract item in a certain price range requiring labor in a certain hour range.
+
+A practitioner of this style would find
+that the impact of such details on the final price of a job
+are so low as to be trivial.
+Not to say that they shouldn't be addressed,
+only that they ought not be addressed before more significant factors.
+
+Risk is a measure of the effect of uncertainty on outcome.
+Uncertainty being a necessity of estimating,
+the language and tools that we use
+must facilitate discussions of risk management.
+In estimation in fields other than construction
+it is common to give an estimate as a *confidence interval*,
+a range in which a result has a certain percentage chance to fall.
+This interval can be determined from a population of possible prices.
+
+The *accuracy* of a risk-oriented estimate remains roughly the same
+(approaching 100% with continuous input)
+through the takeoff process and, assuming no incorrect input,
+is entirely out of the hands of the estimator doing the "takeoff".
+The previous chapters describe how a centralized system
+separates the concerns of adjustment factors
+and data input for individual projects.
+
+The "takeoff" workflow then is not about progressively approaching the target
+price as with item-oriented methods,
+but reducing the range of possible target prices,
+reducing the risk of the estimate.
+
+Abandoning an item-oriented estimate
+at any point before 100% completion
+results in effectively 100% wasted effort.
+In contrast, an abandoned risk-oriented estimate
+becomes a budget with no additional effort.
diff --git a/traditional-estimating-methods.md b/traditional-estimating-methods.md
index b5bb729..ea9b56d 100644
--- a/traditional-estimating-methods.md
+++ b/traditional-estimating-methods.md
@@ -17,3 +17,39 @@ are those [[construction-estimating]] methods that produce:
 * a single, definitive final price for each bid item
 
 Such methods lack the ability to intelligently express [[uncertainty]].
+
+### Limitations of Traditional Estimating Methods
+
+Traditional estimating methods, sometimes referred to as "Detailed Takeoff",
+seek to detail all constituent subcosts,
+including 100% itemized pricing by way of a *material extension*,
+a complete list of all material included in the price.
+
+For clarity and contrast to [[risk-oriented-estimating]],
+which does not require itemized pricing,
+I'll refer to these methods as "item-oriented estimating".
+
+By popular belief, item-oriented estimating is the only "correct" way to estimate,
+however few to no estimators create 100% "Detailed" estimates
+as the effort would require a significant increase in estimating time
+for little reward in overall **precision**.
+
+> [!info] Pareto Principle
+> The Pareto principle states that for many outcomes,
+> roughly 80% of consequences come from 20% of causes.
+> 
+> In the case of estimating efficiency, this means that optimal strategy
+> is to focus on the 20% of estimating effort
+> representing 80% of the overall efforts contribution to the total.
+
+It is popular to dismiss alternate estimate models as potentially inaccurate,
+but this dismissal fails to acknowledge
+the potential for _much greater_ inaccuracy in item-oriented methods.
+While an estimate based on item extension is 100% **precise**,
+in that it computes to single final number,
+the method has no such inherent guarantee of **accuracy**.
+It relies on the estimator to miss absolutely nothing,
+and to adjust for all labor conditions and market factors _exactly_.
+
+Most estimators wouldn't rate their margin of error at less than 10%,
+though most would refuse to answer anyway (see [[estimating-culture]]).