vault backup: 2025-12-17 17:03:56

.obsidian/community-plugins.json

@@ -16,5 +16,6 @@
   "lilypond",
   "novel-word-count",
   "easy-copy",
-  "anchor-display-text"
+  "anchor-display-text",
+  "calendar"
 ]

.obsidian/plugins/calendar/data.json

@@ -0,0 +1,10 @@
+{
+  "shouldConfirmBeforeCreate": true,
+  "weekStart": "locale",
+  "wordsPerDot": 250,
+  "showWeeklyNote": true,
+  "weeklyNoteFormat": "",
+  "weeklyNoteTemplate": "",
+  "weeklyNoteFolder": "",
+  "localeOverride": "system-default"
+}

.obsidian/plugins/calendar/manifest.json

@@ -0,0 +1,10 @@
+{
+  "id": "calendar",
+  "name": "Calendar",
+  "description": "Calendar view of your daily notes",
+  "version": "1.5.10",
+  "author": "Liam Cain",
+  "authorUrl": "https://github.com/liamcain/",
+  "isDesktopOnly": false,
+  "minAppVersion": "0.9.11"
+}

2025-12-02.md

@@ -31,16 +31,16 @@ Let $A$ and $B$ be sets
 sharing some but not all elements.
 
 * $A \cap B \neq \varnothing$:
-    The intersection of $A$ and $B$ is nonempty
+    "The intersection of $A$ and $B$ is nonempty"
     (They share at least one element).
 
 * $A \not\subseteq B$:
-    $A$ is not a subset of $B$
+    "$A$ is not a subset of $B$"
     ($A$ has at least one element not in $B$).
     Equivalent to $A \setminus B \neq \varnothing$.
 
 * $B \not\subseteq A$:
-    $B$ is not a subset of $A$
+    "$B$ is not a subset of $A$"
     ($B$ has at least one element not in $A$).
     Equivalent to $B \setminus A \neq \varnothing$.
 

2025-12-08.md

@@ -12,12 +12,4 @@ title: 2025-12-08
 
 ## 2025-12-08 11:03
 
-#topic/ambiguity
+[[ambiguity-in-construction-estimating]]
-
-I hate to come off as pedantic,
-but I care a lot about standardized terminology
-because spending a few minutes to be more thoughtful in specification
-can save hundreds of people cumulative hours of confusion.
-And the problem with standardization, of course,
-is that sometimes it works,
-and undoing years of poor conditioning is... not easy.

2025-12-09.md

@@ -12,33 +12,7 @@ tags:
 
 ## 2025-12-09 10:43
 
