The Rule of Order Part I

Markov Algorithms as a Policy Programming ModelPart I
2013Q1
The Rule of Order
PROGRAMMING POLICY ENFORCEMENT Business and Government Regulations

An Occasional Paper
Copyright 2012-13, David M. Sherr 1 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET Annals of a Running Dog
2013Q1
Contents
Motivation: Verification of Policy Suites Derived from Government and Business Regulations ................. 3 Part I: Prologue on Cultural Context ........................................................................................................... 4 Part I: IntroductionFirst Principles ........................................................................................................... 8 Markov Algorithm ................................................................................................................................... 8 Whats in a name? .............................................................................................................................. 8 The Dijkstra Guarded Command ........................................................................................................... 17 Syntax ............................................................................................................................................... 17 Part I: The Sherr<Guarded Command> ..................................................................................................... 19 Guarded Commands ............................................................................................................................. 20 Service Points and Provable Reference Behavior .................................................................................. 21 Design by Contract: Pre-, Post-, Invariant Conditions ....................................................................... 22 The Guard ............................................................................................................................................. 26 Descending into the weeds ............................................................................................................... 27 Bridging to the practical .................................................................................................................... 28 Policy Constructs ............................................................................................................................... 28 Implementing XACML Data Flow ...................................................................................................... 29 The Command ....................................................................................................................................... 32 Tying back to Service Point and State Change .................................................................................. 32 Part I: ConclusionBridge to Part II.......................................................................................................... 34
Copyright 2012-13, David M. Sherr 2 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET
Annals of a Running Dog
2013Q1
Motivation: Verification of Policy Suites Derived from Government and Business Regulations
Call this the Law of order at both the macro and micro levels. Each Policy Suite is focused on controlling a small, coherent subset of Business Rules/Regulations. Developing the Policy Suites is, as of now, very much an art form. As we will see in Part II of this paper, we can find tutorial use cases that help guide that artful process. In one of the Part II use cases, we will look at an important financial service business process, viz., Open Account, and how to identify the enforcement points for policies that ensure compliance with the Gramm-Leach-Bliley Act privacy requirements. The useful point to all the formalism contained herein is to be disciplined and precise. That is, disciplined and precise enough to be able to make and prove assertions about Policy Suites that represent Government and Business Regulation. The approach is akin to constructing Complete Axiomatic Systems wherein we can know exactly what is true and what is not. The Gramm-Leach-Bliley Act (GLBA) from 1999 replaced the Glass-Steagall Act of 1933 and that deregulation is largely blamed as setting the stage for the Financial Crises of 2008. GLBA also has rules to protect the disclosure of Non Public Information (e.g. Name, Address, SSN, Age, and Account Numbers in various combinations) during the execution of financial processes. The Sarbannes-Oxley Act of 2002 (affectionately referred to as SOX) concerns regulation of accounting practices and how business processes are implemented. Additionally, it specifies who can and cannot perform various roles within those processes. This set of regulations resulted from the several highly impactful accounting fraud collapses at the turn of the Millennium (Enron, WorldCom, Tyco and Adelphia, most notably). The Dodd-Frank Wall Street Reform and Consumer Protection Act of 2010 is the latest set of regulations. Dodd-Frank contains rules on financial transactions that are currently highly automated or will be in order to comply most efficiently. It is the Dodd-Frank regulations that will force many financial institutions to remediate automated systems across many asset categories end to end, from underwriting to high frequency trading to back office processing. The approach here can be highly impactful for both efficiency and effectiveness. Many regulations can be conflicting and therefore require some deep verification of their consistency. And this must be done in an easy-to-use fashion that helps hide the technical complexity of such tasks. The ultimate objective is the Part III white paper entitled, Codification of Core Dodd-Frank Concepts. This paper and subsequent Parts II and III are a candidate for an open, transparent regime that implements Policy Enforcement. This effort is seen as leading to a capability to model and control transactions within varying Sovereign Jurisdictions for the purpose of finding efficient venues. Copyright 2012-13, David M. Sherr 3 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET Annals of a Running Dog
2013Q1
Part I: Prologue on Cultural Context
Think like a Machine.
The Borg looms,
and We become Part of the Machine.
2013Q1
Accelerating since the 60s, we have been washed in this meme of the techno-culture of Machine-Space: 2001, A Space Odyssey
Star Trek,
And, Star Wars
2013Q1
Man and machine are tightly integrating in and into the collective psyche. It is even more so today. How many can resist the Smart Phone message alert Ding!? And, of course, we have the current producer generations version of the Man-Machine Meme
Neo Does the Matrix.
In the end, it is all Neology (neo: new, logos: word); making new language. Copyright 2012-13, David M. Sherr 6 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET Annals of a Running Dog
2013Q1
It is with the above attitude in context of World Asset Exchange, Mobile Wallets and Social Media that we consider the audit of the critical functions of social/economic/financial activity: Monitor, Alert, and, Report and Remediate. But, can we adequately comply with all these new and old rules and regulations? As Jethro Tull sings, Aiming high where the eagle circles, Where he keeps his tail feathers clean, And he wonders Am I still a free bird? Or, just part of the machine. [emphasis added]
Popular techno-culture like the Tablet, Smart Phone and Social Media allow and deliver us extremely intimate experiences with economic transactions and relationships. We need a new economic theory of not macro-, not micro-, or not even nano-, but of pico-economic transactions. This is the Singularity that Kurzweil speaks of He is now Director of Engineering at Google who also employs Vin Cerf, a Founding Father of the Internet, and Hal Varian, Founder of the School of Information at Haas Business School of Cal Berkeley. Google is, indeed, a great candidate for the Borg. (Resistance is futile. You will be assimilated.)
What are pico-economic transactions? We offer a personal example. The maintenance cost for a set of six grid computing server images at an Amazon Web Services (AWS) account is $0.15 per monththe cost of a few sticks of gum charged to a credit card. AWS has had two price reductions of 20% and 25% over the past three years. Is the next one a 33% drop to $0.10? Computing is being commodity priced, if not commoditized. This is the Grail of Cloud. That is to say, the quest is for workloads to become interchangeable across differing Cloud providers. We are in a market of walled gardens at the moment. At the moment, web service dispatch via apis and virtualization is as close as we get. Of course, as with all businesses, the telecom/hardware/software/service providers wish to create walled gardens. This seems inevitable as it is the most sustainable profit modelwitness Apple as a not so modest example with the highest Market Capitalization (albeit dipping to #2 at this writing) of any equity stock in the World.
It is in this cultural and business context/milieu that we consider a new policy programming model. To be truly effective, policy development, management and enforcement need to be turbocharged with automation. Such an approach is offered here. It is the Singularity to come. Copyright 2012-13, David M. Sherr 7 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET Annals of a Running Dog
2013Q1
Part I: IntroductionFirst Principles

Mathematician Andrey A. Markovs 100-year old work is seminal in the area of statistical computing Markov Chains. He also delved into the nature of algorithm in the domain of Alan Turing and John von Neuman. Taking it from the top from First Principles, on Wikipedia, we have a very straightforward definition of Markov Algorithm:
Markov Algorithm
The Rules is a sequence of pair of strings, usually presented in the form of pattern replacement. Some rules may be terminating. Given an input string: 1. Check the Rules in order from top to bottom to see whether any of the patterns can be found in the input string. 2. If none is found, the algorithm stops. 3. If one (or more) is found, use the first of them to replace the leftmost matching text in the input string with its replacement. 4. If the applied rule was a terminating one, the algorithm stops. 5. Return to step 1 and carry on.
The important aspect of these algorithms is that they are Turing Complete, i.e., capable of representing any computation.
Whats in a name?
Juliet: "What's in a name? That which we call a rose By any other name would smell as sweet." Romeo and Juliet (II, ii, 1-2)
Juliet spoke this as she reveled in the thought of Romeo and his being of the House of Montague that was a blood enemy of her House of Capulet. As we will see below, there is plenty in a name. Alfred Korzybski, the Father of General Semantics would ask the question, Would you eat honey if it were called bee vomit? Without getting caught up in a human psychological discussion of words and names specifically, lets examine the phonetic construction in the question Whats in a name? We turn to the Soundex Coding, Patented 1918/1922. It was used for Analyzing the 1880-1939 Censuses.
2013Q1
Experience Soundex coding. Try this 1997 Genealogy Web Service url with a last name, e.g., Sherr using Figure 1 below. Figure 1: Description of the Soundex Coding Scheme
Invocation through the Web Interface Form produces results of Sherr S600 as in Figure 2 below Figure 2: Soundex Coding Scheme Applied to Sherr
Notice the form of the url request (we are talking a ReSTful invocation): http://searches.rootsweb.ancestry.com/cgi-bin/Genea/soundex.sh?Sherr Click on the link and produce the page up above. If you embed the request in code, issue the request over an IPaddr:80 and intercept the html response from that port, and parse it, you now have legacy wrapped a function from 1996 by using a scripting language like python, php, perl, etc. with some modern api infrastructure (apigee, mashery, Layer 7, etc.) to orchestrate the request/response. In this Copyright 2012-13, David M. Sherr 9 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET Annals of a Running Dog
2013Q1
case, the process is synchronous, but does not have to be using ReST. This is a protocol implementation made Simple. Not bad for a Web Service that is 16 years old. The complexity arises as we focus on performance. But, it is dynamic binding that makes it all work seamlessly.
Specifics for Implementing Soundex, Please [This section presents my thinking about the details of implementation. The discussion below shows the development of the solution in two versionsTable 1 and Table 5, the almost correct solution and the corrected solution, resp. To be honest, I try to keep it simple, because simple is hard enough. The two tables depict the solution creation process. They are the order in which yours truly understood the transformation. Hoping that this is instructive of how one may come to an understanding as opposed to just the final state. It is called learning to learn. It is meta*] Remember from above that the Markov Algorithm rule is of the form:
pattern replacement
The Soundex coding scheme above then looks like Table 1 below. Let the Subject String = <surname> and use regular expression recognition semantics for patterning and rewriting replacements. Note (a) that if no rule applies we stop, (b) that pattern recognition is caseless on the alphabet, and, (c) that the recognition is context sensitive. Using Rule 1 below in Table 1, as a reminder to those fuzzy on regular expressions, in the pattern on the Subject String to be Soundex Coded, ^ and $ denote the beginning and ending context anchors of a string, resp. [.] denotes a string of exactly one character. [.*] provides a context meaning any string, including the null string. That provided context is around [BPVF] which denotes any one of the set of B, P, V, and F which is to be rewritten as 1 as per the replacement string. In the replacement, ?1 denotes the first substring recognized by the pattern, ?2 the second, $4 the fourth, etc. A closer to English translation of Rule 1 is If a match of any 1st character, followed by a string of any length (including 0), followed by one character of BPVF, followed by a string of any length including the rest of the characters in the Subject String; then, replace it with the 1st substring (1 character), followed by the 2nd substring, followed by a 1, and then followed by the 4th substring. The [ ] groupings represent the sequence of substrings ( ?1, ?2, $3, $4, etc.) recognized in the pattern.

Here is the whole ball of wax. Table 1: A Markov Algorithm for Standard American Soundex Rule 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Pattern ^[.][.*][BPFV][.*]$ ^[.][.*] [CSGJKQXZ][.*]$ ^[.][.*] [DT][.*]$ ^[.][.*] [L][.*]$ ^[.][.*][MN][.*]$ ^[.][.*] [R][.*]$ ^[.][.*] 11[.*]$ ^[.][.*]22[.*]$ ^[.][.*]33[.*]$ ^[.][.*]44.*]$ ^[.][.*]55[.*]$ ^[.][.*]66[.*]$ ^[BPFV]1[.*]$ ^[CSGJKQXZ]2[.*]$ ^[DT]3[.*]$ ^[.][L]4[.*]$ ^[.][MN]5[.*]$ ^[.][R]6[.*]$ ^[.][.*][AEIOUYHW][.*]$ ^[.]$ ^[..]$ ^[]$ Replacement ?1?21?4 ?1?22?4 ?1?23?4 ?1?24?4 ?1?25?4 ?1?26?4 ?1?21?3 ?1?22?3 ?1?23?3 ?1?24?3 ?1?25?3 ?1?26?3 ?1?2 ?1?2 ?1?2 ?1?2 ?1?2 ?1?2 ?1?2?4 $1000 $100 $10
Closed lip explosive Open mouth explosive breath Open mouth, tongue on palate Open mouth, tongue touches palate
2013Q1
Comment
Explosive, lip to open mouth (M), open mouth, tongue on palate (N) Open mouth, explosive Remove internal sequences of same numbers
Remove prefix sequences of same numbers
Remove vowels and vowel-like letters, retaining first letter Assure exactly four characters remain, suffixing with 0s to fill out
Truncate to exactly four characters 23 ^[.]..*$ $1 In the above Table 1, there are six phases to this algorithm as summarized in Table 2 below. The phases will be applied in the order they appear in the list of Table 1.
This is because, in Markov Algorithms, the list of rules, by definition, is searched top to bottom until one applies to be executed, the process then returning to the top. The Algorithm stops when no rule applies or it is explicitly stopped with a HALT.

