Oughtomation in a Nutshell

No one can derive OUGHT from IS, as David Hume argued three centuries ago.

But anyone can assert OUGHT from IS. That's called a 'rule'. In every society, organization and household, each person is both a rule-maker and a rule-taker as we routinely use terms such as MUST, MAY, and SHOULD, or their various negatives and synonyms.

Let's describe those two roles very generally as follows:

  • A 'rule-maker' is any person (individual or entity) asserting an obligation, permission, or encouragement
  • A 'rule-taker' is any person (individual or entity) subject to obligation, permission or encouragement

Of course, we can distinguish informal and formal rules:

  • Informal IS ⟾ OUGHT assertions are opinions and attitudes that arise in cultural and interpersonal relationships.
  • Formal IS ⟾ OUGHT assertions are composed as laws, contracts, specifications, administrative policies, treaties, standards, and similar documents.

The Latin word for rule is norma, and statements about rules are referred to in the philosophical literature as normative propositions. In the terminology of our framework, we say that a formal rule is ‘in effect’ for a context of dates/times and prerogatives based upon identity and jurisdiction. And we say that a rule is ‘applicable’ to certain general types of activities, things, and/or purposes. Further, when particular events or circumstances unfold that correspond to some particular scenario described in a rule, we say that the rule is 'invoked'. This is relevant to any domain that is subject to obligation, permission, or expectation. Here we speak in the abstract instead of through examples, in order to emphasize the general-purpose utility of the approach.

Each rule is based upon some type of agreement, authority, resolve, or preference which persists through a period of time. In varying degrees, a person may like or dislike a rule; advocate or challenge it; conform with or evade it; understand or be confused by it. But prior to all of that, a person has to know about a rule for that rule to exist for them to react to. Suppose that we use the expression 'IS + RULE ⟾ OUGHT' to refer generically to any assertion that a particular factual circumstance invokes a certain set of obligations, permissions or expectations. The symbol ⟾ is not intended to just mean therefore. In our system, the symbol ⟾ means when there is a known rule which is 'in effect', 'applicable' and 'invoked', therefore. To avoid confusion it's best to use the full expression 'IS + RULE ⟾ OUGHT' than a short form like 'IS ⟾ OUGHT'.

From this we can percieve a rule as a type of message between a rule-maker and a rule-taker. We would go so far as to day that an IS ⟾ OUGHT assertion that is not communicated, does not exist, in the same way that a statement uncommunicated by the author to someone else is not a message.

And this begs the question: How does anyone obtain awareness of formal IS + RULE ⟾ OUGHT assertions?

Oughtomation is a new general-purpose request-response messaging system for use across any digital network. It is designed to make it easy for anyone to publish, discover, fetch, scrutinize and prioritize rules in a way that can be directly read and understood by non-specialized humans and machines, for any purpose, in any language. The purpose of this system is to enhance the functional communication of IS ⟾ OUGHT assertions with precision, simplicity, scale, volume and speed. This system accommodates a hierarchy of rules, the sense that there are meta-rules that structure of rule-making itself, based on jurisdiction and identity. In law this is refered to as 'prerogative'.

Oughtomation is a four-part specification, consisting of: the RuleSchema data model; the RuleMaker application design; the RuleTaker component design; and, the RuleReserve data storage design. Any person (individual or entity) can operate all or some of these elements at their point of connection ('node'), where all of these nodes taken together comprise a peer-to-peer network for the exchange of IS + RULE ⟾ OUGHT data. Each of these four parts is passive, which is to say that every action is initiated by a human agent through a node, or by their authorized intermediary machine or application.

Oughtomation serves a communications role, to provide information to the user of a node on this network, with no capability to impose, enforce, or monitor. This is deliberate. From the philosophical core through to the working reference implementations, oughtomation is premised upon IS ⟾ OUGHT assertions being subject to the complexities of interpretation and context. In a milieu of diverse parties, unknown scenarios, and externally defined rule structures and sequences, it is essential that each person deemed to be subject to a rule determines whether or not, and to what degree, to proceed in accordance with it. This is just a logical necessity of complex normative human-centred design. An Internet of Rules requires inviolable rule-taker agency, unlike systems that would use mechanistic procedures or semi-autonomous artificial intelligence.

The four parts of this specification are managed as discrete sub-projects of the Oughtomation Working Group, hosted by Xalgorithms Foundation. To introduce the design, I'll provide below a general functional summary. The more thorough descriptions are available in the core oughtomation paper. We will wrap up with a few highlights arising from oughtomation's unique design.

A Functional Walk-Through

Oughtomation RuleSchema Specification

Normative propositions (i.e. statements involving MUST, MAY and SHOULD, or their negatives or synonyms) are packaged in oughtomation as a distinct class of structured data. Each record contains metadata, input/output or reference data, and some additional descriptive fields, expressed in a simple tabular declarative form. The records are structured for efficient storage; rapid sifting (i.e. simple filtering); and high performance transmission. Most importantly, data, logic and procedure are unbundled. Therefore, the data is comprehensible for display on end-user devices, for integrity auditing, as well as for dynamic incorporation into applications on any platform. When accompanied by a parsing library, these rule records can be queried from, or embedded into, or auto-transcribed into any programming language.

