Home Systems — Model Architecture

This blog outlines the process of moving from abstract constraint to operational viewpoints for the ideal home. It starts with formally defining Land Capacity and Inhabitant Demand. It then frames the abstraction in terms of general stakeholder concerns and wraps up with several architectural viewpoints for implementing the model.

Introduction

The core constraint of the ideal home—Demand ⊆ Capacity—is a coherent abstraction. However, for the operability of the model, this abstraction must move toward concrete implementations. To do this, architectural design is useful for keeping the core constraint consistently applied.

The following will begin by creating operational definitions for demand and capacity. From there, macro-level design will be established for operational views and domains. With this completed, future implementation will be much more constructive and focused.

What Are Demand and Capacity?

Demand and capacity are the two variables that make up the core constraint of the ideal home (Demand ⊆ Capacity). While the relationship is intuitive enough, the terms themselves can become complicated when applied. Questions begin to emerge, such as:

These questions matter because the model needs to remain consistently applied across use cases.

Capacity & Demand as Sets

In the current understanding of the model, capacity and demand are treated as sets of objects. Thus, capacity can contain any number of objects, such as:

Demand can contain objects such as:

What this demonstrates is that demand and capacity are sets containing heterogeneous objects—that is, objects that are not of the same kind. For instance, usable area is not the same type of thing as sunlight exposure.

So the question becomes: what is the common property among each respective set? To put it more philosophically:

Demand ⊆ Capacity Is an Abstraction

It is important to remember that Demand ⊆ Capacity is an abstraction, which means it is meant to be generalizable across use cases. Because of this, neither demand nor capacity should be trivially reduced to one type of thing. Instead, they need to apply to many operational realities at once.

Requirements for Operational Definitions

In order to arrive at a working definition, it may be best to consider the needs the definition must satisfy.

First, the definition must be generalizable—that is, it must apply across all use cases. While we cannot know all use cases, we can know those which we have already explored: across time and in terms of food, water, and energy usage. So we know the definition cannot be limited to any one of those perspectives but must subsume them.

Second, the definition must be meaningfully restrictive. In other words, the definitions cannot be so broad that they become operationally meaningless by providing no semantic constraint. For instance, if capacity simply means any aspect of land whatsoever, distinctions between storage and production become difficult to reason about consistently.

Definitions

With that in mind, we can begin working toward formal definitions.

Land Capacity (Capacity): any aspect of land that contributes to satisfying inhabitant demand.

More formally:

Land Capacity = { x | x is an aspect of land that contributes to satisfying inhabitant demand }

A more abstract version:

Capacity = { x | x participates in the support of inhabitants }

Inhabitant Demand (Demand): the required support needed by inhabitants.

Formally:

Demand = { x | x is required for inhabitant support }
Disclaimer: These definitions do not fully resolve operational distinctions such as storage vs. production, suggesting that such distinctions may belong to operational views rather than the foundational ontology itself.

Architectural Viewpoints

To begin describing architectural design, it is useful to determine what perspective we are viewing the abstraction from. This is often termed a viewpoint in formal systems architecture.

A viewpoint implies the presence of a stakeholder and a concern. For the following, the primary stakeholders will be:

The concerns these stakeholders have largely fall under the umbrella of bridging the gap between the abstract and the concrete, or otherwise moving from theory to practice. For this, we need ways to put these abstract categories into:

The following will be an attempt at doing so.

Domain Viewpoint

Demand and capacity represent resource dynamics between land and inhabitants. These resource dynamics can be decomposed by type, or domain. For instance:

A major architectural task would be to identify central resource domains that drive the most meaningful exchange between land and inhabitants. We could call these core domains.

Core Domains

To narrow down potential core domains, we must identify what demands are most central to inhabitants. In general, these would be the demands that are necessary for survival. This would include the demand for resources such as:

Food and water are relatively straightforward resource domains. In terms of inhabitants, this represents metabolic and hydration requirements. This directly corresponds to a land’s capacity to provide caloric yield and water availability.

However, shelter becomes a bit less meaningful if taken as a static structure. Should we simply treat it as a need for a house? If so, capacity just becomes the ability to provide materials or the existing structure itself. Instead, shelter may be more meaningfully understood as the need for protection from the environment.

This includes weather, solar radiation, predators, and more. If we were to abstract a core need from this, thermoregulation may be the most comprehensive and appropriate for our current purposes. With that, we could say energy is a meaningful resource domain—land must provide enough energy for inhabitants to protect themselves from the elements.

Note: Due to the significance of power in modern homes, and its overlap with energy more generally, it is reasonable to visualize inhabitant energy demand (thermoregulatory requirements) as subsumed by a more comprehensive power/energy usage. For the sake of simplicity, the following will commit to the above conclusion. However, future developments may deviate toward the latter.

This leads us to our core domains (non-exhaustive):

Formal Subsets

With that in mind, we can begin formalizing these core domains. To start, demand and capacity represent resource sets. These sets can be partitioned into constituent subsets based on resource demands.

By applying those domains to our sets, we can produce formal subsets:

Capacity = { Caloric Yield, Water Availability, Energy Availability, ... }

Demand = { Metabolic Requirements, Hydration Requirements, Thermoregulatory Requirements, ... }