Table 2: Phases of a Markov Algorithm for Standard American Soundex Phase I II III IV V VI Table 1 Rule #s 1-6 7-12 13-18 19 20-22 23 Description
2013Q1
Map each consonant to one of six audible categories Remove adjacent like categories internally Remove adjacent like categories at the front Remove all vowels and vowel-like letters Normalize to exactly four characters Truncate to exactly four characters
Lets apply the Soundex Algorithm of Table 1 to the <surname> = Sherr which is detailed in Table 3. Table 3: Application to Sherr of Markov Algorithm for Standard American Soundex Iteration 0 1 2 3 4 5 6 7 Subject String Sherr She6r She66 She6 Se6 S6 S600 HALT Table 1:6 Table 1:6 Table 1:12 Table 1:19 Table 1:19 Table 1:21 Table 1:End Rule Used Comment
One of the fine points of Soundex is the way it eliminates sequences of similar consonants as with the rr from Sherr above. One needs follow the description of Soundex as in Figure 1 which is as not obvious as it appears. The order of the rules for consonants and vowels must be followed as is. Otherwise, if Rule 19 in Table 1 above were applied first, then a German variant on Sherr as Scherrer becomes H600 instead of H660 in Table 4 below. Soundex aspires to retain the distinction of syllables. Sherr is one syllable. Scherrer is two. Speaking of subtle complexity, it should be noted that the Table 1 Algorithm was corrected twice by the author to accommodate this aspectfirst from 17 to 23 rules and to 30. It requires a trick of phase markers to defer Rule 19 until after all the consonant transforms have been completed. This means a slight rework of Table 1 to explicitly add the Phases I-VI of Table 2 to the algorithm. Copyright 2012-13, David M. Sherr 12 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET Annals of a Running Dog