Oughtomation RuleMaker Specification

RuleMaker describes an easy-to-use application for authoring, publishing, and maintaining rules and their reference tables, along with portfolio management, and storage/retrieval of rule records and reference data records with the repository. RuleMaker does not require the rules author to write any programming code, or to know the nuances of algorithmic logic. Instead, someone using RuleMaker is provided a fixed-grammar template with six syntactic elements to create the particular type of declarative sentence for the Input Conditions and Output Assertions. RuleMaker output conforms with the RuleSchema specification and is ready to be published to the RuleReserve network, a sort of digital library. All rules and reference data records are maintained in the author's own online versioning repository.

Oughtomation RuleReserve Specification

Independently-operated RuleReserve instances comprise nodes of a decentralized network so that participant can self-provision an 'IS ⟾ OUGHT' service over the Internet. They jointly host a distributed library of records and supporting reference data records. Each rule record occupies a single row (referred to as [rule.xa]) of a large consolidated matrix [m x n] (i.e. rows x columns) for compact storage, and fast, high-volume data sifting. Each RuleReserve node is equipped for request-response messaging. A RuleReserve instance receives structured messages containing factual data describing a circumstance (referred to as a [is.xa] message), which is pre-configured as to sift through all the rows for rules that are ‘in effect’ and ‘applicable’ to the contents of that message. Rows remaining from the two-cycle sifting operation are packaged into an response message (called [ought.xa]) that is returned to the particular RuleTaker that issued the original [is.xa] request. In sum: RuleReserve uses [is.xa] requests to sift through [rule.xa] records to assemble and return [ought.xa] responses. A RuleReserve node has no capability to initiate action; it receives [rule.xa] records uploaded to [rulereserve.xa] from RuleMaker instances, and it receives [is.xa] request messages that it employs as simple sieves to quickly generate [ought.xa] response messages. The RuleReserve does not process logic gates that [rule.xa] records contain, because they may involve private or confidential information that must be under the control of end-users. It is left to the operators of RuleTaker components to determine exactly what rule results are invoked.

Oughtomation RuleTaker Specification

The RuleTaker specification can be implemented and used as a stand-alone app or as an auxiliary component or service with any other platform. Its purpose is to enable a person (individual or entity) to fetch, scrutinize, prioritize, and optionally to computationally process normative rules and related reference tables that have been obtained from the RuleReserve network. The [is.xa] message that was used on RuleReserve nodes to sift for rules that are 'in effect' and 'applicable', is used again locally to sift though the logic gates of each of the rules in the [ought.xa] message. RuleTaker rapidly compares the contents of that [is.xa] message to the Input Conditions of each rule in order to identify the matching scenario column(s), and this reveals which of the Output Assertions are ‘invoked’, as well and providing the normative mode. This result can then be presented to the user directly, or via the platform they are using. This RuleTaker component has no capability to initiate an action to reach out and get data; it is only able to respond to events data supplied through user action or configuration.

Some Design Highlights

The whole of oughtomation is more that the sum of its parts. Some very interesting concepts and capabilities emerged from deliberations among community contributors.

One of the most useful outcomes is that oughtomation enables full multilingual equivalency for the expression and sharing of rules. Each row label with an Input Condition or an Output Assertion contains a complete sentence, but each of these sentences shares the same syntactic structure, based on six elements. The sentences can be in any natural language for human comprehension. Since they are always pre-parsed into the same six syntactic elements, data processing is efficient. A novice rule author need only be provided a few examples in any language they are comfortable with, and they would be able use the six syntactic elements provided in RuleMaker to create their own structured sentences in any other language they know, using any character set, with elements displayed in the orientation, order and flow direction of the language in use (e.g. horizontal left-to-right; horizontal right-to-left; vertical top-to-bottom). The multilingual character of the oughtomation specification enables an Internet of Rules that is linguistically and culturally pluralist.

We are also pleased with the very simple but information-dense input/output logic gate that emerged from a blend of thoughtful team discussion and deep-dive research. This is structured as a quaternary bilattice, that's to say, a table with two sets of semantic meanings assigned to each of its four symbols. Input Conditions are associated with combinations and permutations of {00,01,10,11} to signify {Inapplicable, Applicable, Both, Either}. Output Assertions are associated with combinations and permutations of {00,01,10,11} meaning {NOT, MUST, MAY, SHOULD}. This reduces the computational burden enormously.

Finally, at a very broad conceptual level, the oughtomation specification holds Artificial Naïvety (A∅, eh-nought) to be a mandatory system criterion. All concerns relating to context, comprehension, purpose, reason, learning, or motivation are end-user prerogatives, and all of the system’s data, metadata and activity logs belong to end-users. An A∅ system has no methods to retain or copy data or metadata. A RuleReserve node occupies itself with each run-time request-response signal that is being processed and does not store those details. This design aligns to the well-known axiom of Internet architecture that: “The Internet has smart edges... and a simple core" IETF RFC3439. Some Internet Architectural Guidelines and Philosophy This is a very different approach from Artificial intelligence (AI) which involves active knowledge acquisition, inductive reasoning, stochastic variational inference, and double-loop learning. The two are not mutually exclusive. Any person may choose to use oughtomation's A∅ together with their favourite AI platform.