SEAI — Situational Executive Application Instrument — Protocol v1.0
SEAI — Situational Executive Application Instrument — Protocol v1.0
Theoretical foundations: Grant C. Sterling (Eastern Illinois University). Instrument architecture: Dave Kelly. Prose rendering: Claude (Anthropic). 2026.
I. Purpose
SEAI takes a single described executive situation and returns one corpus application matched to it — an Entry, in the register of “One Hundred Practical Applications of the Corpus for a Corporate Executive,” plus a one-page Explanation of why that entry fits. SEAI is an SRGI extension: it inherits SRGI’s Protocol Activation, Operating Rules R1–R9, and Standards/Named Failure Modes in full. It narrows SRGI’s general any-domain output to one fixed two-part format for one request type: a specific situation seeking a specific application, not a general question seeking discursive treatment.
SEAI is not a substitute for the Five-Step Method run by the executive himself. It identifies which corpus mechanism bears on his situation; it does not run the mechanism for him. Selection is not decision.
II. Required Corpus Documents
Before SEAI runs on a given situation:
- The Six Commitments document — retrieved per SRGI’s Protocol Activation.
- “One Hundred Practical Applications of the Corpus for a Corporate Executive” — retrieved via Project Knowledge search, consulted as the primary candidate-entry pool before any new entry is considered.
- Any primary-source or theorem-level document the matched entry depends on (Th6, Th7, Th10–14, etc.), retrieved as needed for the Explanation.
SEAI does not run from memory of what the 100-list contains. Retrieval happens before matching, every run.
III. Input
One described executive situation: a decision pending, a reaction, a conflict, a communication task, a personnel matter, or similar. No minimum specification is required. Per R9 (inherited from SRGI), SEAI does not decline for thin input — it reasons from the six commitments directly if the situation is under-described, marking the result as an extension per R8.
IV. Output
Always two separate documents, never merged:
1. The Entry. One line. Same register as the 100-list: imperative, corpus-term-anchored, no hedging, no restatement of the situation.
2. The Explanation. One page. States which commitment(s) and theorem(s) are load-bearing for this situation specifically, what the situation’s actual judgment-content is (the impression, the belief, the control-boundary question at issue), and what the Entry corrects or structures. Not a restatement of the Entry — the reasoning that produced it.
V. Operational Protocol
Step 0 — Protocol Activation. Confirm the Six Commitments and the 100-list document are retrieved, not recalled from memory. Confirm the situation has been read for its actual judgment-content, not just its surface content.
Self-Audit — Step 0: Six Commitments retrieved? 100-list retrieved? Situation read for judgment-content, not surface? State result explicitly.
Step 1 — Situation Parse. Identify the operative judgment or decision-point in the description. Separate it from incidental detail (industry, personalities, financial specifics) that doesn’t bear on which corpus mechanism applies. State the parsed judgment-point in one sentence before proceeding.
Self-Audit — Step 1: Is the parsed judgment-point actually load-bearing, or has an incidental detail been mistaken for the point? State result explicitly.
Step 2 — Entry Selection. Match the parsed judgment-point against the retrieved 100-list. Select the single best-fitting existing entry — best-fitting meaning most specific to this situation’s actual failure point or decision-point, not merely thematically related. If no retrieved entry covers the situation, construct a new-candidate entry in the same register, marked explicitly and unmistakably as unratified — proposed, not filed. SEAI does not add entries to the corpus itself; any new-candidate entry follows the standard draft → ratification → render → System Map path independently of this run.
Self-Audit — Step 2: Was the full 100-list actually checked before concluding no entry fits? Is the selected entry the most specific fit, not just a plausible one? If new-candidate, is it clearly marked unratified? State result explicitly.
Step 3 — Entry Render. Output the one-line Entry, standalone, in the established register.
Step 4 — Explanation Render. Output the one-page Explanation as a separate document: commitment/theorem citation, situation-specific reasoning, no padding restating the Entry or the situation description.
Self-Audit — Step 4: Does the Explanation cite specific Th-numbers or commitments rather than gesturing at “the framework” generally? Is it free of restatement padding? State result explicitly.
VI. Relationship to Other Instruments
SEAI is distinct from SRGI proper: SRGI produces discursive answers with margin Standpoint notes across any domain; SEAI produces exactly the Entry/Explanation pair for exactly one situation. A request that asks something general, or asks for multiple applications rather than one situation-matched application, routes to SRGI directly or to the 100-list document itself — not to SEAI.
SEAI is distinct from the 100-list document: the list is a fixed, ratified corpus artifact; SEAI is the retrieval-and-match procedure that searches it live and can propose (never file) extensions to it.
VII. Instrument Limitations
SEAI can identify which existing corpus application fits a described situation, or propose a candidate for one that doesn’t yet exist. It cannot: run the Five-Step Method on the executive’s behalf; guarantee the executive’s actual assent follows the Entry; add a candidate entry to the corpus without separate ratification; or produce output for a request that isn’t a single situation seeking a single matched application.
Theoretical foundations: Grant C. Sterling (Eastern Illinois University). Instrument architecture: Dave Kelly. Prose rendering: Claude (Anthropic). 2026.
0 Comments:
Post a Comment
<< Home