Table 4 shows what is wrong with the algorithm of Table 1. Table 4: Application to Scherrer of Table 1 (wrong!). Iteration 0 1 2 3 4 5 6 7 8 9 10 11 12 Subject String Scherrer S2herrer S2he6rer S2he66er S2he66e6 S2he6e6 She6e6 Se6e6 S6e6 S66 S6 S600 HALT Table 1:2 Table 1:6 Table 1:6 Table 1:6 Table 1:12 Table 1:14 Table 1:19 Table 1:19 Table 1:19 Table 1:12 Table 1:21 Table 1:End Rule Used
2013Q1
Comment
Oops, need to prevent this!
Table 5 below is the Phase-Markers-Added to Table 1 algorithm using #<= as the Phase Markers (# invokes Table 1 Rules 1-18; < invokes Rule 19; and, = invokes Rules 20-23all Table 1 rules. Rules 0, 18 and 19 are meta-rules for the sequencing of phases). To remind the reader of regular expression semantics, although ^ denotes the beginning of the Subject String when it appears in the beginning of an expressi on, when it appears after a [, it signifies that none of the characters following until the closing ] are recognized, but all others are. Rule 0 in Table 5 then translates into English as If the 1st character is not # and is not < and is not = (n amely, it is an alphabetic character) then append # to the front of the Subject String parsed into the 1 st character as a substring, followed by the a substring of the 2nd-last characters of the Subject String. NB: Rule 0 then is ignored for the rest of the Soundex Coding processing. The third phase marker, =, is stripped off at the very end in Rule 24 AND the algorithm stops.

