In SADT, SA is the graphic Modeling Language and DT is the Design Technique of its proper practice that brings the technical use of natural language into The Digital Age — where it can provide Perfect Understanding (mathematically defined) for both teams of people and for machine-systems, alike. A machine’s understanding is evidenced by its correct function and functioning. Whatever language is natural for the purpose at hand, that natural language is taken up into the graphical language of SA, and because every graphic feature is semantic so that the semantic constraints are imposed on the taken-up natural-language words —

The graphic structure squeezes out ambiguity and imprecision

to leave only the intended meaning — clearly understood by all relevant readers.

The Reader/Author Cycle keystone of the DT pragmatics (the interaction between meaningful signs and their users) of SADT is what makes it practical to use natural language for technical/scientific purposes. Each Reader receives a personal copy of successive drafts of an Author’s model, in a Reader Kit, and may initiate the cycle with brief written comments on the substance or the presentation of the matter, which the Author then acknowledges (a mere check-mark on the Reader’s copy or a return comment usually suffices; meetings are rare) as the copy is returned to the Reader. The final resulting model enjoys the mutual agreement of all. The process is very efficient (and suited to Web-based Collaborations) because at all times, in SA, the relevant context always is tightly drawn so "brief is beautiful" and sufficient.

SA is, first of all, a graphic ("2a: marked by or capable of clear and lively description or striking imaginative power") language — a form of blueprinting for any subject of interest. SA approaches any subject matter in terms of its Things and the Happenings of, to, or between them, modeled, respectively, as SA Data (noun expressions) and SA Activities (verb expressions). Boxes are Named and arrows are Labeled with those noun or verb expressions, as appropriate, and meaning is controlled (from the top) by the Formal Saying for the SA Box:

Under Control,

Input is transformed into Output by the Mechanism,

which augments the inherited means.

(from the bottom). The Saying forces the meaning of a box’s name to conform to the meanings imposed by the prescriptive labels on its bounding arrows (it is their meanings that are called ICOMs — for they are what ICOM coding codes, as it ensures the structural integrity of all SA modeling). Only Output arrows point away from their box side; the other three sides are oriented toward the box. Branching arrows fork and join to model the interfaces between boxes as they work together to compose a complex meaning.

Sentence formation in SA is the graphic detailing of a Parent Box’s meaning by an SA Child Diagram of interconnected Child Boxes which interface together (through their shared, branching arrow structure) to compose their parent’s meaning. The parent’s bounding arrows match up with the diagram’s boundary arrows (one free end) — controlled by ICOM Code tags derived from the parent. The composition/decomposition is by definition, because of the Formal Saying (formula):

This Saying not only provides the inheritance, it also guarantees the "decomposition" so that those indeed are "its children". [People frequently speak of decomposing "a whole into its parts," but as the Last Child formula shows, a change in the first child (or any other) in the process of analysis will yield a different composition of the same whole — so if there are three or more children (the minimum to yield real structure, rather than mere cleavage in two, or one alias of the parent) except, as in SA’s definitive context-setting composition (when it is OK!) — it simply is wrong to speak of "its" parts! (Lesniewski resolved Russell’s "class of all classes…" Paradox by a related argument proving the concept could have no meaning!)]

The SA Language (probably) is unique among languages in that Activity modeling and Data modeling, in which the roles of box names and arrow labels are interchanged while the meaning of the I,C,O,M sides remains the same, are IDENTICAL IN BOTH SYNTAX AND SEMANTICS (Input to a data box being the activity that creates that form of data, etc.). Only at the Pragmatics level of language do D and A differ, and then only in the OPTION to TOTALLY ELIMINATE Control or Input, respectively, from a box — so that

SA Data modeling can be atemporal and (hence) totally (digitally!) definitive.

Through this duality, if the same Subject is modeled from both A and D viewpoints, the meanings of all labels (including boundary conditions of the respective Top boxes) classify deeply into the hierarchic box-structure of the dual model, both ways, A to D and D to A, through the SA Tie Process (by definition of the "Everything" total inheritance, which is passed on to the A and D Atoms which collectively are each model’s Viewpoint, for there’s no more to be said). The result is called a Complete SA Model — totally definitive, WITH NO BOUNDARY CONDITIONS AT ALL!!! Defined by the hierarchic branching-arrow structure above them, those A & D atoms seek, like a biological antibody, real-world satisfaction of their needs. Each atom is a requirement.

RSADT Multi-Modeling exploits Supported Calls, which are like programming-language subroutines, mixing Caller Arguments with Called Parameters as their box boundaries merge to one Node boundary with Called detailing. The graphic syntax for Support is intriguing in that it is a mere application of tunneling — a feature of the earliest SA. Tunneling is indicated by a parentheses-like pair of ‘( )’s, drawn this vertical way, or horizontally, to enclose the tip end (including any arrowhead token) of an SA arrow. SA Tunneled Arrows indicate that the other side of the interface is missing — no matching ICOMed local <other side> of the interface will be found. The idea is that the ‘( )’s look like a rabbit-hole and the arrow ducks behind the scene of the diagram page, coming or going, as the case may be. A common use is for I or C Entry to a box of an inconsequential parameter, to allay Reader concerns; or, for the same reason, to drop an Output from further consideration. The tunnel notation may include an SA Reference-Language expression or a Model Note of explanation, but usually is blank. The intriguing use for Support is simply that if both the Support and Supported boxes appear on a single diagram, with Support down and to the left — then

A single Support-box Tunneled Output arrow

that makes a single upward bend to

a single Supported-box Tunneled Mechanism arrow

is all that is required, for the result already makes a single dumbbell-shaped Support Domain of the simplest kind! The entire inside of the Support box is available to the entire inside of the Supported box for making SA Calls from anyplace to anyplace — each call being a downward Call Arrow attached to the lower right corner of a Caller box, and labeled with a suitable Model/Node Number address of the Called box. ICOM coding of <non-tunneled O> to I, C, and M interface connections penetrating all box boundaries works throughout the Mechanism portion of the following interface definition for bundling these basic no-forking direct Support elements with other arrows: Like programming-language lexical scope, this:

distributes the Calling Domain with full integrity. [Also, the <! …ism to… Tunneled Input>…!> case can cover controlled connection of Tunneled Diagram-Boundary Entries lacking ICOM coding.] This machinery allows SA’s otherwise(by definition)-non-overlapping viewpoints to mate together — augmenting the Caller’s inheritance for its progeny. Many Callers are allowed per Called, which provides the detailing of each mixed-ancestry encounter. [Any prior Caller detailing instantly is rendered "typical", i.e. modeled by type — making it a statement of binding requirements to be synaptically mapped by the SA Tie Process and checked for compatibility in the Reader/Author Cycle.]

In all this, the SA Tie Process is unaffected so the result is that

surround (and probe) that object’s multifaceted and potentially very deep reality — for (just as infrared, optical, and X-rays work) viewpoints and viewing can operate at many "wavelengths" where Concept Engineering is concerned. The only requirement is that all of SA’s Formal Sayings/Seeings have been observed — vetted by the proper application of good-citizenship Reader(s)/Author(s) Cycle practice to assure the suitability and validity of the modeling.

That is the main plot of the story. No other science of Computer Science matches what RSADT can do for developing and accurately communicating understanding, especially to interested outsiders.