Architected Futures™

Tools and strategies ... for boiling the ocean


This portion of the Architected Futures™ website constitutes a focal point for content related to the Architected Futures™ community rather than the subject matter content for the site. This is the specification for social order and behavior. The two concepts come together as a matrix, defining a context set within the knowledge base.

The data gathered here can be mapped using standardized framework of components to form aggregate sets and subsets for various analytical purposes. As simple(?) as population planning or more complex scenarios like long term economic forecasting. The finished or target content would become "subject" content. How people organize and discuss that content is "community."

[image with vertical subjects and an "integration" column.]

The horizontal layers is similar (identical) to the diagram above. Content subject area define the columns. The integrated column defines, via the calculus of the system, the integrated "whole"

The focus here is not community as an abstract concept to be addressed by the EATS tool; but rather that actual community of people who share an interest in the concepts and purposes of the site. Communities of lawyers would use the legal/law column to "parse" their concepts and discussions based on levels of abstraction. This provides the consistency layering for integration of legal concepts, with other concept models. (This does not imply conceptual "legal" maps to conceptual "horticulture." Rather, it is used in the models to extract the right layer or layers of conceptual information about law will or could be used with some other arbitrary scenario, game, simulation, etc.


The following outline, developed by Amy Jo Kim is used as a framework for description and modeling of communities. This is starting point, but assumed a good one, since it is anticipated that the thrust for social interaction between people in the communing timeframe will be oriented toward online communities. The general model should also work for other communities including nuclear families.The models are used to specify generic personas.


The real people are in the trenches. Instances in AIR. The model is not the person. The person is in the real, real world.

Instances within EATS represent one or more instances of specific or generic "models" of the real people and their organizations.

AIR Element types define feature attribute and capability attribute and value attribute sets to the "models" of the real people. At this level there may be two forms of person types: an individual and a group, or there may be such types as dental specialists at a technical level, and just dentists at a higher conceptual or logical level.

AIR Element Classes are agnostic to the detail characteristics but more classifying such as dentists with special certifications (implied to have special knowledge or skills.)

In addition to the normal 6 hats questions (who, what, where, when, how, why), which are gathered for everything, data collection focuses on the following areas. The initial test case for beginning to fill this out, is the Architected Futures community itself, completing it via self-documentation and experience, and a generalized view of the world population from the perspective of the Architected Futures community.

The end intent is to define and build a "people model" defining the who, what, where, when, how and why for the global population. Using an agent-based modeling approach, in combination with other techniques (SD, etc.).

Amy Jo's focal elements:


  1. Purpose
  • For each person or group identified as a distinct "group" or entity, hierarchical sets are built upward to create aggregations that eventually lead to the totality of the human population. Represented one way or another, even if it's one element for the population of a continent (assuming a global model), or the State of Idaho if we were doing a US model. Mapping of groups needs to be cognizant of the availability of data that can be mapped to those groupings. Groups can overlap as long as there is a way to map the overlays.
  1. Places: Bringing People Together.  Where, how and why does that happen.
  2. Profiles: Getting to Know Your Members. This defines personality and related effects on behavior.
  3. Roles: From Newcomer to Old-Timer. How do people age and what functions do they accomplish at what points in their life? What security and privacy protocols and restrictions are involved?
  4. Leadership: The Buck Stops Here. How do they govern?
  5. Etiquette: Rules to Live By. How do they deal (perform interactions) with others, near and far, foreign and domestic, formal and informal, friend and foe?
  6. Events: Meetings, Performances and Competitions. Official and unofficial. Includes forms of commerce, education, research, etc.
  7. Rituals: Handshakes, Holidays, and Rites of Passage
  8. Subgroups: Clans, Clubs and Committees

All of this needs to be prepared and entered using a managed template to facilitate encoding into managed relationship sets with enforced relational mapping as to ontology.

You notice this is all about people. That's because people are who we want to focus on. People are who we want to help. And, people are the wild card in the whole system because they are fickle, they change their minds, they change their values,  and sometimes they are very self-destructive or they do things unexpected without regard to all the consequences. In effect, they are their own worst enemy. But we love them.