Table 5: A Correct Markov Algorithm for Standard American Soundex Rule 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 18 19 19 20 21 22 23 24 Pattern ^[^#<=][.*]$ ^#[.][.*][BPFV][.*]$ ^#[.][.*] [CSGJKQXZ][.*]$ ^#[.][.*] [DT][.*]$ ^#[.][.*] [L][.*]$ ^[#.][.*][MN][.*]$ ^#[.][.*] [R][.*]$ ^#[.][.*] 11[.*]$ ^#[.][.*]22[.*]$ ^#[.][.*]33[.*]$ ^#[.][.*]44[.*]$ ^#[.][.*]55[.*]$ ^#[.][.*]66[.*]$ ^#[BPFV]1[.*]$ ^#[CSGJKQXZ]2[.*]$ ^#[DT][3[.*]$ ^#[.][L]4[.*]$ ^#[.][MN]5[.*]$ ^#[.][R]6[.*]$ ^#[.*] ^<[.][.*][AEIOUYHW][.*]$ ^<[.*] ^=[.]$ ^=[..]$ ^=[]$ ^=[.]..*$ ^=[.*] Replacement #?1?2 #?1?21?4 #?1?22?4 #?1?23?4 #?1?24?4 #?1?25?4 #?1?26?4 #?1?21?3 #?1?22?3 #?1?23?3 #?1?24?3 #?1?25?3 #?1?26?3 #?1?2 #?1?2 #?1?2 #?1?2 #?1?2 #?1?2 <?1 <?1?2?4 =?1 =?1000 =?100 =?10 =?1 ?1; HALT Comment
Append Phase Marker to Subject String Closed lip explosive Open mouth explosive breath Open mouth, tongue on palate Open mouth, tongue touches palate
2013Q1
Explosive, lip to open mouth (M), open mouth, tongue on palate (N) Open mouth, explosive Remove internal sequences of same numbers
Remove prefix sequences of same numbers
Next Phase for vowel removal Remove vowels and vowel-like letters, retaining first letter Next Phase to adjust to 4 characters if length < 4 Assure exactly four characters remain, suffixing with 0s to fill out
Truncate to exactly four characters Remove = Phase Marker, if HALT were not here, would loop on Rule 0 and this Rule

Now for running though the corrected algorithm for Scherrer turn to Table 6 below: Table 6: Application to Scherrer of Table 5 (correct!). Iteration 0 1 2 3 4 6 7 8 9 10 11 12 13 14 15 Subject String Scherrer #Scherrer #S2herrer #S2he6rer #S2he66er #S2he66e6 #S2he6e6 #She6e6 <She6e6 <Se6e6 <S6e6 <S66 =S66 =S660 S660 Table 5:0 Table 5:2 Table 5:6 Table 5:6 Table 5:6 Table 5:12 Table 5:14 Table 5:18 Table 5:19 Table 5:19 Table 5:19 Table 5:19 Table 5:22 Table 5:24 Rule Used Comment
2013Q1
Begin first phase with # marker
S2 treated as a double category Consonants handled, on to vowels
Vowels finished with, handle string length HALT
To finish the exploration of Soundex, consider the fine point of H as a syllable delimiter. For example, a name like Lochson should see the c and s not collapsed into one sound as with the S and c in Scherrer above. Keeping ancestry.com as the Soundex Reference Service: Figure 4: Soundex Code for Lochson

Apply Table 5 to Lochson as detailed in Table 7 Table 7: Application to Lochson of Table 5 (correct!). Iteration 0 1 2 3 4 6 7 8 9 10 11 Subject String Lochson #Lochson #Lo2hson #Lo2h2on #Lo2h2o5 < Lo2h2o5 <L2h2o5 <L22o5 <L225 =L225 L225 Table 5:0 Table 5:2 Table 5:2 Table 5:5 Table 5:18 Table 5:19 Table 5:19 Table 5:19 Table 5:19 Table 5:24 HALT Rule Used
2013Q1
Comment Begin first phase with # marker
Consonants handled, on to vowels
As a final note, notice that this set of names {Sherr, Scherrer, Lochson} forms a test set of any Soundex Implementation. Are there any others that test the capability of an algorithm to produce correct results? This is left as an exercise for the interested (if you have made it this far) reader.
The previous discussion is very nice for a course in Computability abstract and almost trivial. The next section drives the thinking closer to practical usability.
2013Q1
The Dijkstra Guarded Command

Guarded Commands of Dijkstra from Wikipedia offers a similar pattern as for Markov Algorithms for computation. The Dijkstra Guarded Command offers an if-then-else(-else)*fi structure around the differing Rules which are not abstract string rewrites, but traditional executable statements in some programming language. Syntax
if G0 | G1 ... | Gn fi Sn S0 S1
This structure too has the merit of being Turing Complete. Without boring unduly, one can prove these two representations equivalent. This also is left for the interested reader. guard statement] [Hint: The form of pattern replacement is rendered
The general Guard, Gi, is a complex logical statement that evaluates True or False. If Gi is True then the statement Si is executed and the Guard is satisfied. If no Guard G i is True, nothing happens. Assuming top-down, left-right evaluation, then we can see the parallel to Markov rewrite rules. Spoiler alert on Guarded Command-Markov Algorithm equivalence! To convert a Dijkstra (Soundex code = D236) Guard into an equivalent Markov Algorithm, we need only embed the patterned rules into the pseudo-code below which implements the looping execution of the Markov Algorithm:
_Exec = 1; while( _Exec == 1 ) if G0 | G1 | Gn fi S0; S1; ... Sn; | _Exec = 0;
2013Q1
NB: Any compound Si can include a statement _Exec = 0; as a Halt indicator.
The next section dives down into great detail on the structure and process of Policy Sets. These sets are the basis of Policy Based Specifications that are computationally complete. Policy Sets are useful in implementing Policy Enforcement Points for any automated interaction. With High Frequency Trading accounting for roughly 60% of volume and the emerging Dodd-Frank regulations, automated policy enforcement appears to be the only option. Thus, a disciplined regimen for definition, design, debugging, deployment and deprecation of Policy Sets is needed. Lets begin with the first step below.
2013Q1
Part I: The Sherr<Guarded Command>

The Summary Slide below is how Guarded Command is summarized in the Sherr Lean thinking in a context of Policy Management and Enforcement (represented in Backus-Naur Form (BNF):
This certainly has a European bias: Lean Implementation, Niklaus Wirth (Swiss), Guarded Commands, Edgers Dijkstra (Dutch), Programming by Contract, Bertrand Meyer (French). Of course, we have to add to this list Tim Berners-Lee (British) who developed the http protocol at CERN in Geneva. All these developments were 1968-90. It is Old Time Object Orientation and Service Programming from the European Academic Masters. Just because something is old, doesnt mean it is obsolete, especially with ideas. In fact, being Old means it has survived the test of time. Many times with New things , it is old wine in new bottles. The recent popularity of Python is a case in point. Python is Lisp (the original language for AI) without all those annoying parentheses. The Library construct of Python is content addressable memory and was a central feature of arrays in awk, the C-like pattern matching language of unix. And so, we turn our attention to First Principles as we provide very old ideas (Turing Computability, Markov Algorithms, Guarded Commands, Design by Contract, and Lean Programming) within a new container called The Sherr Guarded Command for Policy Management and Enforcement. Ideas are the ultimate reusable resource. In the spirit of taking it from the top, Wirths Law, Software gets slower than hardware gets faster, drives us to First Principles rather than layering more complexity on a morass of complexity. So, lets conceptualize operating as an appliance, that is, either hardware of software appliance. The value-add with the Sherr Guarded Command is the simplification of programming Policy Enforcement. This Policy Enforcement works in service oriented, distributed, time-displaced computing, that is, in the current and coming World of Cloud. Moreover, there is an almost fanatical clinging to the stateless processing in the http communications. The ostensible reason is to make processing asynchronous. But, state matters and must be accommodated as in ReST Architecture. This is done through Context preservation, augmentation and use. Copyright 2012-13, David M. Sherr 19 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET Annals of a Running Dog
2013Q1
Guarded Commands
Recall Rule 0 from the Table 5 Soundex Algorithm as an example of a Guarded Command which is abstractly, a specification of a state machine transition: Rule 0 Pattern (Guard) ^[^#<=][.*]$ Replacement (Command) #?1?2 Comment
Append Phase Marker to input string
The semantics of patterned rules are very precise and, literally, programmatic. The Markov idea of an ordered table of rules is simple. What is complex is controlling the execution of those rules. For many use cases of algorithm implementation, this sequence of construction works: Write the rules as Guarded Commands, order them, and supply the Context within which they are invoked. In the case of this discussion using Regular Expressions as the heart of Guard, context sensitivity is supplied by the immediate Context string anchors (^ and $) and the substrings (denoted by [ ] expressions) surrounding the Content character(s) to be replaced by the Command. In detail, how does Rule 0 work as the start of American Soundex implementation in Table 5? Recall, as part of correcting the error of Table 1, we needed to assure that certain rules would be skipped after some point. Since the scan of the rule list is always top-to-bottom, we used a context signifier ( [#<=] ) to stage the execution of the sublists of rules into the three sequenced groups of application (the Beginning, the Middle, and the End). The solution was to build the three phases into the rules. The phases are enforced by special context markers, namely, # as the Beginning phase that handles all consonant transformation, < as the Middle phase that handles vowel removal and syllable separations, and, = as the End phase that normalizes the final string to exactly four characters.
In the Specifics of Implementation section, we saw (a) some of the semantics of Posix Extended Regular Expressions by explanation and (b) the parallel association with the semi-formatted set of rules articulated in the English Description from the ancestry.com description. Here we take a deeper dive into the nuances of Regular Expressions and Markov Algorithms to the end of sequencing context for the algorithm. The interpretation of Rule 0 is simple: Begin the Soundex Coding on a Content Subject String (e.g. Sherr).
2013Q1
More precisely, deconstruct Rule 0, noting that algorithmic processing operates transparently to the background Context, viz., the formatting or location of the data: Context A string sits in a memory cache that is implementable in a number of ways Direct (PROM, DRAM, DISK), or, Mediated (Local or Remote Data Service Call), Content Subject String = Sherr Guard The Soundexing Process has not yet begun, signified by none of the three phase markers appearing at the beginning of the Subject String Command Start Phase 1 signified by appending # to the front (left) side of the Subject String Content and Context are a state duality that makes the complete computation (Guard and Command). Fundamentally, it is point of view. Generally, Content is changed directly and internally within the computation. Context is changed indirectly and externally from outside the computation another process Content. Both are required.
Service Points and Provable Reference Behavior

Once defined and compiled into coherent Suites, Policies can be certified that they are meaningful, consistent, and complete to the purpose for which they are fit. The full Context of the Policy life Cycle is depicted in Figure 5 below (NB Certification is done prior to Deployment):
Figure 5: Policy Development; Policy State Life Cycle
2013Q1
As the lower right-hand box indicates, Certification of the Policy Suite is to a Reference Behavior. Thus, the Certification Process depends on being able to Prove the Behavior of the Policy Suite is equivalent to some Reference Behavior. We seek the next level of automation of Search: not just the ability to answer questions (i.e., deliver information), but to draw conclusions (i.e., share knowledge). The details of infrastructure and implementation of specific work-flows for any enterprise are discussed in a paper on Enterprise Policy Development. However, important to this discussion is to note that real value is in Deployment and Operation. Thus, Certification is a level of assurance for which one can establish measureable service levels, and, hence manage the non-compliance risk by the numbers. Design by Contract: Pre-, Post-, Invariant Conditions To talk of proving behavior requires a discussion of the atomic artifact in the current world, Service Request APIs. A Service Request API is satisfied via a Service Point. Service Points are the way functionality is delivered in an asynchronous, distributed World of Cloud. The Command of a Guarded Command contains the invocations of services via Service Points. Service Points are invoked under service level agreements which include the behavioral constraints as a part of their materialization. The following discussion is extracted from a paper delivered in Dec 2003 to the OECD on Measuring Electronic Business Processes. It is particularly relevant here. Service Point: The Picoeconomic Artifact The Service Point is the central artifact to define and measure. Collections of Service Points yield the Business Services that implement the tasks of Electronic Business Processes. Function Point, Precursor to Service Point In the 70s when writing COBOL/CICS applications, we would measure, a priori, the amount of work in a system development based on a notion called function point. A function point was either a function call or file interface. There was one platform, several mechanisms and a few environments to deal with. Life was relatively simple as there was not a lot of choice of how to implement our systems and IBM provided great engineering information on how to make the operations more efficient and manageable. This is NOT true in todays world of Information and Communications Technologies. Service Point is a further abstraction of Function Point with other capabilities added. There is the idea of both supply and demand with respect to the functionality provided by a Service Point. It is obvious but worthy of noting that economies are primarily governed by supply and demand. If one is to have an effective artifact to measure economies of electronic business processes that use business services, then aspects of both need to be included in the abstraction.

Attributes of Service Points
Figure 6: Relationships of Service Point Attributes
2013Q1
A Service Point supplies: An interface to request the service containing a name and list of parametric variables called the function request signature; A delineation of the data/information needed/provided called the view specification; A semantic specification of constraints on how the functionality is achieved in terms of input state (preconditions), operational state (invariants) and outputs (post conditions)borrowed from the field of object programming, Design by Contractcalled behavior constraints.
This is the functionality defined by the Service Point particularly when a formal business vocabulary exists to support the semantics of the constraints. It defines the computational requirements.
A Service Point needs to deliver on the consumers requirements for Service in terms of Service Level Objectives Operational Times: When is the service required to be enabled and operational Performance: How does the service need to operatee.g., transaction per second, user response times, data capacity and transmission rates Transactional Capability: e.g., Best Efforts, No More Than Once, Once and Only Once, Fire and Forget Security Level: e.g., Public, Client, Partner, Representative, Agent, Administrator Quality of Service Availability: requirement for up-time Reliability: error rates tolerance Flexibility: time to change and test to meet competitive and evolving demands
2013Q1
Implied in this measure is substantial instrumentation, monitoring and operational data gathering and integration. Development of standards and reformation of firm system architectures are required to measure service points. Both are formidable undertakings. All this said doesnt mean we shoul d not encourage it to happen. In fact, we undertake a first step herein. It is essential and necessary for us really to get our arms (do) and heads (think) around the problem of measuring electronic business processes. Behavioral Constraints: Illustration of the Conditions of Service Invocation Looking at Figure 6, lets take a deeper dive on the Meyers Design By Contract Context of Behavioral Constraints on a Service invocation. From the Service Point supplies list above, the third bullet point breaks out Behavioral Constraints (Policy Suites) on application work flow rules. This breakout consists of security controls (identity and access) and compliance rules (e.g., SOX, GLBA, Dodd-Frank or Professional Certification statusboth Role and Action constraints). Table 8 serves as a Summary Example. Consider an Order2Cash work flow order change task under SOX oversight of a physical goods or service provider: Table 8: Behavioral Constraints for an Order2Cash Business Process change_order Task change_order(order_no, delivery_address) Design By Contract Category Precondition Description
Constraints on Input at point and time of Service invocation Constraints on continued operation of Service per invocation Constraints on presentation, format and delivery of Service results Quality of Service Experience
Application
delivery_address Valid && order_no Exists order_no_status is Open
Security
Compliance
Identity is ~order_no( OrderMaker)
Identity Known
Invariant Post Condition Service Level Request
Identity Permitted && Role is OrderMaker
N/A
order_no_status is Changed
N/A
N/A
TXN: OnceOnlyOnce; PERF: RespTime < 3 sec., BeginToEnd < 3 min; AVAIL: AnyTime; SECLEV: Agent
Order2Cash is the basic sale transaction: order, pay [, deliver]. Deliver is a separate process, probably. On SOX controlling any change transaction, the goal is to forbid an OrderMaker from being able to change a delivery address for the receipt of Physical Goods or Services Renderedsimplest fraud
2013Q1
prevention. This rule makes collusion necessary for fraud. Multi-Party Fraud is much, much easier to detect than for a Single Party, since only one party is needed to blow the whistle. The principle is called Segregation of Duties. Different tasks, different people in a value supply chain. [Quick aside: This style of regulation requiring theoretically more people is what the cost is. We argue the necessity of incurring such costs. Regulation is an explicit cost to each party. Deregulation is an implicit cost to the whole system. Deregulation as a policy is always a triumph of hope over experience. It always precipitates the Tragedy of the Commons where benefits are obvious and the costs not. 2008 is a Tragedy of Epic Proportions.] Detailed below, a little more explanation of Table 8 is helpful to describe instrumentation of the life cycle of a Service: The Context Preconditions (Service Birth) allow the change_order Task to proceed: Application is senseless if the delivery address is invalid. Security permits only known Identities to operate. Compliance (SOX) requires segregation of duties.
Once invoked, the Service (Life) continues to operate with the Context Invariant Conditions persisting: The Application status of the Order remains Open since we operate in a multi -tenant, single Authoratative Store environment. The Security status persistence requires that the Identity of the interactor stays valid (think of revocation of a rogue traders privileges) and the Role of the interactor is an OrderMaker (although not the originator of the order_no).
And because of the asynchronous nature of processing, the Context Post Condition (Service Death) is one where the Service doesnt complete until the status of the order is marked as Changed.
By structuring the invocation of Services, we thus can make testable assertions about behavior, before, during and after invocation. So a set of Service Point descriptions at this detail dives the life cycle of policies.
2013Q1
The Guard
And now for 9th Grade English where Miss Bergey, Mennonite Missionary, taught how to parse/diagram sentencesgrammar in action, recognizing syntax. Miss Bergey was a grammatical purist, as pure as pure can be (Dont split infinitives!!cue ruler smackCatholic Nuns had nothing on her), and so are we formally pure here. Think of a <Guard> like the shields of the Star Trek USS Enterprise: Shields Up, Deflecting Attack
In the analogy, the Business is the USS Enterprise and the Sherr<Guarded Command> is the fabric of the shield.
We use Backus-Naur Form (BNF) as a language, the generic structure of which emerges as through explanation of Figure 7 below. Figure 7: Syntactic Definition of Guard
An XACML statement has a set of grammar rules which are intimately associated with specific semantic components around access control.
2013Q1
The Sherr<Guard> is a superset of XACML in that all XACML is acceptable to this definition scheme, but not vice versa. For instance XACML is largely a stateless policy evaluation UNLESS state is explicitly maintained.
Descending into the weeds The advantage of expressing languages in BNF lies in the capabilities of well-developed old tools from unix. These tools can (1) parse BNF (lexcourtesy of Googles Eric Schmidt collaborating in his Berkeley days) and (2) compile lower level code (yacccourtesy of one of the many early small contributors to unix, Stephen Johnson from his Bell Labs days). While GUIs exist for BNF, as we automate and use XML or json style semi-structured data (short of free text), we need machine readable forms of definitions so agents can dynamically create and interpret definitions in real or near-real time. The top level grammar of Figure 7 shows how to construct/deconstruct a well-formed statement in BNF. ::= means is defined as and is the meta-verb per se. <> are the meta-nouns of BNF. Juxtaposition defines concatenation of sequences and | is alternative choices. ~, &&, ||, ==, and => are part of the language being defined and are the logical operators Not, And, Inclusive Or, Equivalent and Implies, resp. ( Vx ) and ( x ) are the logical quantifiers For All and There Exists, resp., statements about sets of {x}, where x is a free variable in the Proposition. Sentential logic (propositional logic) is the simplest of logic that allows us to define assertions regarding the state of the World, where the World includes its Mind (Collective Consciousness) as well. It is concerned with only what can be stated and proven with regard to basic grammatical structure where we construct compound statements using the logical operators, Not, And, Inclusive Or, Equivalent and Implies. For example, (Roses are Red && Violets are Blue) => I love You Another name for Sentential/Propositional Logic is Boolean Algebra. Boolean Algebra contains the First Principles of specification of Circuit Design for all our digital machines. A Law of Computer Science states that all Software can be rendered in Hardware and vice versa. So Logic is at the heart of all automationsoft or hard. Quantification Logic involves quantifying (1) over only members of sets or (2) members of sets and the sets themselves, first-order and second-order, resp. Sentential Logic is zeroth-order logic. Quantification Logic is the logic of processing sets of data to mine information from them. It is the basis of the newly codifying discipline called Data Science. This was just called Data Analysis in the not so old days. Once again, we have old wine in new bottles. Policies make assertions about states and changes in state for sets of data and their internal and external relationships. This is the complexity of second-order logic. Second-order Logic unfortunately suffers the flaw that one cannot, at the same time, be consistent and complete. Consistency means all statements can be modeled togethernamely, there is a possible world where all the rules apply Copyright 2012-13, David M. Sherr 27 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET Annals of a Running Dog
2013Q1
without conflictideal. (Muddled together, however, is how it appears in practice.) Complete means all true statements are provable. We can only find well defined areas in which we can be both consistent and complete. For these areas, we develop policy suites with confidence that automation is completely doable. Bridging to the practical Lets finish the discussion of Figure 7, the BNF definition of <guard>. A <guard> consists of logical statements which can be evaluated to be true or false by the principles presented just above. Evaluation is concerned with materializing the sets of data defined by the <guard> and its constituent parts. Because of the speed of change in systems performance requirements, materialization of data is always behind reality. Thus, real-time or near-time computing is necessary. Also, it is a workable strategy, moving processes to data instead of vice versa. Materialization of data is the impedance. Practically, we need a single source of each policy rule so that we may maintain in one place and then compile to deploy policies in any processing environment. Maintaining different definitions for each environment is a maintenance nightmare and so argues for a common, open definition. [This is The Major Objective for this entire white paper.] But what is the Context of this discussion? Lets take a deeper dive into Policy Constructs. Policy Constructs A first principle is that The Business is controlled with clearly defined policies and rules. Of course, clearly becomes the issue. Common language is The Enabling Capability. The first question is What Components do I need to do End-to-End Policy Management? Figure 8: Components of Policy Definition and Design
2013Q1
Extracted from a detailed discussion, Figure 8 above depicts how Enterprise Intellectual Property in the
form of Business Processes is used to define and select Work Flow Design Patterns and Use Case Policy Templates. And the Templates are used to create deployable AND auditable Operational Components. The discussion below is centered on the key (in Red) Policy architectural components, that is, those components drawn from the standard XACML architecture. Policy Information Point Policy Information is managed through a Policy User Interface that gathers Policy Information from Points of Presence and allows Policy Life Cycle management from Creation through Deprecation of Policies deployed through any Policy Administration Point of Presence. Policy Administration Point Policy Administration Points interface to Policy Repository Services which maintain policies and policy suites: (1) newly defined, (2) extant, and, (3) retired. The Repository supports the Policy Test Workspace which is where newly defined policies are moved through the life cycle maturing to Deployment, Operation, and Monitoring. Policy Decision Point There are Policy Decision Points of Presence which support Policies at the Points of Enforcement within Operational Components. Policy Enforcement Point Policy Enforcement culminates in the Policy Monitor which shadows the System Audit Log. Implementing XACML Data Flow With respect to the Data Flow Diagram on page 17 of the XACML 2.0 Specification (http://tinyurl.com/j73hb), this architecture herein virtualizes the Policy Information Point. We reproduce this diagram below as Figure 9. Its explanation follows. Figure 9: XACML 2.0 Data Flow Diagram
2013Q1
This diagram is heavily infused with knowledge like the Periodic Table of Elements in terms of the story (read knowledge) stored. We engage in Design through Narrative with heavy reliance on use cases that cover all the aspects we wish to impart.
A Story of Access Control contained in Figure 9 is elaborated belowa story of who, what, when, where, how and in many cases, why. The numbered list below corresponds to those in Figure 9. They are the sequence of processing through the XACML semantics. 1. Policy Here we see the Policy Administration Point (PAP) to source the Policy from which Decisions are made during the processing of the access request. 2. Access Request The access requestor interacts with a Policy Enforcement Point, thus beginning a journey through and with all the component entities that deliver GrantAccess. The PEP then turns to the central coordinator, context handler. 3. Request Awakened, the context handler begins to coordinate among the Policy Decision Point and Policy Information Point, extracting Policy attributes from a catalogue of subjects (i.e., topics), target resources for the Policy (set) and embedding environment for the GrantAccess or DenyAccess event notifications. 4. Request Notification A PDP is notified of the request and needs attributes to respond appropriately within the total request action and context. The PDP uses the context handler as a peer process to deliver attribute values from the Policy Decision is made. 5. Attribute Queries Specifically, the PDP sends the set of attributes it needs to pick the right policy and apply the rules and logic to Decide. 6. Attribute Query The context handler pulls the attribute values query by query from the appropriate Policy Information Point which, in turn, receives Copyright 2012-13, David M. Sherr 30 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET Annals of a Running Dog
2013Q1
7. Pulled information From the attribute values from information from the (a) catalogue of subjects, (c) the target resources and (b) embedding environments. 8. Attributes Are returned per each attribute query. 9. Resource Content Is pulled by context handler from the resource, and, then combined with the PIP returns 10. Attributes Which are delivered to the PDP to make the Policy Decision, and return the context handler to the 11. Response Context From which the context handler send its 12. Response To the PEP which emits either the GrantAccess or the DenyAccess event , and notifies residual 13. Obligations To the obligations service for future assurance application in the larger context of processing think of it as residual liability.
Thus, we see how data are marshaled to lead to the enforcement of policies granting/denying access to data or processes. This is a relatively simple action. The Sherr<Guard> greatly expands XACML expressional capabilities to Grant/Deny (which is message pass-through and local) to Alert/Remediate (which is action invoking and global). This leads to a useful device, the Sherr<GuardedCommand>.
2013Q1
The Command
The community organization where this author lives has a slogan amply displayed on tee shirts: Less talk, more action. And so it is with the <command>. Figure 10: Syntactic Definition of <command>
Figure 10 lays out a concise BNF definition of the <command> portion of the Sherr<Guarded Command>. It is, as the green arrow indicates, where the action is. It is how one specifies how to change or prevent change to the state of a computation. Playing along with our Star Trek reference as we create a great integration with our technology, Jean Luc Picard would say Make it So
Tying back to Service Point and State Change In Figure 6 above, <signature> is at the center piece. Following the figure, the semantics are explained in detail.
2013Q1
Figure 10 contains the syntactic definitions for <command> of the Sherr<Guarded Command>. There is a new BNF construct introducedthe use of square bracketed ([ ]) expressions. The square brackets indicate that the expression within is optional. Harkening back to Table 8, the <signature> as defined by Figure 10 is change_order (order_no, delivery_address) where <command name> = change_order and <argument> = (order_no, delivery_address)
Completing the <command> in Table 8, we append Service Contract Constraints, viz., <precondition> = ( Identity Known && order_no Exists && Identity is ~order_no(OrderMaker) && delivery_address Valid )
<invariant> = ( Identity Permitted && Role is OrderMaker && order_no_status is Open )
<postcondition> = ( order_no_status is Changed )
Per Figure 7, each of the Table 10 Service Contract Constraints components is a <generic logical expression>, while Service Level Request is a four-element vector: <svc-lvl-req> = TXN: OnceOnlyOnce; PERF: RespTime < 3 sec., BeginToEnd < 3 min; AVAIL: AnyTime; SECLEV: Agent; As a final note, the <command> set of a <state variable> to an <expression> assures complete computational functionality. This is much like the use of special state characters in the correct Soundex algorithm of Table 5. In case of <command>, the capability is more general.
2013Q1
Part I: ConclusionBridge to Part II

In Part I here, we have explored the first principle foundations of computing as viewed in the context policy evaluation and enforcement. Take it from the top. We have separated the fly specks from the pepper. There is much more depth and breadth to cover, viz., creation of an Open Narrative to engage the World Mind. This is a goal of 2013.
In Part II, we step out of the clouds and put our feet down on two illustrative tutorial use cases, connection to the money world, and, seamless payment systems, respectively, (1) OpenFinAcct, and, (2) ScanSKU2Cash. Stay tuned to @davidsherr.
In Part II, we will turn our attention to codifying the core of Dodd-Fran Regulations from the CFTC point of view. Caveat: Commodities and FX traders beware. There is a Compliance Tool Kit business here. Open Compliance Intellectual Property (Platform as a Service) because, everybody has to do it. Only implementations are proprietary (Software as a Service)..

The Rule of Order Part I

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

The Rule of Order Part I

Загружено:

Авторское право:

Доступные форматы

Markov Algorithms as a Policy Programming ModelPart I

The Rule of Order

PROGRAMMING POLICY ENFORCEMENT Business and Government Regulations

Markov Algorithms as a Policy Programming ModelPart I

Copyright 2012-13, David M. Sherr 2 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

Markov Algorithms as a Policy Programming ModelPart I

Part I: Prologue on Cultural Context

Think like a Machine.

The Borg looms,

and We become Part of the Machine.

Copyright 2012-13, David M. Sherr 4 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

And, Star Wars

Copyright 2012-13, David M. Sherr 5 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

Neo Does the Matrix.

Markov Algorithms as a Policy Programming ModelPart I

Markov Algorithms as a Policy Programming ModelPart I

Part I: IntroductionFirst Principles

Copyright 2012-13, David M. Sherr 8 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

Markov Algorithms as a Policy Programming ModelPart I

Copyright 2012-13, David M. Sherr 10 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

Remove prefix sequences of same numbers

Copyright 2012-13, David M. Sherr 11 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

Markov Algorithms as a Policy Programming ModelPart I

Oops, need to prevent this!

Copyright 2012-13, David M. Sherr 13 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

Remove prefix sequences of same numbers

Copyright 2012-13, David M. Sherr 14 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

Begin first phase with # marker

S2 treated as a double category Consonants handled, on to vowels

Vowels finished with, handle string length HALT

Copyright 2012-13, David M. Sherr 15 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

Comment Begin first phase with # marker

Consonants handled, on to vowels

Copyright 2012-13, David M. Sherr 16 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

The Dijkstra Guarded Command

_Exec = 1; while( _Exec == 1 ) if G0 | G1 | Gn fi S0; S1; ... Sn; | _Exec = 0;

Copyright 2012-13, David M. Sherr 17 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

NB: Any compound Si can include a statement _Exec = 0; as a Halt indicator.

Copyright 2012-13, David M. Sherr 18 WIP: COMMENTS ONLY, NO REDISTRIBUTION YET

Annals of a Running Dog

Markov Algorithms as a Policy Programming ModelPart I

Part I: The Sherr<Guarded Command>