Thus, we can formally express the core constraint in terms of domain:

Metabolic Requirements ⊆ Caloric Yield

Hydration Requirements ⊆ Water Availability

Thermoregulatory Requirements ⊆ Energy Availability

Modal Viewpoint

A question that begins to emerge when considering resource subsets is: does this subset represent a potential or actual value? Is crop yield what a land is capable of producing or what it has actually produced? Are we thinking in terms of realized production or possible outcomes?

This concern creates the need for a modal viewpoint—a perspective concerned with the state or mode of a thing rather than its substance. In other words, the modal view is used when a use case requires knowledge of the state in which a resource exists.

From this view, we can now answer questions such as the above. A subset can be analyzed as actual or potential. For instance, a food subset of land capacity may be determined in terms of crop yield, as well as in terms of potential crop yield.

Actual vs. Potential

The primary practical difference between actual and potential is that of input. For instance, when measuring actual crop yield, we are measuring realized production (e.g., amount of each crop type, weight, etc.).

actual_yield( crop_type, weight, ... )

With potential yield, the input becomes arable area, soil profile, crop selection, climate conditions, etc.

potential_yield( arable_area, soil_profile, crop_selection, climate, ... )

On the surface, it may seem that actual and potential modes are primarily concerned with land capacity. This may be true practically speaking; however, these same modes can be applied to inhabitant demand. For instance, it may be useful to consider the potential for family growth, changing individual needs, or even health complications. Thus, there is a potential inhabitant demand that exists alongside the current actual demand.

Mode × Domain Matrix

From here, we can begin formalizing resources according to a matrix:

Actual Potential
Food Crop yield Potential crop yield
Water Water availability Potential water availability
Energy Energy availability Potential energy availability

If this seems obvious or unrevealing, that means the architecture is doing its job. The goal is not to produce profound insights, but rather to organize the macro-level structure of the model so that it can begin reflecting the nuances of the underlying reality while reducing complexity.

Extensibility of Modes

This section focused on actual and potential modes. However, these modes do not exhaust the modal view; they simply happen to be a useful starting point. Future extensions could account for a range of possible modal views, such as peaks, failure states, risk, etc. Furthermore, explicit use of possible world semantics, as well as stochastic analysis, could make the existing architecture more robust. That said, the current goal is simply to establish a minimally useful set that is immediately operational.

Temporal Viewpoint

It is necessary to consider temporality if we are to avoid treating the relationship between land and inhabitants as static. This is where the model becomes:

∀t, Capacity(t) + Storage(t) ≥ Demand(t)

With the variable time, we can now model capacity and demand as multidimensional.

Common time periods may include:

Stocks and Flows

With the temporal dimension, we now see the importance of explicitly modeling storage — capacity is not just what is produced at any moment, but also what has accumulated over time. A question raised previously was: does capacity include storage? The answer is yes.

The distinction we actually make here is not between capacity and storage, but between stocks and flows. Flows are the processes through which transformation occurs. Practically speaking, in terms of resources, flow is the rate at which a quantity increases or decreases. A field of crops actively produces over a period of time, and the rate at which that occurs (e.g., x per month) can be thought of as the flow of production.

Stocks represent the state of resource quantity at a moment in time. While a crop field is understood as producing over time, a storage unit can be understood as holding a static amount at a discrete moment in time.

For a stronger visual representation, a matrix may help:

Stock Flow
Food Pantry Crop growth rate
Water Reservoir volume Rainfall per day
Power Battery charge Solar generation rate

Thus, where technical clarity is a concern, the above model may actually be described as:

∀t, Flow(t) + Stock(t) ≥ Demand(t)

Evaluative Metrics Viewpoint

From the relation of the above viewpoints, we can derive metrics for certain use cases.

Optimality

Represents how efficiently a system realizes its theoretical productive potential in practice. Measures the percentage of potential capacity that is realized as actual capacity.

optimality% =
actual_capacity potential_capacity
x 100

Example:

Feasibility

Represents the degree to which a system can satisfy required demand under its available capacity constraints. Measures the percentage of demand that can be satisfied by available capacity.

feasibility% =
potential_capacity - overhead_loss demand
x 100
Value Meaning
50% insufficient
100% exact sufficiency
200% double required capacity

Example:

Sustainability

Represents the degree to which a system can sustain its own productive capacity without self-exhaustion. Measures the percentage of potential capacity that remains after sustaining the system itself.

sustainability% = 1 -
overhead_loss potential_capacity
x 100
Value Meaning
100% no sustaining overhead
80% efficient
50% half of output consumed internally
0% entirely self-consuming
< 0% unsustainable

Example:

Conclusion

With that, the model has now moved from pure abstraction toward operationalization. Capacity and demand have been given formal definitions. Several viewpoints have been defined for common use-case perspectives. From here, the model can begin developing toward practical ends.

The next steps will involve developing thin-slice prototypes for each major domain. This will be done using an experimental method so that models can be empirically grounded. These prototypes can then be iterated upon as real-world demands emerge.

The prototypes will start small and minimal. The goal for this model is not precision, but utility. If a crude or simplistic model of the land provides useful metrics for analyzing feasibility, then further fidelity is not necessarily helpful nor desired.