-### Overgeneralization via Hyperspecification
+[[ambiguity]]
-
-#topic/ambiguity
-
-Or "inappropriate synecdoche[^1]"
-
-[^1]: **synecdoche:** Using the name of a part to refer to the whole, or vice versa.
-
-Much of my issue with terminology
-can be blamed on **overgeneralization via hyperspecification**,
-
-[Proprietary eponyms](https://en.wiktionary.org/wiki/proprietary_eponym)
-(synonym: [genericized trademark](https://en.wiktionary.org/wiki/genericized_trademark))
-are usually[^2] an example of such,
-and are prominent in electrical construction.[^3]
-
-[^2]: I'm not a complete pedant, Cadweld is a perfectly unambiguous substitution.
-    "Caddy", "Hilti", and "Vitalink" are my real complaints,
-    where the word only gets me marginally closer
-    to creating a concrete image in my head.
-
-    The general acceptance of "band-aid"
-    compared to the rejection of "coke"
-    may be related.
-
-[^3]: See [Database of American Proprietary Eponyms](https://www.searstower.org/rkrause/brands.html)
-    for examples.
 
 ## 2025-12-09 10:52
 

2025-12-17.md

@@ -41,45 +41,51 @@ to the conceivably far more broad [spatial statistics](https://en.wikipedia.org/
 > such as in computer-aided design (CAD),
 > see [geometric modeling](https://en.wikipedia.org/wiki/Geometric_modeling "Geometric modeling").
 
-### Common Fallacies
+### Ambiguity
 
-* [Reification](https://en.wikipedia.org/wiki/Reification_(fallacy))
+New Note: [[ambiguity]]
 
-    > [!quote]
+## 2025-12-17 12:32
-    > **Reification** ... is a fallacy of ambiguity,
-    > ...it is the error of treating something that is not concrete...
-    > as a concrete thing.
 
-    See ["the map is not the territory"](https://en.wikipedia.org/wiki/Map-territory_relation "Map-territory relation").
+#topic/ambiguity
 
-    > [!aside]
+A while ago I heard a minor coding influencer lament
-    > This one is very common among my peers in estimating.
+that frameworks, packages, and tools
-    > The problem with fallacies, of course,
+often have ridiculous sounding names
-    > is that you can't simply say "Reification fallacy, booyah".
-    > If some one is overgeneralizing,
-    > they likely just have a different understanding of the term.
-    > Certainty of definition only occurs with some quorum,
-    > and I'd argue most of [[construction-estimating|ours]] don't meet it,
-    > and that the choice of any term over another ought to be based on utility.
-    >
-    > > Note also that a term's definition can be certain ~~on some axis~~,
-    > > but ambiguous ~~on another~~.
-    > > See ["I know it when I see it"](https://en.wikipedia.org/wiki/I_know_it_when_I_see_it)
-    > > which, as far as I'm concerned, is a perfectly legitimate definition.
 
-* [Equivocation](https://en.wikipedia.org/wiki/Equivocation "Equivocation")
+> `bubble-tea` and `ratatui`,
+> libraries for creating CLI's, come to my mind
 
-    The misleading use of a word with more than one meaning
+when, he suggests, they ought to just be called what they do.
 
-* [Composition](https://en.wikipedia.org/wiki/Fallacy_of_composition "Fallacy of composition")
+Unfortunately some people and organizations agree,
+giving us terms which mean both something very general
+and something very specific.
 
-    Assuming a whole has a property because its parts have that property
+> [[project-management-tm|"Project Management"]]
+> was my go to example, but weak
+> because it's difficult for me to articulate
+> the difference from construction project management
+> especially to someone un familiar with the specifics of either.
 
-* [Division](https://en.wikipedia.org/wiki/Fallacy_of_division "Fallacy of division")
+For lack of a better term I've been thinking of this as an SEO problem,
+but the bigger problem is that it invites [[ambiguity#Category Mistake|Category Mistake]],
+whereby the ignorant listener associates traits unique to the example
+to all things that the name could describe.
 
-    Assuming parts have a property because the whole has that property
+I thought to finally write about this problem
+while researching [[lighting-controls#Protocols|lighting control protocols]].
+The two most dominant examples:
 
-> [!quote] [Category mistake](https://en.wikipedia.org/wiki/Category_mistake)
+* [[lighting-controls#^dali|"Digital Addressable Lighting Interface (DALI)"]]
-> An example is a person learning that the game of cricket involves team spirit,
+* [[lighting-controls#^dmx|"Digital Multiplex (DMX)"]]
-> and after being given a demonstration of each player's role,
+
-> asking which player performs the "team spirit".
+while notably different in topology,
+are could both be described accurately with the other's name.
+
+> It is possible to avoid this problem
+> without the effort necessary to come up with a clever name.
+> Just stick an arbitrary, but reasonably unique word
+> in front of the generic description.
+> A person's name ("John's Digital Addressable Lighting Interface (JDALI)")
+> or your favorite animal ("Heron Digital Multiplex (HDMX)") are good options.

actuarial-science-for-construction-estimating.md

@@ -8,17 +8,17 @@ tags:
   - status/incomplete
   - topic/estimating
   - topic/risk
-  - type/idea
+  - type/cross-topic
 ---
 # Actuarial Science for Construction Estimating
 
+Cross-topic of [[actuarial-science]] and [[construction-estimating]].
+
 For a contractor, construction projects are like _investments_
 in that they have a cost and return.
 However, for construction projects,
 **return** is known but **cost** must be estimated.
 In this way, projects are better compared to _insurance accounts_.
 
-- cost of individual service is uncertain
+* cost of individual service is uncertain
-- cost to customer must be minimized
+* cost to customer must be minimized
-
-[[actuarial-science]]

actuarial-science.md

@@ -5,6 +5,7 @@ title: Actuarial Science
 tags:
   - authorship/original
   - destiny/permanent
+  - status/incomplete
   - topic/risk
   - type/encyclopedia
 ---

ambiguity-in-construction-estimating.md

@@ -0,0 +1,37 @@
+---
+id:
+aliases: []
+title: Ambiguity in Construction Estimating
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/incomplete
+  - topic/ambiguity
+  - topic/construction
+  - topic/estimating
+  - type/cross-topic
+---
+# Ambiguity in Construction Estimating
+
+Cross-topic of [[ambiguity]] and [[construction-estimating]].
+
+I hate to come off as pedantic,
+but I care a lot about standardized terminology
+because spending a few minutes to be more thoughtful in specification
+can save hundreds of people cumulative hours of confusion.
+And the problem with standardization, of course,
+is that sometimes it works,
+and undoing years of poor conditioning is... not easy.
+
+## Naming Conventions (Use Case vs. Description)
+
+Related: [[realism-vs-instrumentalism]]
+
+Naming by use case is intuitive for those without estimating or field experience,
+but has the side effect that those accustomed to the names
+will inevitably _treat them as descriptive_.
+
+| Use Case            | Description   |
+| ------------------- | ------------- |
+| Hi-Hat              | Daisy-Chain   |
+| Furnished By Others | Rough-In Only |

ambiguity.md

@@ -0,0 +1,91 @@
+---
+id:
+aliases: []
+title: Ambiguity
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/incomplete
+  - topic/ambiguity
+  - type/encyclopedia-entry
+---
+# Ambiguity
+
+Not to be confused with [[uncertainty]].
+
+## Common Fallacies
+
+### Reification Fallacy
+
+> [!quote] [Reification](https://en.wikipedia.org/wiki/Reification_(fallacy))
+> **Reification** ... is a fallacy of ambiguity,
+> ...it is the error of treating something that is not concrete...
+> as a concrete thing.
+
+See ["the map is not the territory"](https://en.wikipedia.org/wiki/Map-territory_relation "Map-territory relation").
+
+> [!aside]
+> This one is very common among my peers in estimating.
+> The problem with fallacies, of course,
+> is that you can't simply say "Reification fallacy, booyah".
+> If some one is overgeneralizing,
+> they likely just have a different understanding of the term.
+> Certainty of definition only occurs with some quorum,
+> and I'd argue most of [[construction-estimating|ours]] don't meet it,
+> and that the choice of any term over another ought to be based on utility.
+>
+> > Note also that a term's definition can be certain ~~on some axis~~,
+> > but ambiguous ~~on another~~.
+> > See ["I know it when I see it"](https://en.wikipedia.org/wiki/I_know_it_when_I_see_it)
+> > which, as far as I'm concerned, is a perfectly legitimate definition.
+
+### Equivocation Fallacy
+
+[Equivocation](https://en.wikipedia.org/wiki/Equivocation "Equivocation")
+
+The misleading use of a word with more than one meaning
+
+### Composition Fallacy
+
+[Composition](https://en.wikipedia.org/wiki/Fallacy_of_composition "Fallacy of composition")
+
+Assuming a whole has a property because its parts have that property
+
+### Division Fallacy
+
+[Division](https://en.wikipedia.org/wiki/Fallacy_of_division "Fallacy of division")
+
+Assuming parts have a property because the whole has that property
+
+### Category Mistake
+
+> [!quote] [Category mistake](https://en.wikipedia.org/wiki/Category_mistake)
+> An example is a person learning that the game of cricket involves team spirit,
+> and after being given a demonstration of each player's role,
+> asking which player performs the "team spirit".
+
+#### Overgeneralization via Hyperspecification
+
+Or "inappropriate synecdoche[^1]"
+
+[^1]: **synecdoche:** Using the name of a part to refer to the whole, or vice versa.
+
+Much of my issue with terminology
+can be blamed on **overgeneralization via hyperspecification**,
+
+[Proprietary eponyms](https://en.wiktionary.org/wiki/proprietary_eponym)
+(synonym: [genericized trademark](https://en.wiktionary.org/wiki/genericized_trademark))
+are usually[^2] an example of such,
+and are prominent in electrical construction.[^3]
+
+[^2]: I'm not a complete pedant, Cadweld is a perfectly unambiguous substitution.
+    "Caddy", "Hilti", and "Vitalink" are my real complaints,
+    where the word only gets me marginally closer
+    to creating a concrete image in my head.
+
+    The general acceptance of "band-aid"
+    compared to the rejection of "coke"
+    may be related.
+
+[^3]: See [Database of American Proprietary Eponyms](https://www.searstower.org/rkrause/brands.html)
+    for examples.

assembly-objects.md

@@ -3,7 +3,7 @@ id:
 aliases: []
 tags:
   - authorship/original
-  - destiny/fleeting
+  - destiny/permanent
   - status/incomplete
   - topic/automation
   - topic/estimating

auction-theory.md

@@ -5,7 +5,9 @@ title: Auction Theory
 tags:
   - authorship/original
   - destiny/permanent
+  - status/incomplete
   - topic/strategy
+  - type/encyclopedia-entry
 ---
 # Auction Theory
 

bid-process-strategy.md

@@ -4,7 +4,7 @@ aliases: []
 title: Bid Process Strategy
 tags:
   - authorship/original
-  - destiny/permanent
+  - destiny/fleeting
   - status/incomplete
   - topic/estimating
   - topic/risk

breakdown-objects.md

@@ -4,7 +4,7 @@ aliases: []
 title: Breakdown Objects
 tags:
   - authorship/original
-  - destiny/fleeting
+  - destiny/permanent
   - status/incomplete
   - topic/automation
   - topic/estimating

capek_1935_pov-of-a-cat.md

@@ -6,6 +6,7 @@ tags:
   - authorship/other
   - destiny/permanent
   - exclude-from-word-count
+  - status/complete
   - topic/hobbies/poetry
   - type/media/poetry
 author: Karel Čapek

consolidate-estimating-thoughts.md

@@ -1,42 +1,71 @@
 ---
 id:
 aliases: []
+title: Consolidate Estimating Thoughts
 tags:
+  - authorship/original
   - destiny/fleeting
   - status/incomplete
   - topic/estimating
   - topic/meta
   - type/task
-  - authorship/original
-title: Consolidate Estimating Thoughts
 ---
 # Consolidate Estimating Thoughts
 
-My notes on construction estimating
+My notes on [[construction-estimating]]
-are currently disparate, disjointed, and redundant
+are currently disparate, disjointed, and redundant.
+
+## TODO
+
+### Legitimate Subtopics
+
+* [[estimating-methodologies]]
+* [[construction-estimating-software]]
+* [[history-of-construction-estimating]]
+* [[labor-factoring]]
+
+### New Cross-Topics
 
 Remove estimating-specific content from irrelevant notes.
 
 Create and use cross-topic notes for complex thoughts:
+
 * [[actuarial-science-for-construction-estimating]]
+    * [[risk-oriented-estimating]]
+
 * [[risk-management-for-construction-estimating]]
+    * [[risk-oriented-estimating]]: resource allocation
+
 * [[auction-theory-for-construction-estimating]]
+    * [[bid-process-strategy]]
+
+* [[game-theory-for-construction-estimating]]
+    * [[estimating-culture]]: estimator incentives
+
+* [[project-management-for-construction-estimating]]
+    * [[separating-estimating-concerns]]
+
+* [[ambiguity-in-construction-estimating]]
+
+* [[nontraditional-computing-for-construction-estimating]]
+    * [[optimal-estimating-patterns]]
+
+* [[object-oriented-programing-for-construction-estimating]]
+    * [[assembly-philosophy]] - pare down
+    * [[software-based-estimating]]
+    * [[optimal-estimating-patterns]]
+
+* [[statistical-modeling-for-construction-estimating]]
+
+* [[transparency-in-construction-estimating]]
+    * [[estimating-ethics]]
+
+### Orphaned Notes
+
+* [[estimating-philosophy]]
+* [[purpose-of-construction-estimating]]
+* [[traditional-estimating-methods]]
 
 ## Relevant Notes
 
-![[estimating-thoughts.base]]
+![[estimating-thoughts.base#fleeting]]
-
-## Orphaned Topics
-
-### Naming Conventions (Use Case vs. Description)
-
-Related: [[realism-vs-instrumentalism]]
-
-Naming by use case is intuitive for those without estimating or field experience,
-but has the side effect that those accustomed to the names
-will inevitably _treat them as descriptive_.
-
-| Use Case            | Description   |
-| ------------------- | ------------- |
-| Hi-Hat              | Daisy-Chain   |
-| Furnished By Others | Rough-In Only |

construction-estimating-software.md

@@ -2,16 +2,28 @@
 id:
 aliases: []
 tags:
-  - destiny/uncertain
+  - destiny/permanent
   - status/incomplete
   - topic/estimating
   - topic/software
-  - type/philosophy
+  - type/encyclopedia-entry
   - authorship/original
 title: Construction Estimating Software
 ---
 # Construction Estimating Software
 
+%%
+## TALK
+
+This note is for describing _existing_, _conventional_
+construction estimating software and patterns.
+
+## TODO
+
+Remove philosophy.
+
+%%
+
 ## Why Not Excel?
 
 ### "Spreadsheet Syndrome"

construction-estimating.md

@@ -24,6 +24,26 @@ For philosophy see [[bid-process-strategy]]
 
 [[estimating-ethics]]
 
+## Topics
+
+### Subtopics
+
+* [[history-of-construction-estimating]]
+* [[estimating-methodologies]]
+* [[construction-estimating-software]]
+* [[labor-factoring]]
+
+### Cross-Topics
+
+* [[actuarial-science-for-construction-estimating]]
+* [[risk-management-for-construction-estimating]]
+* [[auction-theory-for-construction-estimating]]
+* [[game-theory-for-construction-estimating]]
+* [[project-management-for-construction-estimating]]
+* [[ambiguity-in-construction-estimating]]
+* [[nontraditional-computing-for-construction-estimating]]
+* [[object-oriented-programing-for-construction-estimating]]
+
 ## Misconceptions
 
 ### Standard Practices

electrical-takeoff.md

@@ -26,10 +26,6 @@ use ENT and PVC as permitted.
 
 In precast slab garages, use EMT.
 
-## Lighting Control
-
-See [[lighting-controls-takeoff]].
-
 ## Receptacles
 
 ## Floor Boxes

estimating-culture.md

@@ -2,7 +2,7 @@
 id:
 aliases: []
 tags:
-  - destiny/uncertain
+  - destiny/fleeting
   - status/draft
   - topic/estimating
   - topic/organization
@@ -54,7 +54,7 @@ Such incentives therefore create a [[game-theory|competitive game]]
 between the estimator and the employer
 where the employer is hopelessly outmatched,
 and the estimator's [[strategy#Strictly Dominant Strategy|strictly dominant strategy]]---
-resisted only by their moral conviction---
+resisted only by their [[personal-values]]---
 is to abuse the system: to bid fast, lie often, take the bag, and leave.
 
 ## Collaboration

estimating-detail.md

@@ -1,62 +0,0 @@
----
-id:
-aliases: []
-tags:
-  - destiny/uncertain
-  - status/incomplete
-  - topic/estimating
-  - type/philosophy
-  - authorship/original
-title: Estimating Detail
----
-# Estimating Detail
-
-The acceptable level of detail of an estimate
-in [[construction-estimating]] is a contentious subject.
-What's worse, estimators often disagree
-on what makes an estimate more detailed than another.
-
-The commonly repeated answer is this:
-
-> As detailed as possible,
-> given required turnaround and available estimating resources.
-
-This analysis is flawed
-because it implies more time always ought to be preferred,
-when the reality is that when considering larger organizational factors,
-ideal estimate certainty is likely far lower than most expect.
-
-The correct answer involves optimizing for these factors:
-* value of increased bid certainty
-* value of increased estimate volume
-
-An estimate's detail is irrelevant to its quality.
-A less detailed estimate is a more [[risk|risky]] bid,
-but it is not the role of the estimator to determine acceptable risk.
-
-## Experiment
-
-Perform a system takeoff (lighting for example) in exacting detail,
-the maximum amount you would ever consider using,
-and measure the time required to do so,
-as well as the cost of the scope.
-
-Have another estimator takeoff the same scope
-using the proposed time saving strategy.
-
-Repeat the test on additional projects.
-
-Treat the detailed takeoff as the true value
-and find the error of the time saving strategy.
-
-$\frac{d\sigma}{dt}$
-
-### Expectation
-
-Time-saving strategies will overestimate or underestimate detailed takeoff
-depending on the assumptions used in their creation.
-
-## Human Error
-
-It is commonly understood that a "detailed takeoff"
-is more "accurate" than a square foot estimate.

estimating-thoughts.base

@@ -1,3 +1,6 @@
+filters:
+  and:
+    - file.hasTag("topic/estimating")
 formulas:
   destiny: file.tags.filter(value.contains("destiny"))
   status: file.tags.filter(value.contains("status"))
@@ -5,21 +8,22 @@ formulas:
   linkText: (["[[",file.name,"]]"]).join("")
 views:
   - type: table
-    name: Table
+    name: fleeting
     filters:
       and:
-        - file.hasTag("topic/estimating")
+        - file.hasTag("authorship/original")
         - '!file.hasTag("type/media-commentary")'
-        - '!file.hasTag("type/anecdote")'
+        - file.hasTag("destiny/fleeting")
     order:
       - file.name
       - title
       - file.size
-      - formula.destiny
       - formula.status
       - formula.type
       - formula.linkText
     sort:
+      - property: formula.destiny
+        direction: DESC
       - property: formula.status
         direction: ASC
       - property: formula.type
@@ -28,5 +32,5 @@ views:
         direction: DESC
     columnSize:
       note.title: 290
-  - type: table
+  - type: list
-    name: View
+    name: all

full-takeoff.md

@@ -39,12 +39,13 @@ tags:
 
 4. [[units-takeoff]]
 5. [[fixtures-takeoff]]
-6. [[electrical-takeoff]]
+6. [[lighting-controls-takeoff]]
-7. [[telecom-takeoff]]
+7. [[electrical-takeoff]]
-8. [[low-voltage-takeoff]]
+8. [[telecom-takeoff]]
-9. [[fire-alarm-takeoff]]
+9. [[low-voltage-takeoff]]
-10. [[standalone-systems-takeoff]]
+10. [[fire-alarm-takeoff]]
-11. [[misc-budgets-takeoff]]
+11. [[standalone-systems-takeoff]]
+12. [[misc-budgets-takeoff]]
 
 [[general-takeoff]]
 

gold-plating.md

@@ -1,15 +1,15 @@
 ---
 id:
 aliases: []
+title: Gold Plating
 tags:
   - authorship/original
-  - destiny/fleeting
+  - destiny/permanent
   - status/complete
   - topic/construction
   - topic/construction/electrical
   - topic/risk
-  - type/encyclopedia
+  - type/encyclopedia-entry
-title: Gold Plating
 ---
 # Gold Plating
 

grounding-takeoff.md

@@ -1,13 +1,13 @@
 ---
 id: grounding
 aliases: []
+title: Grounding Takeoff
 tags:
   - authorship/original
   - destiny/permanent
   - occupational/takeoff/feeders
   - status/draft
   - type/guide
-title: Grounding Takeoff
 ---
 # Grounding Takeoff
 
@@ -19,28 +19,26 @@ not especially consistent with the actual install.
 
 ### System Grounding
 
-> `Area` = "01 - Feeders/Risers Building"
+* `Area` = "01 - Feeders/Risers Building"
 
-`COMMON ASSEMBLIES`/`GROUNDING`/`GND = #3/0 & 1" CONDUIT - EMT`
+1. `COMMON ASSEMBLIES`/`GROUNDING`/`GND = #3/0 & 1" CONDUIT - EMT`
+    * **Length:** Perimeter of the main electrical rooms plus length to each riser.
+    * **Count:** Total number of electrical rooms
 
-* Length: Perimeter of the main electrical rooms plus length to each riser.
+2. `COMMON ASSEMBLIES`/`GROUNDING`/`(3) ... x 10' CU CLAD GRD ROD & 4"X12" GND BAR`
-* Count: Total number of electrical rooms
+    * **Count:** 1
-
-`COMMON ASSEMBLIES`/`GROUNDING`/`(3) ... x 10' CU CLAD GRD ROD & 4"X12" GND BAR`
-
-* Count: 1
 
 ### Riser
 
-> `Area` = "Typical - Building All Electrical Riser Rooms"
+1. * `Area` = "Typical - Building All Electrical Riser Rooms"
 
-`COMMON ASSEMBLIES`/`GROUNDING`/`GND = #3/0 & 1" CONDUIT - EMT`
+    `COMMON ASSEMBLIES`/`GROUNDING`/`GND = #3/0 & 1" CONDUIT - EMT`
-
+    * **Length:** 15
-* Length: 15
+    * **Count:** 1
-* Count: 1
 
 ### Telecom Ground Bridge
 
-Use only where shown.
+1. * `Area` = "01 - Feeders/Risers Building"
 
-`COMMON ASSEMBLIES`/`GROUNDING`/`TELE/DATA GND BRIDGE, ..., W/ COVER & (60') #6 THHN GREEN`
+    `COMMON ASSEMBLIES`/`GROUNDING`/`TELE/DATA GND BRIDGE, ..., W/ COVER & (60') #6 THHN GREEN`
+    * **Count:** Only as shown

history-of-construction-estimating.md

@@ -0,0 +1,13 @@
+---
+id:
+aliases: []
+title: History of Construction Estimating
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/not-started
+  - topic/construction
+  - topic/estimating
+  - type/encyclopedia-entry
+---
+# History of Construction Estimating

individual-ability.md

@@ -6,6 +6,7 @@ tags:
   - authorship/original
   - destiny/permanent
   - status/incomplete
+  - topic/individualism
   - topic/organization
   - type/philosophy
 ---
@@ -47,4 +48,4 @@ familiarity requires maintenance.
 Expertise as heuristics and biases
 [Daniel Kahneman](https://en.wikipedia.org/wiki/Daniel_Kahneman)
 
-%%
+%%

labor-factoring.md

@@ -2,16 +2,55 @@
 id:
 aliases: []
 tags:
-  - destiny/fleeting
+  - destiny/permanent
   - status/incomplete
   - topic/automation
   - topic/estimating
   - topic/software
   - type/idea
   - authorship/original
-title: Functional Labor Factoring
+title: Labor Factoring
 ---
-# Functional Labor Factoring
+# Labor Factoring
+
+%%
+## TODO
+
+Discuss purpose and practice of labor factoring,
+briefly mention impracticality.
+
+%%
+
+## Resources
+
+```bibtex
+@article{Hanna2018FactorsAL,
+  author  = {Hanna, Awad S.},
+  title   = {Factors Affecting Labor Productivity For Electrical Contractors},
+  subtitle = {A Factor Approach To Productivity Impact},
+  publisher = {Electrii International},
+  month  = {September},
+  year    = {2018},
+  pages   = {83}
+}
+
+@article{Hanna2002BenchmarkingPI,
+	author = {Hanna, Awad S. and Peterson, Pehr and Lee, Min-Jae},
+	journal = {Journal of Construction Engineering and Management},
+	month = {7},
+	number = {4},
+	pages = {331--337},
+	title = {Benchmarking productivity Indicators for Electrical/Mechanical Projects},
+	volume = {128},
+	year = {2002},
+	doi = {10.1061/(asce)0733-9364(2002)128:4(331},
+	url = {https://doi.org/10.1061/(asce)0733-9364(2002)128:4(331)},
+}
+```
+
+## Software Integration
+
+%% TODO: move to more appropriate article. %%
 
 calculate labor hours utilizing a comprehensive set of factors
 not practical with traditional methods.
@@ -45,29 +84,3 @@ most sensitive to weight.
 Greater understanding of this relationship would make practical
 the prediction of labor of unstudied items.
 
-## Resources
-
-```bibtex
-@article{Hanna2018FactorsAL,
-  author  = {Hanna, Awad S.},
-  title   = {Factors Affecting Labor Productivity For Electrical Contractors},
-  subtitle = {A Factor Approach To Productivity Impact},
-  publisher = {Electrii International},
-  month  = {September},
-  year    = {2018},
-  pages   = {83}
-}
-
-@article{Hanna2002BenchmarkingPI,
-	author = {Hanna, Awad S. and Peterson, Pehr and Lee, Min-Jae},
-	journal = {Journal of Construction Engineering and Management},
-	month = {7},
-	number = {4},
-	pages = {331--337},
-	title = {Benchmarking productivity Indicators for Electrical/Mechanical Projects},
-	volume = {128},
-	year = {2002},
-	doi = {10.1061/(asce)0733-9364(2002)128:4(331},
-	url = {https://doi.org/10.1061/(asce)0733-9364(2002)128:4(331)},
-}
-```

lighting-controls-takeoff.md

@@ -24,111 +24,91 @@ title: Lighting Controls Takeoff
 Determine which Systems and Codes are required:
 * _IBC/IECC 2021 or later:_ all fixtures 0-10V dimmable.
 
-## PDI Lighting Control Configurations
+* `System` = "LV - Lighting Control System"
 
-> [!important]
+## Wall Switches
-> This section is currently not practical
 
-### Stand Alone
+> [!tip]
+> For switch combinations not in `COMMON ASSEMBLIES`,
+> create [[heating-designations]] based on the most similar.
 
-0-10V dim --- "LV cable" is 2 conductor
+## Analog Controls
 
-Takeoff rough-in for switches and occupancy sensors
+24V sensors. Typical of BOH spaces too large for wall sensors.
-* **Branch Length** = length of room
 
-Takeoff the lighting control relay (DLM)
+1. `COMMON ASSEMBLIES`/`SWITCHES`/`CEILING OCC SENSOR ...`
+    **Count:** as shown.
 
-Takeoff an additional controller if receptacles are controlled
+2. `COMMON ASSEMBLIES`/`SWITCHES`/`POWER PACK FOR OCC SENSOR ...`
+    **Count:** each circuit controlled by analog sensors. Minimum 1 per sensor.
 
-Takeoff homeruns to the DLM (one per controlled circuit)
+## Digital Controls
-* Note: Not necessarily per room, several rooms may share a lighting circuit.
 
-### Networked
+Applicable to all digital control systems
+(i.e. "Standalone" and "Centralized", wired and wireless)
 
-"LV Cable" is [[twisted-pair-cable]]
+### General
-
-#### Room Controllers
-
-No room controllers are necessary,
-lighting zones are switched from a central lighting control panel (LCP)
-
-#### Switches and Sensors
-
-Takeoff rough-in for switches and occupancy sensors
-
-??
-(only if time based; length based on proximity to switch or occupancy sensor)
-??
-
-#### Homeruns
-
-Takeoff 1 circuit homerun per lighting zone.
-
-### Wattstopper
-
-PDI default configuration
-
-#### Room Controllers
-
-For all rooms with dimmable fixtures
-and/or automatically controlled receptacles,
-take off (1) of either or both as appropriate.
-
-`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/`DLM LTG RM CONTROLLER - ...`
-
-`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/`REC PLUG CONTROLLER - ...`
 
 Takeoff normal power to the controlled load
 * Add LV cable to fixture branch
-* Use \#12/3 for controlled receptacles
+* Use switched assemblies (\#12/3) for controlled receptacles
 
-Takeoff rough-in for both the occ sensors and the LV switch
+#### Digital Sensors
 
-`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/`... LV SW - WALL ROUGH IN ...`
+1. `COMMON ASSEMBLIES`/`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/...
+    * `... LV SW - WALL ROUGH IN ...`
+    * `... SENSOR LOW VOLTAGE - ROUGH IN ...`
 
-`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/`... SENSOR LOW VOLTAGE - ROUGH IN ...`
+### "Standalone" Systems
 
-* Free air if possible
+Room controllers distributed throughout controlled areas.
-* **Length** = length of room
 
-Cat cabling from the controllers on is likely provided by systems
+> [!important] "Room controllers"
-* Confirm with chief or quote language
+> As I have always understood it, and other manufacturers tend to agree,
+> a room controller _necessarily_ controls multiple zones
+> (otherwise "zone controller" would be better),
+> however PDI terminology is based on Wattstopper's.
 
-#### Corridor Occupancy Sensors
+`COMMON ASSEMBLIES`/`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/...
 
-If occupancy sensors are shown in the corridors:
+1. .../`DLM LTG RM CONTROLLER - ...`
+    **Count:** each lighting control zone.
 
-Takeoff homerun back to the electric room
+2. .../`REC PLUG CONTROLLER - ...`
+    **Count:** each receptacle control zone.
 
-Takeoff (1) DLM controller for each electric room
+3. `HEATING`/`Network Bridge - Blank 4SQ`
+    **Count:** each controller.
 
-`SWITCHES`/`LOW VOLTAGE SWITCHES & OCC SENSORS - ROUGH IN`/`DLM LTG RM CONTROLLER - ...`
+    Coordinate with PDS to determine if necessary.
 
-??
+4. `COMMON ASSEMBLIES`/`PDI BRANCH CKT HOME RUNS`/... (_without_ dimming cable)
-Run free-air down corridor
+    **Count:** each _circuit_.
-??
 
-* **Length** = Length of corridor
+### "Centralized" Systems
 
-Takeoff rough-in for each occupancy sensor shown.
+Zones switched and dimmed from central lighting control panel (LCP).
 
-#### Network Bridge
+1. `COMMON ASSEMBLIES`/`DISTRIBUTION`/`LIGHTING CONTROL PANEL INSTALLATION`/...
 
-Check systems quote to determine if network bridges are needed.
+2. `COMMON ASSEMBLIES`/`PDI BRANCH CKT HOME RUNS`/... (_with_ dimming cable)
+    **Count:** each _lighting control zone_.
 
-Takeoff (1) back box for every ==group of rooms you want together==
+%%
 
-??
+### Somewhere In Between
-If not showing, put one in every room with a controller
-??
 
-#### Homeruns
+The dichotomy of [[#"Standalone" Systems]] vs. [[#"Centralized" Systems]]
+assumes zones will be controlled either
+(1) right next to the fixture or (2) in the nearest electrical room.
 
-Need a HR into the room for the controllers
+I think just as common is 3--5 circuit controllers above the ceiling.
-* Can link multiple controllers (aka rooms) together if you have the same circuit
-* Go back to closest electric room
 
-## Custom Switch Boxes
+1. `HEATING`/`Lighting Control Room Controller - n Circuit`
+    **Count:** each controller.
 
-For switch combinations not in `COMMON ASSEMBLIES`,
+2. `COMMON ASSEMBLIES`/`PDI BRANCH CKT HOME RUNS`/... (_without_ dimming cable)
-create [[heating-designations]] based on the most similar.
+    **Length:** route to room.
+    **Count:** each circuit.
+
+%%

lighting-controls.md

@@ -11,6 +11,9 @@ title: Lighting Controls
 ---
 # Lighting Controls
 
+## Protocols
+
+
 ## Occupancy/Vacancy Sensor Technologies
 
 * Passive Infrared (PIR)
@@ -33,7 +36,53 @@ title: Lighting Controls
 
 ### Digital
 
-Digital Light Management (DLM)
+#### Digital Addressable Lighting Interface (DALI) ^dali
+
+[Digital Addressable Lighting Interface](https://en.wikipedia.org/wiki/Digital_Addressable_Lighting_Interface)
+
+Open protocol defined by [IEC 62386](https://www.dali-alliance.org/standards/IEC62386.html).
+
+Includes wired (via [[twisted-pair-cable]] and 8P8C "RJ-45" connectors)
+and wireless topologies.
+
+##### Proprietary DALI Clones
+
+There exist several proprietary control ecosystems
+with feature sets and topologies identical to DALI.
+
+> I suspect these exist to skirt the cost of DALI's testing requirements.
+
+%%
+I'm less sure this is an apt description.
+The examples below are typical of some generic system,
+but it doesn't seem to be DALI.
+%%
+
+Examples include:
+* [Legrand Wattstopper Digital Light Management (DLM)](https://www.legrand.us/solutions/digital-lighting-management)
+* [Acuity nLight®](https://nlight.acuitybrands.com/overview)
+* [Lutron Quantum](https://www.lutron.com/us/en/controls/systems/quantum)[^1]
+* [Lutron Athena][^2]
+* [Cooper Greengate](https://www.cooperlighting.com/global/brands/greengate)
+
+[^1]: Maybe not. Sensors show 24V wiring.
+
+[^2]: Can not verify. Website is down at time of writing.
+
+#### Digital Multiplex (DMX) ^dmx
+
+[DMX512](https://en.wikipedia.org/wiki/DMX512)
+
+DMX512-A defined in ANSI E1.11-2008
+
+Shielded [[twisted-pair-cable]] with XLR or 8P8C ("RJ-45") connectors
+
+#### See Also
+
+> [!quote] [BACnet](https://en.wikipedia.org/wiki/BACnet)
+> **BACnet** is a communication protocol
+> for building automation and control (BAC) networks.
+> It is defined by **ANSI/ASHRAE 135** and **ISO 16484-5**.
 
 [[twisted-pair-cable]]
 
@@ -48,6 +97,8 @@ All these control methods are likely to appear in drawings.
 
 ### 0-10V Dimming
 
+[0-10 V lighting control](https://en.wikipedia.org/wiki/0-10_V_lighting_control)
+
 In conduit:
 
 ```

nfpa-70_338.md

@@ -5,9 +5,9 @@ aliases:
 title: "Article 338 Service-Entrance Cable: Types SE and USE"
 tags:
   - authorship/other
-  - destiny/fleeting
+  - destiny/permanent
   - exclude-from-word-count
-  - status/incomplete
+  - status/draft
   - topic/construction/electrical
   - type/media/reference
 ---

nfpa-70_352.md

@@ -5,7 +5,7 @@ aliases:
 title: "Article 352 Rigid Polyvinyl Chloride Conduit: Type PVC"
 tags:
   - authorship/other
-  - destiny/fleeting
+  - destiny/permanent
   - exclude-from-word-count
   - status/incomplete
   - topic/construction/electrical

nontraditional-computing-for-construction-estimating.md

@@ -0,0 +1,92 @@
+---
+id:
+aliases: []
+title: Nontraditional Computing for Construction Estimating
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/incomplete
+  - topic/construction
+  - topic/estimating
+  - type/cross-topic
+---
+# Nontraditional Computing for Construction Estimating
+
+Cross-topic of [[nontraditional-computing]] and [[construction-estimating]].
+
+### Sketch-Based Lookup
+
+%% TODO:
+This section is a transcription of a dictation.
+To be condensed.
+%%
+
+A better use for computer vision in estimating
+is sketch based assembly lookup.
+Probably the the biggest hang-up in the workflow
+is searching through available assemblies and items based on text,
+which has a number of problems,
+mostly that names, in electrical material for certain, are practically meaningless.
+
+Trade names are incorrect, and there are often many different names for the same item.
+Basically, there's just so many problems with text-based lookup as a rule.
+That sketching and handwriting recognition would be more idiomatic.
+
+Drawing lines for raceways, angles representing bends,
+squiggly lines representing flexible conduit, etc.
+All things that are common sketching conventions
+that estimators are probably drawing in their workflow anyway.
+
+Many parts of the estimating workflow would be greatly benefited
+by the sort of non-traditional interface that Ink & Switch promotes.
+Traditionally estimating software is all tables and forms.
+
+Suppose you were to sketch a takeoff indicating a run
+
+1. from a panel
+2. up to the ceiling
+3. across the building
+4. down to a disconnect
+5. out through a flex connection
+6. to a piece of equipment
+
+that's a very complex assembly,
+and despite how common it is,
+it can be very difficult to to get exactly that from databases.
+
+Suppose instead you draw that that sketch
+and the application creates a graph
+of all the primitive parts of that assembly.
+
+It may include the panel and the equipment by default
+but with the same stylus you used to draw the sketch,
+you just cross out the panel, the equipment,
+the parts that that you didn't intend to include.
+
+1. Draw a line from start to end.
+  * A canvas appears on top of the plans.
+2. Sketch the desired assembly with predetermined conventions.
+3. Draw a checkmark to confirm
+  * A render of the interpreted assembly appears
+4. Draw a second checkmark to select.
+
+A Non-Traditional Computing approach
+(journal-type, heavy-stylus-use),
+would would be great here, too.
+
+Keyboards as a takeoff input device are an anti-pattern.
+Every time you're entering data is an interruption.
+
+But perfect for that would be drawing takeoffs on the on the prints
+then using stylus based interaction patterns to edit them.
+Lasso selecting groups of takeoffs to change aspects of them.
+
+There is so little typing necessary.
+Everything that you're typing is just short descriptors
+that, in a lot of cases, don't even need to exist.
+the language exists purely to roughly communicate ideas
+that are intuitive in even a crude sketch.
+
+Estimating is a perfect use case
+for a purely stylus and handwriting recognition based workflow,
+probably more perfect than whatever Ink & Switch is using.

nontraditional-computing.md

@@ -0,0 +1,11 @@
+---
+id:
+aliases: []
+title: Nontraditional Computing
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/not-started
+  - type/encyclopedia-entry
+---
+# Nontraditional Computing

object-oriented-programing-for-construction-estimating.md

@@ -0,0 +1,38 @@
+---
+id:
+aliases: []
+title: Object Oriented Programming for Construction Estimating
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/incomplete
+  - topic/construction
+  - topic/estimating
+  - type/cross-topic
+---
+# Object Oriented Programming for Construction Estimating
+
+Cross-topic of [[object-oriented-programing]] and [[construction-estimating]].
+
+### Estimating As Code
+
+#### Compared to Existing Frameworks
+
+Traditional methods interact with an existing database.
+EaC builds a static database at runtime,
+allowing flexibility of input.
+
+* define variables
+* search and replace
+* undo
+
+#### Project Structure
+
+Organizational info (items, assemblies) as submodules.
+Solves database conflicts by pinning estimates to a commit.
+
+#### Related Notes
+
+* [[breakdown-objects]]
+* [[assembly-objects]]
+* [[labor-factoring]]

object-oriented-programing.md

@@ -0,0 +1,12 @@
+---
+id:
+aliases: []
+title: Object Oriented Programming
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/not-started
+  - topic/software
+  - type/encyclopedia-entry
+---
+# Object Oriented Programming

optimal-estimating-patterns.md

@@ -35,120 +35,3 @@ Optimizing the takeoff process means:
 * _Maximizing_ organizational consistency
 
 %%
-
-## More "Innovative" Patterns
-
-These ideas are farther out there
-in terms of what existing estimators may be willing to accept
-
-### Estimating As Code
-
-#### Compared to Existing Frameworks
-
-Traditional methods interact with an existing database.
-EaC builds a static database at runtime,
-allowing flexibility of input.
-
-* define variables
-* search and replace
-* undo
-
-#### Project Structure
-
-Organizational info (items, assemblies) as submodules.
-Solves database conflicts by pinning estimates to a commit.
-
-#### Related Notes
-
-* [[breakdown-objects]]
-* [[assembly-objects]]
-* [[functional-labor-factoring]]
-
-### Bayesian Takeoff
-
-#### User Story
-
-Frank is estimating a 20-story high rise
-and notices that their are roughly, but not exactly,
-the same number of receptacles in the corridors of levels 2 to 19.
-Frank starts a new takeoff for duplex receptacles,
-typical of levels 2 to 19.
-He counts and inputs quantities for 3 levels,
-each adjusts the prior to calculate the expected quantity for all 18 levels.
-
-### Sketch-Based Lookup
-
-%% TODO:
-This section is a transcription of a dictation.
-To be condensed.
-%%
-
-A better use for computer vision in estimating
-is sketch based assembly lookup.
-Probably the the biggest hang-up in the workflow
-is searching through available assemblies and items based on text,
-which has a number of problems,
-mostly that names, in electrical material for certain, are practically meaningless.
-
-Trade names are incorrect, and there are often many different names for the same item.
-Basically, there's just so many problems with text-based lookup as a rule.
-That sketching and handwriting recognition would be more idiomatic.
-
-Drawing lines for raceways, angles representing bends,
-squiggly lines representing flexible conduit, etc.
-All things that are common sketching conventions
-that estimators are probably drawing in their workflow anyway.
-
-Many parts of the estimating workflow would be greatly benefited
-by the sort of non-traditional interface that Ink & Switch promotes.
-Traditionally estimating software is all tables and forms.
-
-Suppose you were to sketch a takeoff indicating a run
-
-1. from a panel
-2. up to the ceiling
-3. across the building
-4. down to a disconnect
-5. out through a flex connection
-6. to a piece of equipment
-
-that's a very complex assembly,
-and despite how common it is,
-it can be very difficult to to get exactly that from databases.
-
-Suppose instead you draw that that sketch
-and the application creates a graph
-of all the primitive parts of that assembly.
-
-It may include the panel and the equipment by default
-but with the same stylus you used to draw the sketch,
-you just cross out the panel, the equipment,
-the parts that that you didn't intend to include.
-
-1. Draw a line from start to end.
-  * A canvas appears on top of the plans.
-2. Sketch the desired assembly with predetermined conventions.
-3. Draw a checkmark to confirm
-  * A render of the interpreted assembly appears
-4. Draw a second checkmark to select.
-
-A Non-Traditional Computing approach
-(journal-type, heavy-stylus-use),
-would would be great here, too.
-
-Keyboards as a takeoff input device are an anti-pattern.
-Every time you're entering data is an interruption.
-
-But perfect for that would be drawing takeoffs on the on the prints
-then using stylus based interaction patterns to edit them.
-Lasso selecting groups of takeoffs to change aspects of them.
-
-There is so little typing necessary.
-Everything that you're typing is just short descriptors
-that, in a lot of cases, don't even need to exist.
-the language exists purely to roughly communicate ideas
-that are intuitive in even a crude sketch.
-
-Estimating is a perfect use case
-for a purely stylus and handwriting recognition based workflow,
-probably more perfect than whatever Ink & Switch is using.

personal-values.md

@@ -2,7 +2,12 @@
 id:
 aliases: []
 title: Personal Values
-tags: []
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/incomplete
+  - topic/individualism
+  - type/encyclopedia-entry
 ---
 # Personal Values
 

professionalism.md

@@ -7,6 +7,7 @@ tags:
   - destiny/permanent
   - status/incomplete
   - topic/organization
+  - topic/individualism
   - type/philosophy
 ---
 # Professionalism

risk-management-for-construction-estimating.md

@@ -0,0 +1,98 @@
+---
+id:
+aliases: []
+title: Risk Management for Construction Estimating
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/incomplete
+  - topic/construction
+  - topic/estimating
+  - topic/risk
+  - type/cross-topic
+---
+# Risk Management for Construction Estimating
+
+Cross-topic of [[risk-management]] and [[construction-estimating]].
+
+## 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]]
+given an organization's [[risk#Risk Tolerance]].
+
+#### EVI Takeoff
+
+Expected value of information (EVI)
+
+#### Takeoff Optimization
+
+For systems where EVI analysis determines manual takeoff is still necessary,
+optimizations can be made to decrease the required effort of takeoff,
+and thus the opportunity cost of takeoff.
+
+See [[optimal-estimating-patterns]] for more.
+
+# Estimating Detail
+
+The acceptable level of detail of an estimate
+in [[construction-estimating]] is a contentious subject.
+What's worse, estimators often disagree
+on what makes an estimate more detailed than another.
+
+The commonly repeated answer is this:
+
+> As detailed as possible,
+> given required turnaround and available estimating resources.
+
+This analysis is flawed
+because it implies more time always ought to be preferred,
+when the reality is that when considering larger organizational factors,
+ideal estimate certainty is likely far lower than most expect.
+
+The correct answer involves optimizing for these factors:
+* value of increased bid certainty
+* value of increased estimate volume
+
+An estimate's detail is irrelevant to its quality.
+A less detailed estimate is a more [[risk|risky]] bid,
+but it is not the role of the estimator to determine acceptable risk.
+
+## Experiment
+
+Perform a system takeoff (lighting for example) in exacting detail,
+the maximum amount you would ever consider using,
+and measure the time required to do so,
+as well as the cost of the scope.
+
+Have another estimator takeoff the same scope
+using the proposed time saving strategy.
+
+Repeat the test on additional projects.
+
+Treat the detailed takeoff as the true value
+and find the error of the time saving strategy.
+
+$\frac{d\sigma}{dt}$
+
+### Expectation
+
+Time-saving strategies will overestimate or underestimate detailed takeoff
+depending on the assumptions used in their creation.
+
+## Human Error
+
+It is commonly understood that a "detailed takeoff"
+is more "accurate" than a square foot estimate.

risk-oriented-estimating.md

@@ -2,7 +2,7 @@
 id: risk-oriented-estimating
 aliases: []
 tags:
-  - destiny/permanent/entry-point
+  - destiny/fleeting
   - status/incomplete
   - topic/estimating
   - topic/risk
@@ -37,36 +37,6 @@ of critiquing common practice.
 
 %%
 
-## 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]]
-given an organization's [[risk#Risk Tolerance]].
-
-### EVI Takeoff
-
-Expected value of information (EVI)
-
-### Takeoff Optimization
-
-For systems where EVI analysis determines manual takeoff is still necessary,
-optimizations can be made to decrease the required effort of takeoff,
-and thus the opportunity cost of takeoff.
-
-See [[optimal-estimating-patterns]] for more.
-
 ## Potential Objections
 
 Objections to the use of historical data in new estimates are not unfounded.

statistical-modeling-for-construction-estimating.md

@@ -1,16 +1,33 @@
 ---
 id:
 aliases: []
+title: Statistical Modeling for Construction Estimating
 tags:
   - authorship/original
-  - destiny/fleeting
+  - destiny/permanent
   - status/incomplete
-  - topic/construction/electrical
+  - topic/construction
   - topic/estimating
-  - type/idea
+  - topic/math/statistics
-title: Stochastic Branch Takeoff
+  - type/cross-topic
 ---
-# Stochastic Branch Takeoff
+# Statistical Modeling for Construction Estimating
+
+Cross-topic of [[statistical-modeling]] and [[construction-estimating]].
+
+## Bayesian Takeoff
+
+#### User Story
+
+Frank is estimating a 20-story high rise
+and notices that their are roughly, but not exactly,
+the same number of receptacles in the corridors of levels 2 to 19.
+Frank starts a new takeoff for duplex receptacles,
+typical of levels 2 to 19.
+He counts and inputs quantities for 3 levels,
+each adjusts the prior to calculate the expected quantity for all 18 levels.
+
+## Stochastic Branch Takeoff
 
 generate a BOM from point loads distributed in a space.
 

statistical-modeling.md

@@ -0,0 +1,22 @@
+---
+id:
+aliases: []
+title: Statistical Modeling
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/incomplete
+  - topic/math/statistics
+  - type/encyclopedia-entry
+---
+# Statistical Modeling
+
+Bayesian inference is a method of statistical inference,
+the practice of analyzing and describing
+
+stochasticity is the property of an outcome
+that can be described with a probability distribution
+
+## Credibility
+
+* [[statistical-significance]]

taleb_2001_fooled-by-randomness.md

@@ -6,6 +6,7 @@ tags:
   - authorship/other
   - destiny/permanent
   - exclude-from-word-count
+  - status/incomplete
   - topic/math/statistics
   - topic/risk
   - type/media/book
@@ -25,4 +26,4 @@ This note, with the exception of comments like this one
 consists only of content from the text.
 For commentary see the companion
 [[fooled-by-randomness]].
-%%
+%%

tasks.base

@@ -3,12 +3,12 @@ filters:
     - file.hasTag("type/task")
     - file.name != "tags"
 views:
-  - type: table
+  - type: list
     name: all
     sort:
       - property: file.name
         direction: ASC
-  - type: table
+  - type: list
     name: meta
     filters:
       and:

utility.md

@@ -2,10 +2,15 @@
 id:
 aliases: []
 title: Utility
-tags: []
+tags:
+  - authorship/original
+  - destiny/permanent
+  - status/not-started
+  - topic/risk
+  - type/encyclopedia-entry
 ---
 # Utility
 
 [Utility](https://en.wikipedia.org/wiki/Utility)
 is a measure of a party's satisfaction
-with a certain state of the world.
+with a certain state of the world.