RuleTaker re-uses is.xa msg data as a sieve.xa to sift the logic gate of each rule.xa row in the ought.xa msg. Some rows use lookup.xa calls. ($2145557) · Snippets

A RuleTaker component was given data by an end user, either directly or via an application that they were using. RuleTaker automatically packaged that data in the form of an is.xa request message, with addressing data in a header required for targeting back the response. This is.xa was sent over the Internet to a distributed and decentralized RuleReserve node.

This sequence does not seem correct. The primary reason is "was given data by an end user ... automatically packaged". This suggests that XA-RT is somehow aware of a domain-specific context that would remain undefined until an integration is performed with XA-RT.

I wonder if you're conflating the concept of "XA-RT is a library that can be integrated with an application" and the "API" that XA-RT presents?

As a core component of XA, XA-RT should exclusively adhere to only our APIs and data formats, not an external format. This suggests that the "packaging of data" into ìn.xa`is not performed by XA-RT, but by the application integrated with XA-RT.

A database is a decent exemplar of the problem: When you write an application you develop a "data model" that is of semantic significance to your application. While you might store that data in a DB, it has no semantic awareness of the data. It's merely columns and rows with particular datatypes. Your application interacts with the DB using SQL - a specialized API expressed in relational algebra. Our is.xa is something like the SQL.

is declared APPLICABLE to any circumstance declared in a sieve.xa that contains box_type : standard

This is a novel definition of APPLICABLE for me. To determine this information, we would need to (effectively) evaluate the rule.xa, negating the need for the INVOKE phase.

"customer_id" : [4d4673b6-3f5d-499b-a87e-468bd0b2c268] "frequency_group" : "==frequent" 
"customer_id" : [4d4673b6-3f5d-499b-a87e-468bd0b2c268] "spend_group" : "!=high"

In this snippet, what I think you're trying to accomplish is to select rows 2, 4 (filters are AND) from the table that follows. If you're trying to select rows 1, 2, 4 (filters are OR); that's a different conversation so let me know if that's the case. After selecting those rows, you also want customer_id to be available in the final sieve.xa.

Here, I'll show you how to do this using the syntax from the operational commentary:

# select all rows where frequency_group is 'frequent'
"frequency_group" : "[4d4673b6-3f5d-499b-a87e-468bd0b2c268]=='frequent'",
# refine the selection where spend_group is not 'high'
"spend_group" : "[4d4673b6-3f5d-499b-a87e-468bd0b2c268]!='high'",
# refine the selection to include all customer_id
"customer_id" : "[4d4673b6-3f5d-499b-a87e-468bd0b2c268]"

Recall that in the Input Conditions section, the numeric values {00,01,10,11} mean {INAPPLICABLE; APPLICABLE; INAPPLICABLE AND APPLICABLE; INAPPLICABLE OR APPLICABLE} whereas in the Output Assertions section the same values mean {NOT; MUST; MAY; SHOULD}.

As an aside, I'd like to understand how exactly you expect 10 and 11 to match. If we have an expression x==1, if x is 1, then the expression evaluates to true. Does that match all of { 01, 10, 11}? Conversely, if x is 2 (false), then does this match all of { 00, 10, 11 }?

Suppose that the returned ought1.xa message from the RuleReserve network contains a row with the Grocery Store Delivery Policy

This ought1.xa that's returned contains references to rules that were IN EFFECT and APPLICABLE, of which "Grocery Store Delivery Policy" is one, correct?

contained_value>=USD100: B is valid

This evaluates to false, and a 10 case (A) is eliminated, so I can conclude that false does not match 10, yes? What about 11? Following on my previous question, does false only match 01?

"contained_value" : ">=USD100"

This reminds me: We're going to have to consider "types" of things in the expressions. In this case "currency". This is important because it takes us down the line of "is expressing something like currency important?". Consider, for example, if is.xa contained "contained_value" : "CAD100". Since we "know" the "type", would we convert to compare? If we would not, then consider whether USD100 could just be 100.00 in this rule. If you feel that it could not, could you explain your reasoning?

RE: "This is a novel definition of APPLICABLE for me. To determine this information, we would need to (effectively) evaluate the rule.xa, negating the need for the INVOKE phase."

Oops, you're correct. I have adjusted that text to say "INVOKED in [REMOVED: declared APPLICABLE to]"

RE: "Here, I'll show you how to do this using the syntax from the operational commentary:"

What I want to express here is that the lookup uses the customer_id supplied in the is.xa to find the same customer-id in the lookup table. When it appears in that lookup table, then RT looks over at the "frequency_group" column of the same row to find out whether it is "frequent"; and also looks over at the "spend_group" column of the same row of the matching customer_id to find out whether it is NOT "high".

RE: "A"s an aside, I'd like to understand how exactly you expect 10 and 11 to match."

When the rule maker assigns a 01 to this, then when the sieve has a match then this contributes to an INVOKE result.
When the rule maker assigns a 10 to this, then whether or not the sieve has a match then this contributes to an INVOKE result.
When the rule maker assigns an 11 to this, then whether or not the sieve has a match then this contributes to an INVOKE result.

The 10 (AND) and the 11 (OR) operate the same at this point, but he meaning is different.

RE: "If we have an expression x==1, if x is 1, then the expression evaluates to true. Does that match all of { 01, 10, 11}? Conversely, if x is 2 (false), then does this match all of { 00, 10, 11 }?"

RE-STATED: "If we have an expression x==1, if x is 1, then the expression evaluates to APPLICABLE. Does that match all of { 01, 10, 11}? Conversely, if x is 2 (INAPPLICABLE), then does this match all of { 00, 10, 11 }?"

Yes.

I understand your inclination to retain 'true/false' terminology. This is the convention in almost all programming languages.

I have a background hunch (only a hunch, though) that errors of meaning can arise when 'translating' into epistemological notions. The choice of terms based on 'applicability' instead of 'truth' is not a UI choice, but reflects intrinsic meaning within the method.

!A ≡ not ‘a’
A ≡ ‘a’
A&!A ≡ ‘a’ and not ‘a’
A|!A ≡ ‘a’ or not ‘a’

True/False does not handle uncertainty or complex systems programming well.

I learned a few things from the literature on molecular computing -- I share samples a couple of months ago, and recently came across these too:

Consider DNA- and RNA-Based Computing Systems and Enzyme-Based Computing Systems.

DNA Logic Circuits

In that sort of computing environment, the concepts of T/F are not relevant. Instead, {A,C,T,G} or {A,C,T,U} are the available states.

Well, I came across that literature after I came across the catuskoti logic literature upon Wayne's recocmmendation. But whatever the route, expressing any of these quaternary logic methods with true/false notions, although culturally more comfortable for developers, and needed in order to program current-generation software, is nevertheless a source of confusion to keep in mind.

RE: "We're going to have to consider "types" of things in the expressions. In this case "currency". This is important because it takes us down the line of "is expressing something like currency important?". Consider, for example, if is.xa contained "contained_value" : "CAD100". Since we "know" the "type", would we convert to compare? If we would not, then consider whether USD100 could just be 100.00 in this rule. If you feel that it could not, could you explain your reasoning?"

Hmm, I neglected to mention this in the core paper, though it's in the example used throughout. Xalgo Rule Schema (XRS) will need the same types as spreadsheets offer: Number, Percent, Currency, Date, Time, Fraction, Boolean Value, Text, UserDefined

Since XRS should be usable in any language, it's not optimal to use those terms in XRS expressions directly, however...

When a string is currency, I do prefer to use the ISO standard 3-letter codes like CAD, EUR and USD, extended to things like BTC, XRP, ETH, IOT, etc. An XRS convention could be preceed the USD100 with EITHER the generic ascii symbol for currency which is: ¤ or, for something suited to the typical keyboard, the Unicode for that symbol, U+00A4, or for readability: [type:¤]USD100.00 OR [type:U+00A4]USD100.00

Having said that, I agree that for someone writing rules in English, it would be nice to be able to choose to DISPLAY in the UI: [type:currency]USD100.00

And having said that, surely this is a loooong-solved problemita, no?

What I want to express here is that the lookup uses the customer_id supplied in the is.xa to find the same customer-id in the lookup table.

Ah ha! I wondered if that was the case. Here's the way to do that:

# refine the selection to include customer_id from is.xa
"customer_id" : "[4d4673b6-3f5d-499b-a87e-468bd0b2c268]==customer_id"
# select all rows where frequency_group is 'frequent'
"frequency_group" : "[4d4673b6-3f5d-499b-a87e-468bd0b2c268]=='frequent'",
# refine the selection where spend_group is not 'high'
"spend_group" : "[4d4673b6-3f5d-499b-a87e-468bd0b2c268]!='high'",

If is.xa contained "customer_id" : 382639, then the result would be row 2 and the sieve.xa would be built according to the single-row semantics. Conversely, if is.xa contained "customer_id" : 937465, then the sieve.xa would _only contain keys from is.xa. The frequency_group and spend_group expressions would have previously filtered away row 3, leaving nothing for 937465 to filter.

This might seem "odd", so I'll explain. The reason this works is because customer_id is still bound to the key in the is.xa when the customer_id filter is activated. The expression means "include customer_id from the lookup.xa in the sieve.xa where it equals the current value of the customer_id key". Since there's no previous binding of that key, we only have the value from is.xa.

If we were to change the rule to:

# refine the selection to include customer_id from is.xa
"customer_id" : "[4d4673b6-3f5d-499b-a87e-468bd0b2c268]"
# select all rows where frequency_group is 'frequent'
"frequency_group" : "[4d4673b6-3f5d-499b-a87e-468bd0b2c268]=='frequent'",
# refine the selection where spend_group is not 'high'
"spend_group" : "[4d4673b6-3f5d-499b-a87e-468bd0b2c268]!='high'",
# refine the selection to include customer_id from is.xa
"customer_id" : "[4d4673b6-3f5d-499b-a87e-468bd0b2c268]==customer_id"

Then we'd get all the rows that matched the middle filters because the rule has rebound customer_id.

RE: "This might seem "odd", so I'll explain."

Didn't seem odd to me. My thoughts are now about how this gets written in RM.

RE-STATED: "If we have an expression x==1, if x is 1, then the expression evaluates to APPLICABLE. Does that match all of { 01, 10, 11}? Conversely, if x is 2 (INAPPLICABLE), then does this match all of { 00, 10, 11 }?"

Again, I think we cannot bind APPLICABLE to something that will result in evaluation of expressions. To say that "x is 1 is APPLICABLE", we need to "run the program". The whole point of APPLICABLE is to "guess that the program" could produce output if the rule were run.

I understand your inclination to retain 'true/false' terminology. This is the convention in almost all programming languages.

No. I'm not retaining it. An expression like x==1 will be either true or false (unless we're using quantum computer). That's just reality. We're evaluating a different epistemological notions on top of it, but eventually at the bottom we're still constrained by notions that the machine we have is capable of intrinsically.

If we don't perform this consideration, the concept cannot be implemented.

need the same types as spreadsheets offer: Number, Percent, Currency, Date, Time, Fraction, Boolean Value, Text, UserDefined

Ok... Sounds like a commentary to write.

And having said that, surely this is a loooong-solved problemita, no?

Yup. A lot of it can be inferred if we stick to consistent expression syntax:

bool: true, false
string: 'some string'
datetime: 2006-08-14T02:34:56-06:00
etc.

RE: "Again, I think we cannot bind APPLICABLE to something that will result in evaluation of expressions. To say that "x is 1 is APPLICABLE", we need to "run the program". The whole point of APPLICABLE is to "guess that the program" could produce output if the rule were run."

Ah okay, I finally see the source of the inconsistency on my end. We have simple 'IN EFFECT' and 'APPLICABLE' sifting that occurs out on the RR network, but then I've been the one hanging onto 'APPLICABLE' in RT. The process there is slightly more complicate sifting the Input Conditions of the logic gates. Mea culpa! ¯_(ツ)_/¯

So, thinking further, my reasons for preferring to not say TRUE and FALSE are not significant enough for me to hang onto my reluctance. We'd keep the {00,01,10,11} in the logic gate but their Input Condition meaning would be F; T; F-AND-T; F-OR-T.

Correct?

Incidentally, this is much easier to talk about too: False, True, FandT and ForT.

So, thinking further, my reasons for preferring to not say TRUE and FALSE are not significant enough for me to hang onto my reluctance. We'd keep the {00,01,10,11} in the logic gate but their Input Condition meaning would be F; T; F-AND-T; F-OR-T.

Incidentally, this is much easier to talk about too: False, True, FandT and ForT.

I don't think this is much easier to talk about. For me, internally, { 00, 01, 10, 11 } is fine. I just needed to make sure that we had the same understanding. The one word descriptions you've done for output assertions is good, why don't we have the same for input conditions? With those, we can just describe precisely what they would mean when selected in the UI. Internally, or for developers, we can just use { 00, 01, 10, 11 } and describe how they should work.

Ah okay, I finally see the source of the inconsistency on my end. We have simple 'IN EFFECT' and 'APPLICABLE' sifting that occurs out on the RR network, but then I've been the one hanging onto 'APPLICABLE' in RT. The process there is slightly more complicate sifting the Input Conditions of the logic gates. Mea culpa! ¯_(ツ)_/¯

Here's the way that I've internalized this process. There are three "phases": IN EFFECT, APPLICABLE, and INVOKE. The INVOKE phase is "running the program". The other two are "inspecting the program and acting on inferences".

"Running the program" is done by an "interpreter" of the rules expressions. In my mind, XA-RT is that interpreter. All it does it "run programs". "Running the program" (aka INVOKE) means to accept an is.xa (in "raw" form), derive a sieve.xa (which is equivalent to is.xa when there are no lookup.xa), and respond with ought.xa.

The role of XA-RR is to perform the first two "phases". Effectively, that means to accept an is.xa (the same one that would be sent to XA-RT) and respond with an ought.xa that contains "which rules ought to be invoked". How an XA-RR accomplishes this "sifting" of rules is, from a specification perspective, "undefined".

Our reference implementation of XA-RR will use XA-RT to perform the "sifting" because it's our opinion that "sifting" is also a form of IS-OUGHT logic. We would recommend that other XA-RR implementations do the same because that makes good sense as a factoring exercise.

In our reference implementation, this entire process would be "fronted" by a "client library" that performs the entire three phases transparently to the user of the library (an "integrating" application). This library would:

Accept an is.xa
Perform the IN EFFECT and APPLICABLE process against a configured XA-RR
Receive the ought.xa back from XA-RR containing the rules
For each of the rules received, send the original is.xa to XA-RT and receive an ought.xa
Collate a final ought.xa based on each ought.xa received
Respond with the final, collated ought.xa

We can't call this "client library" XA-RT or XA-RR because it's an artifact of our reference implementation. That is: "we've done our implementation of XA-RT and XA-RR and this is how you use it". Depending on how other implementations want to integrate in their context, they may do something different.

I understand that it feels like this "client library of the reference implementation" should be assigned to one of the roles (XA-RT, XA-RR, XA-RM) that we've defined and therefore, you've been kind of chasing which it is. But, like I said in the previous paragraph, I think that the how of this "client library" will change depending on the integration. We don't need to define it as a role because it's merely mechanical - it's how the implementor decides to combine the critical roles that we've designed.

RE: "The one word descriptions you've done for output assertions is good, why don't we have the same for input conditions?"

Oh, how about this! Dialetheism: "A dialetheia is a sentence, A, such that both it and its negation, ¬A, are true. If falsity is assumed to be the truth of negation, a dialetheia is a sentence which is both true and false." https://plato.stanford.edu/entries/dialetheism/

I wonder if, since this term is exactly the right word to use, we might just go ahead and use it with a formal source reference. Of couse, if we see DIAletheism, there must be a MONOletheism. This is even less common but it is exactly ti https://en.wiktionary.org/wiki/monoletheism

That would give us:

FALSE TRUE DIALETHEIA MONOLETHEIA

We can't call this "client library" XA-RT or XA-RR because it's an artifact of our reference implementation.

Alternatively, this entire process is XA-RT and the "interpreter" is our own internal implementation of a "thing that receives in.xa and responds with ought.xa". We could call it "the rule invoker" (XA-RI). XA-RI would be a specified shared role used by XA-RT and XA-RR. In this way, we're specifying that "there should exist an invoker as part of a conforming implementation".

FALSE TRUE DIALETHEIA MONOLETHEIA

I hope you're not serious. ;-) I can't imagine that XA-RM users will have the necessary formal logic to understand.

Well, I'm at least onto something: https://philpapers.org/archive/SIRCTA-2.pdf

Heck, I'm gonna mark 00:00:01 2020-01-01 as the precise bifurcation point at which began "The Age of Dialetheism".

FWIW, Hegel's use of the term "dialectic" referred to the "process of resolving or merging contradictions" And, well, heeere's Scotty selling refined dialethia crystals via Shopify!!

But suppose we employ these

00_________F_________False

01_________T_________True

10_________T∧F_______True AND False

11_________T∨F_______True OR False

RE: "RuleTaker is that interpreter. All it does it "run programs"."

Then, initially I thought...

Suppose the [is.xa] specification documents the API for data provided by the substrate application to the user's local Subset RR instance, which is configured with a destination RT instance for the [ought1.xa] responses.

But this would be bad.

In order to pre-empt abusive directing of [ought1.xa] responses, the specification will need to require that [ought1.xa] responses MUST ONLY go to the same RT instances that provided the origination [is.xa] requests. So there's got to be a matching hash or something before RT will accept an [ought1.xa] message.

So, RT has to also handle reasonably secure messsaging.

RE: "The INVOKE phase is "running the program"."

No, it's one step less than that. Only the substrate application can run the program. RT is still just sifting to find out what parts of the program are to be run.

In order to pre-empt abusive directing of [ought1.xa] responses, the specification will need to require that [ought1.xa] responses MUST ONLY go to the same RT instances that provided the origination [is.xa] requests. So there's got to be a matching hash or something before RT will accept an [ought1.xa] message.

Yes. But this depends on the implementation. The reference implementation will start by assuming that the "triad" is all local. With no off-machine processing, this dimension can be assessed independently.

No, it's one step less than that. Only the substrate application can run the program. RT is still just sifting to find out what parts of the program are to be run.

I suspect this is false in the definition I used for "running the program". I think you mean "acting on the oughts". In this case, yes, the substrate runs this program. When I say "running the program", I mean the INVOKE phase which uses rule(s) to (effectively) transform is.xa into ought.xa. If we expect that the substrate program performs this operation, then what's the point of XA-RT ("the interpreter" in my comments)?

If it helps, translate "running the program" in my comment to "interpreting the rule.xa to produce oughts".

RE: ""interpreting the rule.xa to produce oughts""

Agreed. I knew that you knew this.

What do you think of this?

_There are three "phases": IN EFFECT, APPLICABLE, and INVOKE. The first two are sifting data to remove irrelevant rows from view; the third is sifting to remove irrelevant columns from view. _

What do you think of this?

It's ok. Note though that the rows that are removed are from a different table (a set of rules) than the table where the columns are removed (a set of scenarios).

Agreed. I knew that you knew this.

I do. But calling whatever the substrate might do as "running the program" is a somewhat distracting conversation.

We honestly don't know what they're going to do with the oughts. They might just save it and do nothing else. What we're handing them back is more like the parameters to their program. They have a generalized set of conditions most likely oriented around the shared schema represented in is.xa. To make this more specific: They are an accounting program that understands "invoices". We don't understand "invoices" - at all. We're telling them what they "ought to do" with an abstraction they sent us.

They are "running a program", but us even talking about whatever they might be doing is rather pointless, because we just don't care what they're doing. So, from my perspective, there is only one "program" we're interested in: the transform of abstraction to other abstraction (is.xa to ought.xa).

We agree on the essence here, I just want to distinguish what we have here from everyone else's inclination for end-to-end automation.

From the core paper:

The result is a simple deterministic structure:

GIVEN context data; WHEN particular data also appears; THEN certain output statements are retained.

Oughtomation incorporates no ‘decisions’, it only relays normative data, including test results, so that end-users can make more informed decisions, and optionally can automate them. Our “human-centred design” (Mitchell, 1996) orientation ensures that decisions remain with end-user human agents in the rule-maker and rule-taker roles.

RE: "It's ok. Note though that..."

Each time a substrate application provides an [is.xa] message to an RT instance, three processes are run: IN EFFECT, APPLICABLE, and INVOKE. The first two processes sift data to remove irrelevant rows from the persistent RuleReserve table; the third is sifting to remove irrelevant columns from transient [ought1.xa] table.

To remove columns, RT re-uses its original [is.xa] message as a [sieve.xa], and this may involve completing some of the statements from [lookup.xa] sources. How an XA-RR accomplishes this "sifting" of rules is, from a specification perspective, "undefined".

REMOVED: [I am not sure that "How an XA-RR accomplishes this "sifting" of rules [should be] from a specification perspective, "undefined". Why would it be undefined? Why not just have a way in the spec, and allow for "any result-equivalent method". At least there well be a specified result to mimic.]

Reflecting on this, I remembered that the purpose of the reference implementations it to show some exmamples of "how". The oughtomation specification should just identify the input/output.

So I suggest it's better to say: "How an XA-RR accomplishes this is outside the specification, however workable methods are demonstrated in the reference implementations."

Coherent?

Excerpt...

The oughtomation method brings to distributed networks the same general purpose function that Richard Morley’s programmable logic controller (PLC) method of the 1960s supplied to individual machines:

[input data] → [logic gate] → [output data] (Brown, 2015) (Amin & Mridha, 2020)

Until now PLC has been implemented for known classes of agents, scenarios and rule sequences that can be implemented in individual, cascading series and parallel multiplexed configurations. Typically I/O programming of PLC logic is done in an imperative style with tightly integrated data, logic and procedure: rules-as-code.

Oughtomation is designed for the uncertainty of open self-organizing distributed networks comprised of unlimited agent types, partially unknown scenarios, and externally defined rule structures and sequences. For such a PLC variant to work it is essential to unbundle data, logic and procedure, and to generate each special-purpose I/O logic table in a consistent platform-agnostic tabular declarative form: rules-as-data.

[transient input data] ↘

	[sift1 metadata] → [sift2 classification] → [sift3 logic gate] → [output data]

[persistent input data] ↗

RE: "Alternatively, this entire process is XA-RT and the "interpreter" is our own internal implementation of a "thing that receives in.xa and responds with ought.xa". We could call it "the rule invoker" (XA-RI). XA-RI would be a specified shared role used by XA-RT and XA-RR. In this way, we're specifying that "there should exist an invoker as part of a conforming implementation"."

Sorry, I was rabbitholing on Dialetheism around the time of this comment and missed it.

At this point we should redraw general schematic diagram. Let me try with simple text...

PHILOSOPHICAL VIEW

      [IS]  ↘ 
	     [GIVEN]  →  [WHEN]  →  [THEN]  →  [OUGHT] 
     [RULE] ↗

SEMANTIC VIEW

[EVENT DATA]  ↘
 
	      [RULES IN EFFECT]  →  [APPLICABLE RULES]  →  [INVOKED RULES]  →  [ACTION] 

[RULES] ↗

FUNCTIONAL VIEW

 [transient input data] ↘ 

		      [sift1 metadata] → [sift2 classification] → [sift3 logic gate] → [output data] 

[persistent input data] ↗

COMPONENT VIEW

  [Substrate Application] ↘ 

	  	      [BoundarySieve] → [ClassificationSieve] → [LogicSieve] → [RuleTaker] 

   [RuleReserve Network]  ↗

             ↑

  [RuleMaker Application]