Problem-First Research, Mechanism Extraction, Public Publishing, Technical Registration and Strategic Memory

			
PROTOCOL.ID: STRATEGIZEOS.ARTICLE.PRODUCTION
VERSION: 3.0
STATUS: CANONICAL
OWNER: eduKateSG
SUPERSEDES:
    StrategizeOS Article Production Protocol v1.0
    StrategizeOS Article Production Protocol v2.0
DATE: 26 JULY 2026

		

1. Purpose of StrategizeOS

StrategizeOS studies how systems:

perceive their environment;
acquire and interpret information;
allocate resources;
coordinate independent actors;
shape movement;
time commitment;
concentrate force;
preserve optionality;
convert action into durable outcomes;
respond to failure;
and retain the capacity to continue.

Its source cases may come from:

biology;
ecology;
history;
military organisation;
civilisation;
engineering;
business;
education;
governance;
artificial intelligence;
organisational design;
or any other domain in which actors must make decisions under constraints.

StrategizeOS does not exist to produce decorative comparisons.

It is not enough to say:

			
The lion represents teamwork.
The tiger represents independence.
The cheetah represents speed.
The eagle represents power.
The peregrine represents precision.
Napoleon represents centralisation.
Genghis Khan represents decentralisation.

		

These statements may be memorable, but they are strategically incomplete.

StrategizeOS must continue beneath the visible comparison:

			
What problem was the system solving?
What information was available?
Where was decision authority placed?
How was action distributed?
What capabilities created the advantage?
At which stage was decisive advantage concentrated?
What costs did the system carry?
What conditions made the architecture effective?
What caused it to fail?
How did it withdraw, recover or adapt?
What part of the mechanism can be transferred elsewhere?

		

The fundamental transformation is:

			
STRATEGIC PROBLEM
    ↓
RELEVANT SOURCE CASES
    ↓
VERIFIED OBSERVATIONS
    ↓
CAUSAL INTERPRETATION
    ↓
PROPOSED MECHANISMS
    ↓
RIVAL EXPLANATIONS
    ↓
COUNTERCASE TESTING
    ↓
CONDITIONAL STRATEGIC RULE
    ↓
DECISION PROCEDURE
    ↓
REGISTRY CLASSIFICATION
    ↓
OUTCOME MEMORY

		

The source comparison begins the investigation.

It does not automatically prove the strategic conclusion.

2. The Central Architectural Law

A StrategizeOS project may produce several related outputs.

These outputs must not be confused with one another.

2.1 The Public Article

The public article explains the strategic discovery to an intelligent general reader.

Its purpose is to make the problem, evidence, mechanism, decision rule and limits understandable.

The public article is not the full StrategizeOS warehouse.

2.2 The Evidence Dossier

The evidence dossier records:

sources;
factual claims;
source quality;
inferential distance;
uncertainties;
internal variations;
exceptions;
rival explanations;
counterevidence;
and unresolved questions.

Its purpose is epistemic control.

2.3 The Strategy Card

The Strategy Card records:

the problem addressed;
activation conditions;
required capabilities;
operating sequence;
warning signals;
switch conditions;
abort conditions;
repair logic;
and protected base floors.

Its purpose is operational use.

2.4 The Machine Object

The machine object stores:

stable identifiers;
object type;
primitives;
relationships;
evidence status;
validation status;
decision conditions;
and memory fields.

Its purpose is AI retrieval, comparison and institutional memory.

2.5 The Runtime

A runtime selects, sequences or switches between strategies using defined inputs, states and feedback.

Its purpose is adaptive operation.

A runtime should be created only when its inputs, states, transitions, outputs, failure conditions and feedback mechanisms are sufficiently defined.

The architectural law is:

			
THE PUBLIC ARTICLE EXPLAINS.
THE EVIDENCE DOSSIER SUPPORTS.
THE STRATEGY CARD OPERATES.
THE MACHINE OBJECT RETRIEVES.
THE RUNTIME SELECTS AND ADAPTS.
OUTCOME MEMORY CORRECTS THE SYSTEM.

		

These outputs may arise from the same investigation.

They must not automatically appear on the same public webpage.

3. Mandatory Output Mode

Every StrategizeOS commission must declare an output mode before production.

The default mode is:

OUTPUT.MODE: PUBLIC_ARTICLE

The permitted modes are:

			
PUBLIC_ARTICLE
TECHNICAL_BUNDLE
FULL_RESEARCH_PACKAGE
RUNTIME_SPECIFICATION

The selected mode controls what may appear in the final output.

3.1 PUBLIC_ARTICLE

Purpose:

To publish a clear, complete and readable StrategizeOS article on WordPress.

Produce only:

			
ARTICLE TITLE
STRATEGIC QUESTION
EXECUTIVE THESIS
COMPARISON BOUNDARY
SOURCE EXPLANATION
CENTRAL STRATEGIC CONTRAST
MECHANISM
RIVAL EXPLANATIONS
CONDITIONAL DECISION RULE
VALIDITY CONDITIONS
FAILURE CONDITIONS
RELEVANT TRANSFER
LIMITS AND ETHICS
STRATEGIC SUMMARY
COMPACT RESEARCH BASIS

		

Hard stop:

			
END THE OUTPUT AFTER THE PUBLIC ARTICLE.
DO NOT APPEND:
Full Strategy Card
Claim Ledger
Evidence Dossier
YAML
JSON
Machine Object
Registry Recommendation
Runtime Specification
Production Checklist
Internal Validation Worksheet

		

A compact strategy summary may appear inside the article.

The full technical object must not appear.

3.2 TECHNICAL_BUNDLE

Purpose:

To create the internal or linked technical infrastructure supporting an existing public article.

Produce only:

			
TECHNICAL IDENTITY
EVIDENCE AND VALIDATION NOTE
CLAIM LEDGER
STRATEGY CARD
MACHINE OBJECT
REGISTRY RECOMMENDATION
REVISION AND TESTING REQUIREMENTS

		

Do not reproduce the entire public article.

A brief synopsis may be included for orientation.

3.3 FULL_RESEARCH_PACKAGE

Purpose:

To produce both the public and technical layers as distinct deliverables.

Produce:

			
DELIVERABLE A:
PUBLIC ARTICLE
DELIVERABLE B:
TECHNICAL BUNDLE

The deliverables must be clearly separated.

They are intended for different pages, systems or publication surfaces.

The full research package must not be represented as one ordinary public article.

3.4 RUNTIME_SPECIFICATION

Purpose:

To create an adaptive operating system using already researched strategies.

Produce:

			
RUNTIME PURPOSE
INPUT DEFINITIONS
STATE DEFINITIONS
TRANSITION CONDITIONS
SELECTION LOGIC
EXECUTION LOGIC
WARNING SIGNALS
ABORT CONDITIONS
FALLBACK LOGIC
REPAIR LOGIC
TELEMETRY
OUTCOME MEMORY
VALIDATION PLAN
MACHINE SPECIFICATION

		

Do not create a runtime merely because a concept can be expressed in pseudo-code.

4. Core Production Sequence

Every StrategizeOS investigation must follow this order:

			
PROBLEM
BOUNDARY
EVIDENCE
INTERPRETATION
MECHANISM
RIVAL TESTING
TRANSFER TESTING
OPERATIONALISATION
PUBLICATION
REGISTRATION
VALIDATION
MEMORY

		

The sequence must not be reversed.

Do not begin with a desired strategy and then collect supporting examples.

Do not publish the conclusion before testing rival explanations.

Do not register a new strategic object before applying the novelty gate.

Do not claim validation merely because the article has been published.

5. Problem Before Comparison

A memorable comparison may stimulate curiosity.

However, a StrategizeOS investigation requires a real strategic problem.

For example:

			
EXPLORATORY TOPIC:
Golden Eagle versus Peregrine Falcon.
STRATEGIC QUESTION:
At which stage in an operating sequence should a system place its
strongest capability in order to reduce the target’s remaining freedom?

		

Or:

			
EXPLORATORY TOPIC:
Napoleon versus Genghis Khan.
STRATEGIC QUESTION:
How should command authority be distributed when semi-independent
units move across a large operating space under information delay?

		

Or:

			
EXPLORATORY TOPIC:
Roman Empire versus Aztec Triple Alliance.
STRATEGIC QUESTION:
How much institutional integration should a central authority impose
across a distributed system, and when does looser control create
coalition reversal risk?

		

Every project must define:

			
OPERATOR:
Who must make the decision?
DECISION:
What difficult choice must be made?
OBJECTIVE:
What outcome matters?
CONSTRAINT:
What prevents an obvious solution?
STRATEGIC CONTRAST:
What competing architectures or moves are being considered?
EXPECTED VALUE:
What should the reader be able to understand or decide afterwards?

		

If no genuine strategic decision can be identified, the work may still become a comparative essay.

It should not be registered as a mature StrategizeOS object.

6. Comparison Boundary

Every project must declare what is being compared and what is not.

Required fields:

			
SOURCE CASES:
The specific species, organisation, campaign, period or system examined.
UNIT OF ANALYSIS:
Individual, group, formation, institution, campaign, state or network.
TIME BOUNDARY:
The historical or operational period examined.
GEOGRAPHICAL OR ENVIRONMENTAL BOUNDARY:
The relevant location, terrain or operating environment.
OUTCOME BOUNDARY:
The result being studied.
IN SCOPE:
The mechanisms relevant to the strategic problem.
OUT OF SCOPE:
The subjects’ total moral, political, biological or cultural value.

		

Example:

			
IN SCOPE:
The placement of decisive advantage across the hunting sequence.
OUT OF SCOPE:
A complete comparison of all Golden Eagle and Peregrine Falcon
behaviour, ecology or intelligence.

		

Another example:

			
IN SCOPE:
Command density, distributed movement and convergence.
OUT OF SCOPE:
A complete comparison of Napoleon and Genghis Khan as rulers,
political leaders or historical personalities.

		

The comparison boundary prevents the title from claiming more than the research supports.

7. Variation Before Archetype

Do not reduce a complex actor to one permanent behaviour.

Every source case must be examined for:

internal variation;
changes over time;
environmental differences;
subgroup differences;
tactical exceptions;
failures;
and alternative behaviours.

Use:

This pattern was common under these conditions.

Avoid:

This actor always used this strategy.

A Golden Eagle may use several hunting techniques.

A Peregrine Falcon does not rely solely on high-speed stoops.

Napoleon did not personally control every local movement.

Genghis Khan did not create a system without central authority.

Rome did not integrate every territory identically.

The Triple Alliance did not operate as a purely unstructured tribute network.

The archetype may remain as a human-facing memory device.

The evidence must remain more precise than the archetype.

8. Mechanism Before Metaphor

The source image is an entry point.

It is not the conclusion.

The required transformation is:

			
SURFACE DESCRIPTION
    ↓
OBSERVED PATTERN
    ↓
DOMAIN INTERPRETATION
    ↓
PROPOSED MECHANISM
    ↓
OPERATIONAL VARIABLE
    ↓
CONDITIONAL DECISION RULE

		

Example:

			
SURFACE DESCRIPTION:
The Peregrine Falcon is fast.
OBSERVED PATTERN:
The falcon uses positioning, interception geometry and rapid commitment
to reduce the prey’s available decision window.
PROPOSED MECHANISM:
DECISION_WINDOW_COMPRESSION
OPERATIONAL VARIABLE:
How much time and manoeuvring freedom remains available to the target
after commitment?
CONDITIONAL RULE:
Use decision-window compression when interception geometry can be
prepared before the target can adapt.

		

Example:

			
SURFACE DESCRIPTION:
The Golden Eagle is powerful.
OBSERVED PATTERN:
The eagle places substantial capability around contact, retention and
physical control.
PROPOSED MECHANISM:
CONTACT_DOMINANCE
OPERATIONAL VARIABLE:
Can the system reliably retain control after contact?
CONDITIONAL RULE:
Use contact dominance when the target cannot be fully neutralised before
contact and the operator possesses sufficient retention capability.

		

The mechanism must be expressible without relying on the source animal, commander or civilisation.

9. Evidence Before Architecture

The research must be capable of changing:

the comparison;
the title;
the proposed mechanism;
the decision rule;
the strength of the conclusion;
or the decision to publish.

The law is:

			
EVIDENCE CONSTRAINS THE MODEL.
THE MODEL DOES NOT COMMAND THE EVIDENCE.

Do not build a complete doctrine and then search for supporting facts.

Do not treat a famous story as verified merely because it is widely repeated.

Do not hide evidence that weakens the preferred comparison.

When evidence is insufficient:

			
Reduce the claim.
Narrow the boundary.
Mark the mechanism provisional.
Retain the case as research.
Or abandon the proposed object.

		

Honest incompleteness is preferable to artificial completion.

10. Evidence Classification

Protocol v3.0 separates three different questions:

How reliable is the source?
How far is the claim from direct observation?
How much validation has the mechanism received?

10.1 Source Quality

			
Q1 — HIGH-QUALITY EVIDENCE APPROPRIATE TO THE CLAIM
Examples:
Peer-reviewed empirical research
Reliable official records
Primary data
Strong systematic reviews
Credible critical editions
Multiple converging specialist sources
Q2 — STRONG SPECIALIST SYNTHESIS
Examples:
Recognised academic books
Expert historical analysis
Official institutional syntheses
Specialist scientific reference works
Q3 — CREDIBLE SECONDARY MATERIAL
Examples:
Responsible journalism
Museum or university summaries
High-quality educational reference material
Specialist commentary without full primary support
Q4 — WEAK OR UNVERIFIED MATERIAL
Examples:
Unsourced summaries
Popular mythology
Promotional narratives
Unverified claims
Content whose method cannot be assessed

		

Source quality must be judged relative to the claim.

A primary source may be close to an event but politically biased.

A later scholarly synthesis may be stronger for a broad conclusion.

10.2 Inferential Distance

			
I0 — DIRECT OBSERVATION OR RECORDED FACT
I1 — INTERPRETATION WITHIN THE ORIGINAL DOMAIN
I2 — MECHANISM EXTRACTED FROM SEVERAL OBSERVATIONS
I3 — CROSS-DOMAIN STRUCTURAL TRANSFER
I4 — SPECULATIVE EXTENSION OR PREDICTION

		

10.3 Validation Status

			
V0 — UNTESTED
The mechanism has been proposed but not independently examined.
V1 — CASE-CONSISTENT
The mechanism fits the originating case without obvious contradiction.
V2 — TRIANGULATED
More than one relevant case or evidence stream supports it.
V3 — RETROSPECTIVELY TESTED
The procedure has been applied to historical or completed cases using
declared success and failure criteria.
V4 — PILOTED
The procedure has been used prospectively in a limited real setting.
V5 — REPEATEDLY SUPPORTED
The procedure has produced useful results across repeated applications.
V6 — VALIDATED WITHIN A DECLARED CONTEXT
The procedure has demonstrated reliable value within a clearly bounded
domain and operating environment.

		

Validation is always context-bound.

A strategy supported in classroom instruction is not automatically validated for corporate restructuring or autonomous AI systems.

11. The Evidence Dossier

The evidence dossier must be created before the public article is finalised.

Required fields:

			
RESEARCH QUESTION
COMPARISON BOUNDARY
CASE DEFINITIONS
TIME PERIOD
ENVIRONMENT
CORE OBSERVATIONS
KNOWN VARIATION
SOURCE MAP
CLAIM LEDGER
EXCEPTIONS
COUNTEREVIDENCE
RIVAL EXPLANATIONS
UNKNOWN VARIABLES
PROVISIONAL MECHANISMS
TRANSFER RISKS
RESEARCH LIMITATIONS
PROHIBITED OVERCLAIMS

		

The evidence dossier may remain:

internal;
on a separate technical page;
in a structured database;
in a document repository;
or in another research system.

It must not automatically appear in full on the public article page.

12. Claim Ledger

Every important factual or causal claim should be traceable.

Use:

			
CLAIM.ID:
CLAIM.TEXT:
SOURCE:
SOURCE.QUALITY:
INFERENTIAL.DISTANCE:
VALIDATION.STATUS:
SUPPORTING.EVIDENCE:
COUNTEREVIDENCE:
KNOWN.EXCEPTIONS:
CONFIDENCE:
PERMITTED.LANGUAGE:
PROHIBITED.OVERCLAIM:

		

Example:

			
CLAIM.ID:
COMMAND_GEOMETRY.01
CLAIM.TEXT:
As operational distance and information delay increase, effective
command systems may need to reduce instruction density while increasing
intent clarity, modular capability and subordinate discretion.
SOURCE.QUALITY:
Q1–Q2
INFERENTIAL.DISTANCE:
I2
VALIDATION.STATUS:
V1
PERMITTED.LANGUAGE:
The cases suggest...
This mechanism may become useful when...
Under these conditions...
PROHIBITED.OVERCLAIM:
Decentralised command is always superior.
Central control always fails across large distances.
One historical campaign proves a universal law.

		

The public article should reflect this discipline without displaying the entire ledger.

13. Evidence-to-Mechanism Chain

Every central mechanism must be presented internally through this chain:

			
OBSERVATION
    ↓
DOMAIN INTERPRETATION
    ↓
PROPOSED MECHANISM
    ↓
OPERATIONAL VARIABLE
    ↓
EXPECTED EFFECT
    ↓
DISCONFIRMING SIGNAL
    ↓
TRANSFER STATUS

		

Observation

What was measured, recorded or credibly described?

Domain Interpretation

What does the observation mean in its original historical, biological, organisational or technical setting?

Proposed Mechanism

What causal process may have produced the result?

Operational Variable

What can an operator observe, adjust, constrain or protect?

Expected Effect

What should happen when the mechanism is active?

Disconfirming Signal

What result would weaken the proposed explanation?

Transfer Status

Classify as:

			
SOURCE_BOUND
STRUCTURALLY_PLAUSIBLE
MAPPED_TO_SECOND_DOMAIN
RETROSPECTIVELY_SUPPORTED
PILOTED
VALIDATED_WITHIN_CONTEXT

		

14. Rival Explanations Are Mandatory

A StrategizeOS article must not move directly from observed difference to causal certainty.

For every major conclusion, ask:

			
What else could explain the outcome?
Which other variables changed?
Could causality run in the opposite direction?
Could the result be caused by technology, terrain, disease, logistics,
opponent weakness, institutional maturity or timing?
Is the mechanism only correlated with the outcome?
Where should the mechanism work but apparently does not?
What observation would weaken the conclusion?

		

Every public article must distinguish:

			
OBSERVED DIFFERENCE
PROPOSED MECHANISM
RIVAL EXPLANATIONS
PERMITTED CONCLUSION
IMPERMISSIBLE CONCLUSION

		

Example:

			
OBSERVED DIFFERENCE:
One system maintained denser institutional integration.
PROPOSED MECHANISM:
Higher integration may increase reciprocal dependence and reduce some
forms of rapid coalition defection.
RIVAL EXPLANATIONS:
Geography
Disease
Technology
Chronology
Military circumstances
Political succession
External alliances
PERMITTED CONCLUSION:
Control density may change the costs and risks of defection.
IMPERMISSIBLE CONCLUSION:
Control density alone explains imperial durability or collapse.

		

Rival explanations strengthen the article by defining the mechanism’s actual contribution.

15. Countercase Testing

Every major mechanism must be able to lose.

Required questions:

			
SUPPORTING SIGNAL:
What would strengthen the mechanism?
DISCONFIRMING SIGNAL:
What would weaken it?
COUNTERCASE:
Where should the mechanism work but does not?
BOUNDARY CASE:
Where is the mechanism too weak to matter?
REPLACEMENT EXPLANATION:
What may explain the outcome better?

		

Possible outcomes:

			
MECHANISM RETAINED
MECHANISM NARROWED
MECHANISM REVISED
MECHANISM MERGED
MECHANISM REJECTED
INSUFFICIENT EVIDENCE

		

A theory that can explain every result after the fact is not sufficiently disciplined.

16. StrategizeOS Object Taxonomy

Not every article creates a new strategy.

Protocol v3.0 uses the following hierarchy.

16.1 Case

A researched source of observations.

Examples:

			
CASE.GOLDEN_EAGLE_PEREGRINE_ADVANTAGE_PLACEMENT
CASE.NAPOLEON_GENGHIS_COMMAND_GEOMETRY
CASE.ROMAN_AZTEC_CONTROL_DENSITY

A case may support several mechanisms.

A case is not automatically a strategy.

16.2 Primitive

A small reusable strategic element.

Examples:

			
DISTRIBUTED_SENSING
CONTACT_DOMINANCE
DECISION_WINDOW_COMPRESSION
TARGET_ISOLATION
CONTROL_DENSITY
LOCAL_AUTONOMY
SAFE_WITHDRAWAL
RESERVE_CAPACITY
CONCENTRATED_CONVERSION

		

16.3 Law

A conditional relationship between variables.

Example:

			
As operational distance and information delay increase, instruction
density may need to fall while intent clarity and local discretion rise.

A StrategizeOS law is a bounded strategic relationship.

It is not automatically a universal scientific law.

16.4 Recipe

An ordered combination of primitives.

Example:

			
DISTRIBUTE TO DISCOVER
CONCENTRATE TO DECIDE
DISPERSE TO RECOVER

16.5 Doctrine

A family of recipes and laws organised around a recurring problem.

Example:

COMMAND_GEOMETRY_DOCTRINE

16.6 Runtime

A system that selects or switches between strategies using defined states, inputs and feedback.

A runtime requires:

measurable or observable inputs;
distinct states;
meaningful transitions;
defined outputs;
error handling;
abort logic;
recovery logic;
and telemetry.

16.7 Alias

A memorable human-facing name.

Examples:

			
LION MODE
TIGER MODE
PEREGRINE COMMITMENT
EAGLE CONTACT CONTROL
NAPOLEONIC CONVERGENCE
MONGOL DISTRIBUTED MOVEMENT

		

Aliases support communication.

Canonical mechanism names support reasoning.

Example:

			
HUMAN ALIAS:
Peregrine Strategy
CANONICAL MECHANISMS:
DECISION_WINDOW_COMPRESSION
INTERCEPTION_GEOMETRY
RAPID_COMMITMENT
PRE_CONTACT_ADVANTAGE

		

17. Novelty Gate

Before creating a new strategy ID, ask:

			
Has this project revealed a genuinely new primitive?
Has it revealed a new conditional relationship?
Has it created a new sequence using known primitives?
Has it exposed a previously unmapped failure mode?
Has it produced a meaningful switching rule?
Is the proposed object materially different from existing objects?

		

Possible registration outcomes:

			
NEW CASE ONLY
NEW ALIAS
NEW EVIDENCE FOR EXISTING PRIMITIVE
NEW LAW
NEW RECIPE
NEW DOCTRINE
RUNTIME CANDIDATE
MERGE WITH EXISTING OBJECT
NO REGISTRY CHANGE

		

A new comparison does not require a new strategy family.

A new article may contribute evidence to an existing object.

Registry quality matters more than registry size.

18. Precision and Calibration

Exact numbers create an appearance of scientific authority.

They must be used carefully.

Do not write:

			
18 × TARGET_CLARITY
15 × EXECUTION_READINESS
12 × TIME_URGENCY

unless the weights have a defensible basis.

Do not write:

LAUNCH IF READINESS > 0.75

unless readiness can be measured and the threshold has been calibrated.

When calibration does not exist, use:

			
LOW
MODERATE
HIGH
CRITICAL

Or:

			
PASS
CAUTION
FAIL
UNKNOWN

When a conceptual equation is useful, label it clearly:

			
CONCEPTUAL REASONING MODEL
NOT EMPIRICALLY CALIBRATED
NOT A PREDICTIVE EQUATION
USED TO SHOW RELATIONSHIPS BETWEEN VARIABLES

Formal appearance must not exceed empirical support.

19. Principle, Procedure and Executable Model

Not every structured sequence is an algorithm.

Protocol v3.0 uses three levels.

19.1 Strategic Principle

A compact conditional relationship.

Example:

			
Place the system’s strongest capability at the stage where the target’s
remaining freedom can be reduced most reliably.

19.2 Decision Procedure

A human-operable sequence containing:

inputs;
judgement;
phases;
gates;
warning signals;
switch conditions;
exits;
and repair logic.

Example:

			
Define the target outcome.
Map the operating sequence.
Identify where freedom remains highest.
Identify where control can be created most reliably.
Verify required capabilities.
Place decisive effort at that stage.
Protect all indispensable stages above minimum operating level.
Monitor conversion and warning signals.
Switch, abort or repair when conditions change.

		

19.3 Executable Model

An executable model requires:

defined variables;
measurement rules;
calibrated thresholds;
reproducible logic;
observable outputs;
error handling;
and outcome data.

Only this level should be treated as a computational algorithm or runtime.

The naming law is:

			
PRINCIPLE:
Explains a relationship.
DECISION PROCEDURE:
Guides human judgement.
EXECUTABLE MODEL:
Processes defined inputs reproducibly.

		

20. Capability Before Execution

A strategy requiring unavailable capabilities is not a valid immediate strategy.

Every operational object must define:

			
CAPABILITY.REQUIRED
CAPABILITY.AVAILABLE
CAPABILITY.MISSING
CAPABILITY.BUILDABLE
CAPABILITY.NON_TRANSFERABLE

		

Examples of required capabilities may include:

accurate sensing;
trusted communication;
role clarity;
timing control;
modular independence;
shared intent;
safe withdrawal;
target discrimination;
recovery reserves;
institutional legitimacy;
and local judgement.

If required capabilities are missing, the system must:

			
BUILD CAPABILITY
SELECT A LOWER-DEMAND STRATEGY
REDUCE THE OBJECTIVE
DELAY COMMITMENT
OR ABORT

		

Ambition does not substitute for capability.

21. Protect the Base Floor

Every strategy must identify what cannot be sacrificed.

Possible protected elements include:

safety;
dignity;
legal compliance;
trust;
financial survival;
institutional credibility;
student confidence;
core knowledge;
operational continuity;
privacy;
data integrity;
human oversight;
and long-term learning capacity.

Required fields:

			
BASE.FLOOR:
What must remain protected?
MAXIMUM.ACCEPTABLE.LOSS:
What can the system afford to lose?
IRREVERSIBLE.RISK:
What damage cannot be easily repaired?
PROTECTED.PARTIES:
Who carries risk without controlling the decision?

		

A short-term win that destroys future capacity may represent strategic failure.

22. Exit, Withdrawal and Repair

Every strategy requires:

			
WARNING SIGNALS
SWITCH CONDITIONS
ABORT CONDITIONS
WITHDRAWAL ROUTE
REPAIR ROUTE
FALLBACK STRATEGY
RE-ENTRY CONDITIONS

		

An exit must be designed before commitment.

A strategy without an exit is an uncontrolled exposure.

Example:

			
WARNING SIGNAL:
Instructions are arriving too late to remain relevant.
SWITCH CONDITION:
Increase local discretion and reduce instruction density.
ABORT CONDITION:
Independent units no longer share the same objective.
REPAIR ROUTE:
Re-establish intent, reset reporting, reduce operating distance or
recombine the units.
RE-ENTRY CONDITION:
Shared objective and communication reliability are restored.

		

23. Structural Transfer Test

A mechanism may be transferred only when the relevant structures are sufficiently comparable.

Test:

Dimension	Transfer question
Actors	Are the operating units structurally comparable?
Objectives	Are the intended outcomes sufficiently similar?
Incentives	Do actors respond to comparable costs and rewards?
Information	Is information distributed, delayed or concealed similarly?
Resources	Are resources constrained in a comparable way?
Timing	Do commitment windows and delays matter similarly?
Coordination	Is the coordination problem structurally similar?
Reversibility	Can mistakes be reversed to a similar degree?
Adaptation	Can the system learn during operation?
Agency	Do human participants retain judgement and consent?
Harm	Could transfer expose people to unacceptable risk?
Environment	Does the source mechanism depend on a feature absent in the target domain?

Classify:

			
PASS
The relevant structures are substantially comparable.
CAUTION
Some structures align, but important differences remain.
FAIL
The transfer depends mainly on surface resemblance.
UNKNOWN
Evidence is insufficient.

		

Transfer only the mechanism.

Do not transfer:

literal predation;
violence;
coercion;
dehumanisation;
military destruction;
or biological behaviour as moral destiny.

The correct question is not:

How can a classroom hunt like a peregrine?

The correct question is:

			
Does the classroom face a timing and decision-window problem that is
structurally similar to the mechanism observed in the source case?

24. Article Types

Protocol v3.0 does not force every article into one identical structure.

24.1 Case Analysis

Purpose:

To explain one source case and identify possible mechanisms.

Primary output:

			
CASE OBJECT
PROVISIONAL MECHANISMS

24.2 Comparative Analysis

Purpose:

To compare two or more cases around a controlled strategic variable.

Primary output:

			
CONDITIONAL CONTRAST
MECHANISM DIFFERENCE
DECISION RULE

24.3 Mechanism Synthesis

Purpose:

To study one mechanism across several independent cases.

Primary output:

			
PRIMITIVE
LAW
BOUNDARY CONDITIONS

24.4 Strategy Recipe

Purpose:

To combine known primitives into an ordered procedure.

Primary output:

			
STRATEGY CARD
DECISION PROCEDURE

24.5 Doctrine Article

Purpose:

To organise several strategies around a recurring problem class.

Primary output:

			
STRATEGY FAMILY
SELECTION LOGIC
SWITCHING RELATIONSHIPS

24.6 Runtime Specification

Purpose:

To define adaptive selection, state transitions, telemetry and recovery.

Primary output:

TECHNICAL RUNTIME OBJECT

A runtime specification should normally be published separately from its introductory public article.

25. Public Article Architecture

In PUBLIC_ARTICLE mode, use the following structure.

H1: Title

The title should identify:

the source comparison or mechanism;
and the strategic problem it illuminates.

Preferred pattern:

			
StrategizeOS | [Specific Case A] Versus [Specific Case B]:
[Strategic Question or Mechanism]

Use precise source names.

Prefer:

Golden Eagle Versus Peregrine Falcon

over:

Eagle Versus Peregrine Falcon

when the research concerns a specific eagle species.

Opening

The opening should identify:

			
THE DECISION
WHY IT IS DIFFICULT
WHY THESE CASES HELP

Do not spend several paragraphs describing the fame, beauty or power of the subjects before identifying the problem.

H2: The Strategic Question

State the operating problem clearly.

Example:

			
When a target can escape, should decisive advantage be concentrated
before contact or after contact?

H2: Executive Thesis

Answer the question in readable language.

The thesis should state:

the central difference;
the proposed mechanism;
the conditions that matter;
and the limit of the conclusion.

H2: Why These Cases Matter

Explain:

why the cases illuminate the problem;
why the comparison is useful;
and what is not being compared.

Declare the comparison boundary.

H2: What the Evidence Shows

Explain the source cases accurately.

Include:

core observations;
internal variation;
environmental conditions;
meaningful exceptions;
and important factual corrections.

The purpose is not to display every source note.

The purpose is to establish a reliable base for the mechanism.

H2: The Central Strategic Contrast

Use a table where useful.

Possible dimensions:

Dimension	Architecture A	Architecture B
Information	Distributed	Concentrated
Decision authority	Local discretion	Dense central direction
Commitment	Delayed	Rapid
Advantage placement	Before contact	At contact
Movement	Independent	Convergent
Main strength	Flexibility	Precision
Main cost	Divergence risk	Headquarters overload
Recovery	Redistribution	Retention and stabilisation

The table describes the difference.

The next section explains the mechanism.

H2: The Mechanism Beneath the Comparison

Show:

			
OBSERVATION
→ MECHANISM
→ OPERATIONAL VARIABLE
→ EXPECTED EFFECT

Name the mechanism only after explaining it.

H2: What Else Could Explain the Result?

Present:

rival explanations;
countercases;
omitted variables;
and uncertainty.

State the permitted and impermissible conclusions.

H2: The Conditional Decision Rule

Explain when each architecture becomes useful.

Use:

			
USE ARCHITECTURE A WHEN...
USE ARCHITECTURE B WHEN...
USE A HYBRID WHEN...
DO NOT USE EITHER WHEN...

A hybrid must be labelled correctly.

If the hybrid is a StrategizeOS synthesis rather than a directly observed source pattern, state:

			
This hybrid is a StrategizeOS synthesis derived from the comparison.
It is not presented as a separate historical or biological category.

H2: When the Strategy Works

State:

			
VALID UNDER
REQUIRES
DOMINANT WHEN
SUCCESS SIGNALS

H2: When the Strategy Fails

State:

			
INVALID UNDER
WEAK WHEN
WARNING SIGNALS
ABORT CONDITIONS
REPAIR ROUTE

		

H2: Transfer into a Relevant Domain

Include only domains that pass or cautiously survive the structural transfer test.

Possible domains:

education;
business;
AI;
governance;
organisational design;
civilisation;
engineering.

Do not force every domain into every article.

One strong transfer is better than four decorative applications.

H2: Limits, Safety and Ethics

State:

what cannot be transferred;
who must be protected;
what risks are unacceptable;
and where human judgement remains necessary.

H2: Strategic Summary

Summarise:

			
SOURCE LESSON
MECHANISM LESSON
DECISION LESSON
BOUNDARY LESSON

The public article ends after the Strategic Summary and Compact Research Basis.

H2: Compact Research Basis

Include a concise list of the most important source categories or references supporting the article.

Do not reproduce the full claim ledger.

Do not append the machine object.

26. Public Article Hard Stop

When:

OUTPUT.MODE: PUBLIC_ARTICLE

the output must stop after:

			
STRATEGIC SUMMARY
COMPACT RESEARCH BASIS

Do not append:

			
STRATEGY CARD
EVIDENCE AND VALIDATION NOTE
CLAIM LEDGER
YAML
JSON
MACHINE OBJECT
REGISTRY RECOMMENDATION
RUNTIME ASSESSMENT
PRODUCTION CHECKLIST

		

These may be prepared internally.

They may be delivered separately in TECHNICAL_BUNDLE mode.

The public page should feel complete without becoming the entire StrategizeOS warehouse.

27. Technical Bundle Architecture

When:

OUTPUT.MODE: TECHNICAL_BUNDLE

produce the following.

27.1 Technical Identity

			
OBJECT.ID:
OBJECT.NAME:
OBJECT.TYPE:
SOURCE CASES:
HUMAN ALIASES:
VERSION:
STATUS:
OWNER:
RELATED PUBLIC ARTICLE:

		

27.2 Evidence and Validation Note

Summarise:

			
STRONGEST SOURCE QUALITY
INFERENTIAL DISTANCE
VALIDATION STATUS
SUPPORTING CASES
COUNTERCASES
RIVAL EXPLANATIONS
KEY UNCERTAINTIES
PROHIBITED OVERCLAIMS

		

27.3 Claim Ledger

Include the central factual and causal claims.

27.4 Strategy Card

Use:

			
STRATEGY.ID:
STRATEGY.NAME:
OBJECT.TYPE:
HUMAN.ALIASES:
PROBLEM:
CORE.MOVE:
USE.WHEN:
DO.NOT.USE.WHEN:
REQUIRES:
INPUTS:
PHASES:
DECISION.GATES:
SUCCESS.SIGNALS:
WARNING.SIGNALS:
SWITCH.CONDITION:
ABORT.CONDITION:
BASE.FLOOR:
PROTECTED.PARTIES:
WITHDRAWAL.ROUTE:
REPAIR.ROUTE:
FALLBACK:
REENTRY.CONDITIONS:
EVIDENCE.STATUS:
VALIDATION.STATUS:
RELATED.PRIMITIVES:
RELATED.CASES:
MEMORY.WRITE:

		

27.5 Machine Object

Use the structure below.

			
strategizeos_object:
  protocol:
    id: "STRATEGIZEOS.ARTICLE.PRODUCTION"
    version: "3.0"
  identity:
    object_id: ""
    object_name: ""
    object_type: "case | primitive | law | recipe | doctrine | runtime"
    human_aliases: []
    version: "0.1"
    status: "research_draft"
    owner: "eduKateSG"
  strategic_problem:
    operator: ""
    decision: ""
    objective: ""
    constraints: []
    expected_value: ""
  source_scope:
    cases: []
    source_domains: []
    unit_of_analysis: ""
    time_boundary: ""
    geographic_boundary: ""
    environmental_boundary: ""
    comparison_boundary: ""
    exclusions: []
  evidence:
    claim_ledger_location: ""
    highest_source_quality: "Q1 | Q2 | Q3 | Q4 | unknown"
    inferential_distance: "I0 | I1 | I2 | I3 | I4"
    validation_status: "V0 | V1 | V2 | V3 | V4 | V5 | V6"
    supporting_cases: []
    countercases: []
    rival_explanations: []
    uncertainties: []
    prohibited_overclaims: []
  mechanism:
    observations: []
    domain_interpretations: []
    proposed_mechanisms: []
    primitives: []
    conditional_laws: []
    expected_effects: []
    disconfirming_signals: []
  operational_model:
    model_level: "principle | decision_procedure | executable_model"
    inputs: []
    preconditions: []
    phases: []
    decision_gates: []
    switch_conditions: []
    success_signals: []
    warning_signals: []
    abort_conditions: []
    withdrawal_route: []
    fallback_strategy: ""
    repair_route: []
    reentry_conditions: []
  capability:
    required: []
    available: []
    missing: []
    buildable: []
    non_transferable: []
  validity:
    valid_under: []
    invalid_under: []
    dominant_when: []
    weak_when: []
    fails_when: []
    dangerous_when: []
  transfer:
    source_domain: ""
    target_domains: []
    structural_matches: []
    structural_mismatches: []
    transfer_status: "source_bound | plausible | mapped | tested | validated"
    human_review_required: true
  safety:
    protected_base_floor: []
    protected_parties: []
    irreversible_risks: []
    ethical_limits: []
    prohibited_uses: []
    legal_review_required: false
  relations:
    parent_objects: []
    child_objects: []
    complementary_objects: []
    conflicting_objects: []
    supersedes: []
    superseded_by: []
  publication:
    public_article_title: ""
    public_article_url: ""
    evidence_dossier_location: ""
    strategy_card_location: ""
    technical_bundle_location: ""
    runtime_location: ""
  memory:
    outcome_metrics: []
    outcome_records: []
    failure_records: []
    unexpected_effects: []
    revisions_required: []
    last_reviewed: ""
    next_review_due: ""

		

27.6 Registry Recommendation

Classify as:

			
REGISTER AS NEW CASE
REGISTER AS NEW PRIMITIVE
REGISTER AS PROVISIONAL LAW
REGISTER AS RECIPE
REGISTER AS DOCTRINE
RETAIN AS RUNTIME CANDIDATE
MERGE WITH EXISTING OBJECT
RETAIN AS UNREGISTERED RESEARCH
REJECT OR RETIRE

		

State the reason.

28. Runtime Qualification Gate

A strategy or doctrine must not be called a runtime until it passes the following tests.

			
INPUT TEST:
Can the required inputs be defined and observed?
STATE TEST:
Can distinct operating states be identified?
TRANSITION TEST:
Can the conditions for changing state be defined?
OUTPUT TEST:
Can the expected outputs be observed?
FAILURE TEST:
Can failure and degradation be detected?
RECOVERY TEST:
Are fallback and repair routes defined?
TELEMETRY TEST:
Can outcomes be recorded?
VALIDATION TEST:
Has the model received at least some form of testing?

		

Possible status:

			
NOT A RUNTIME
RUNTIME CONCEPT
RUNTIME CANDIDATE
PILOT RUNTIME
CONTEXT-BOUND VALIDATED RUNTIME

		

Pseudo-code alone does not qualify the object as a runtime.

29. Production Workflow

Stage 0: Commission

Define:

			
OUTPUT.MODE
TOPIC
STRATEGIC PROBLEM
OPERATOR
OBJECTIVE
CONSTRAINT
SOURCE CASES
TARGET DOMAIN
EXPECTED VALUE

		

Stop when no real strategic problem can be identified.

Stage 1: Boundary

Define:

			
UNIT OF ANALYSIS
TIME BOUNDARY
ENVIRONMENT
IN SCOPE
OUT OF SCOPE
OUTCOME BOUNDARY

		

Deliverable:

COMPARISON BOUNDARY STATEMENT

Stage 2: Evidence Dossier

Research:

source facts;
context;
internal variation;
exceptions;
failures;
source reliability;
and unknowns.

Deliverables:

			
SOURCE MAP
CLAIM LEDGER
UNKNOWN LIST

Stop when the central descriptive claims cannot be verified.

Stage 3: Provisional Mechanism

Construct:

			
OBSERVATION
→ INTERPRETATION
→ MECHANISM
→ VARIABLE
→ EXPECTED EFFECT

		

Deliverable:

PROVISIONAL MECHANISM MAP

Stage 4: Attack the Mechanism

Search for:

rival explanations;
unsuccessful examples;
countercases;
reversed causality;
omitted variables;
and invalid environments.

Deliverable:

CAUSAL CHALLENGE TABLE

Narrow, revise or reject the mechanism when required.

Stage 5: Extract the Object

Determine whether the result is:

			
CASE
PRIMITIVE
LAW
RECIPE
DOCTRINE
RUNTIME CANDIDATE
ALIAS
NO NEW OBJECT

		

Apply the novelty gate.

Stage 6: Transfer Test

Map:

structural matches;
structural mismatches;
safety concerns;
and transfer status.

Deliverable:

			
PASS
CAUTION
FAIL
UNKNOWN

Do not produce operational advice from a failed transfer.

Stage 7: Operationalise

Define:

required capabilities;
decision procedure;
warning signals;
switch conditions;
exits;
repair routes;
and protected base floors.

Deliverable:

STRATEGY CARD

Stage 8: Produce the Selected Output Mode

PUBLIC_ARTICLE

Produce only the public article and stop.

TECHNICAL_BUNDLE

Produce only the technical materials.

FULL_RESEARCH_PACKAGE

Produce two separate deliverables.

RUNTIME_SPECIFICATION

Produce only the runtime specification.

Stage 9: Register

Assign:

stable ID;
object type;
lifecycle status;
evidence classification;
validation status;
relationships;
and memory fields.

Stage 10: Collect Outcome Memory

After application, record:

			
CONTEXT
INPUT CONDITIONS
STRATEGY SELECTED
ACTION TAKEN
EXPECTED OUTCOME
ACTUAL OUTCOME
SUCCESS SIGNALS
WARNING SIGNALS
FAILURES
REPAIR USED
UNEXPECTED EFFECTS
LESSON
OBJECT REVISION

		

The registry should improve through observed outcomes, not merely expand through publication.

30. Lifecycle Status

Use:

			
RESEARCH_DRAFT
The question and evidence remain under investigation.
SOURCE_VERIFIED
The main descriptive claims have been checked.
MECHANISM_PROVISIONAL
A mechanism has been extracted but remains untested.
TRIANGULATED
Independent cases or evidence streams support the mechanism.
PILOT_READY
Inputs, safeguards, outcome measures and repair routes are defined.
PILOTED_CONTEXT_BOUND
The strategy has been used prospectively in a limited setting.
VALIDATED_CONTEXT_BOUND
Repeated evidence supports the strategy within a declared domain.
REVISED
New evidence or outcomes have materially changed the object.
MERGED
The object has been absorbed into a stronger existing object.
RETIRED
The object is obsolete, misleading, redundant or superseded.

		

CANONICAL means the object is the current official version inside StrategizeOS.

It does not mean every empirical conclusion is universally proven.

31. Failure Modes

31.1 Metaphor Lock

The article remains trapped in the source image.

Repair:

Extract the mechanism, conditions, costs and disconfirming signals.

31.2 Pair-Selection Bias

The subjects were selected first and the article forces a contrast.

Repair:

Restate the strategic problem and introduce more cases where required.

31.3 Archetype Flattening

A species, civilisation or person is reduced to one behaviour.

Repair:

Add variation, exceptions, environmental conditions and failed cases.

31.4 Single-Cause Inflation

One mechanism is used to explain a large historical outcome.

Repair:

Add rival explanations and narrow the conclusion.

31.5 False Precision

Arbitrary weights or thresholds create unsupported authority.

Repair:

Use ordinal gates or label the model as illustrative.

31.6 Algorithm Inflation

A conceptual checklist is called an algorithm.

Repair:

Classify it as a principle or decision procedure.

31.7 Registry Inflation

Every article creates a new strategy family.

Repair:

Apply the novelty gate and reuse existing primitives.

31.8 Transfer Overreach

The source and target share imagery but not causal structure.

Repair:

Apply the structural transfer test.

31.9 Public-Article Overload

The public article includes the evidence dossier, Strategy Card, YAML and registry recommendation.

Repair:

Enforce OUTPUT.MODE: PUBLIC_ARTICLE and the public hard stop.

31.10 Validation by Publication

A published article is treated as proof.

Repair:

Display the actual validation status.

31.11 Mandatory Multi-Domain Transfer

Every article is forced to include education, business, AI and civilisation applications.

Repair:

Include only transfers that materially pass the structural test.

31.12 Self-Sealing Explanation

Success proves the strategy and failure is blamed on execution.

Repair:

Define disconfirming signals before application.

31.13 Personality-Centred Strategy

A mechanism is permanently attached to a famous person.

Repair:

Retain the name as an alias and register the mechanism independently.

31.14 Generic Source Naming

A broad category is used when the analysis concerns a specific case.

Repair:

Use precise source naming in the title and boundary.

Example:

Golden Eagle

rather than:

Eagle

32. Safety and Ethical Boundaries

StrategizeOS may study:

predation;
military conflict;
political coercion;
collapse;
competition;
and adversarial systems.

Analysis does not imply endorsement.

Every human transfer must examine:

			
CONSENT
AGENCY
DIGNITY
HARM
POWER ASYMMETRY
LEGALITY
REVERSIBILITY
PROTECTED PARTIES
LONG-TERM CONSEQUENCES
HUMAN REVIEW

		

Do not convert:

manipulation into pedagogy;
coercion into leadership;
dehumanisation into efficiency;
predation into marketing;
military destruction into ordinary organisational advice;
or biological survival behaviour into moral justification.

In education, the protected base floor normally includes:

student safety;
confidence;
dignity;
developmental appropriateness;
conceptual foundations;
intellectual independence;
family trust;
and long-term willingness to learn.

In AI systems, the protected base floor may include:

human oversight;
privacy;
data integrity;
traceability;
reversibility;
legal compliance;
and resistance to uncontrolled optimisation.

When uncertainty or potential harm is high, human review is mandatory.

33. Public Writing Style

StrategizeOS articles should sound:

			
INTELLIGENT
PRECISE
CALM
READABLE
INVESTIGATIVE
EVIDENCE-AWARE
SYSTEMS-ORIENTED
NON-SENSATIONAL

		

Explain before encoding.

Define specialised terms.

Use technical language only when it improves precision.

Avoid:

			
Hero worship
Empty motivation
Species mythology
Grand claims without evidence
Unexplained abbreviations
Poetic language that obscures causality
Technical density for its own sake
Machine structures in place of explanation
False scientific certainty

		

The human reader should understand the mechanism without reading the machine object.

The machine should retrieve the object without treating prose as a database.

34. WordPress Publishing Rules

Use:

one H1;
logical H2 and H3 headings;
short, complete paragraphs;
comparison tables where useful;
code blocks only for concise decision rules or conceptual models;
visible source attribution near load-bearing claims;
and internal links to related StrategizeOS cases and mechanisms.

Do not publish:

the production checklist;
the complete internal dossier;
the full YAML object;
or the entire registry entry

on an ordinary public article page.

Preferred public architecture:

			
PUBLIC ARTICLE
+
COMPACT RESEARCH BASIS
+
OPTIONAL LINK TO TECHNICAL CASE PAGE
+
OPTIONAL LINK TO MECHANISM PAGE

		

Preferred technical architecture:

			
TECHNICAL CASE PAGE
+
STRATEGY CARD
+
EVIDENCE NOTE
+
MACHINE OBJECT
+
REVISION HISTORY

		

Preferred mechanism architecture:

			
CANONICAL MECHANISM PAGE
+
MULTIPLE SUPPORTING CASES
+
COUNTERCASES
+
VALIDATION HISTORY
+
RELATED RECIPES

		

35. Migration Rules

Existing Protocol v1.0 and v2.0 articles should be migrated rather than discarded.

Preserve

Keep:

strategic questions;
accurate research;
useful comparisons;
mechanisms;
validity conditions;
failure modes;
exits;
repair logic;
and strong structural transfers.

Move

Move to a technical page or internal dossier:

full claim ledgers;
source maps;
machine objects;
YAML;
registry recommendations;
complete Strategy Cards;
and production checklists.

Relabel

Change:

ALGORITHM

to:

DECISION PROCEDURE

unless the object is operationally executable.

Change:

VALIDATED

to the correct context-bound validation status.

Replace arbitrary numerical scoring with ordinal gates unless calibrated.

Reclassify

Classify each page as:

			
CASE ANALYSIS
COMPARATIVE ANALYSIS
MECHANISM SYNTHESIS
STRATEGY RECIPE
DOCTRINE
RUNTIME SPECIFICATION

		

Consolidate

Where several source articles contain the same mechanism, connect them to one canonical mechanism page.

For example:

			
LION
HYENA
WOLF
ANT COLONY
DISTRIBUTED TEAM

		

may contribute evidence to:

			
DISTRIBUTED_SENSING
ROLE_SPECIALISATION
CONDITIONAL_RECRUITMENT
COLLECTIVE_CONVERSION

The source names remain aliases.

The mechanisms become the durable infrastructure.

36. Quality-Control Gates

36.1 Output Mode Gate

			
Has OUTPUT.MODE been declared?
Does the output contain only the permitted deliverables?
Does a PUBLIC_ARTICLE stop before the technical bundle?

36.2 Question Gate

			
Is there a real strategic decision?
Is the operator identifiable?
Is the expected decision value clear?
Has the comparison boundary been declared?

36.3 Research Gate

			
Are the central factual claims supported?
Are myths separated from evidence?
Is internal variation included?
Are meaningful exceptions acknowledged?
Are important unknowns visible?

		

36.4 Mechanism Gate

			
Has the article moved beyond description?
Does the mechanism explain how an effect may occur?
Are operational variables identifiable?
Is the mechanism narrower than the total outcome it helps explain?

36.5 Rival Gate

			
Are alternative explanations considered?
Is at least one countercase or failure case examined?
Does the article state what would weaken the conclusion?

36.6 Validity Gate

			
Does the article state when the strategy works?
Does it state when it becomes weak or invalid?
Are required capabilities explicit?
Is the protected base floor defined?

36.7 Transfer Gate

			
Are the source and target domains structurally comparable?
Are key differences acknowledged?
Is the transfer status declared?
Has literal violent or biological imitation been rejected?

36.8 Precision Gate

			
Are numbers calibrated or clearly labelled as illustrative?
Has formal-looking pseudo-science been avoided?
Is the object correctly labelled as principle, procedure or model?

36.9 Exit Gate

			
Are warning signals observable?
Are switch conditions defined?
Are abort conditions concrete?
Is there a repair route?
Are re-entry conditions defined?

		

36.10 Registry Gate

			
Has the novelty gate been applied?
Is the object type correct?
Are existing primitives reused?
Is publication status separate from validation status?

36.11 Publication Gate

			
Can the reader understand the thesis without the machine object?
Does every visible section contribute to the strategic question?
Has unnecessary repetition been removed?
Does the public article stop when the reasoning is complete?

37. Conditions Preventing Mature Publication

Do not publish an article as a completed StrategizeOS object when:

			
It remains only an analogy.
The strategic problem is unclear.
The source case is inaccurately represented.
Internal variation has been erased.
The mechanism has no evidence chain.
Rival explanations are ignored.
The conclusion cannot be weakened by any observation.
The transfer depends mainly on surface resemblance.
Capabilities are missing but execution is still recommended.
The protected base floor is undefined.
No exit or repair route exists.
Arbitrary numbers create false precision.
A checklist is called an algorithm.
A new strategy ID duplicates an existing object.
Violence or coercion is transferred literally.
Validation is claimed merely because the article is published.
A PUBLIC_ARTICLE contains the entire technical warehouse.

		

Use:

			
RESEARCH_DRAFT
SOURCE_VERIFIED
MECHANISM_PROVISIONAL
REQUIRES_FURTHER_RESEARCH
TRANSFER_CAUTION
PILOT_REQUIRED

		

when stronger status is not justified.

38. Master Prompt: Public Article

			
OUTPUT.MODE: PUBLIC_ARTICLE
Write a StrategizeOS Protocol v3.0 public article on:
[INSERT SOURCE CASE, COMPARISON OR STRATEGIC PROBLEM]
Begin by identifying the underlying strategic decision.
Do not assume the source comparison is automatically valid.
Translate the topic into a precise problem involving:
OPERATOR
DECISION
OBJECTIVE
CONSTRAINT
STRATEGIC CONTRAST
EXPECTED VALUE
Define the comparison boundary, including:
SOURCE CASES
UNIT OF ANALYSIS
TIME BOUNDARY
ENVIRONMENT
IN SCOPE
OUT OF SCOPE
OUTCOME BOUNDARY
Conduct deep research using high-quality sources appropriate to each claim.
Separate internally:
1. Direct observations.
2. Interpretation within the source domain.
3. Proposed mechanisms.
4. Cross-domain transfer.
5. Speculative extension.
Examine internal variation.
Do not reduce a species, civilisation, commander or organisation to one
permanent behaviour.
Build an internal evidence dossier containing:
SOURCE MAP
CLAIM LEDGER
SOURCE QUALITY
INFERENTIAL DISTANCE
VALIDATION STATUS
EXCEPTIONS
COUNTEREVIDENCE
RIVAL EXPLANATIONS
UNKNOWNS
PROHIBITED OVERCLAIMS
For every major mechanism, establish:
OBSERVATION
→ DOMAIN INTERPRETATION
→ PROPOSED MECHANISM
→ OPERATIONAL VARIABLE
→ EXPECTED EFFECT
→ DISCONFIRMING SIGNAL
Actively search for rival explanations and countercases.
Extract stable StrategizeOS primitives.
Reuse existing primitives where appropriate.
Do not invent exact numerical weights or thresholds.
Use ordinal gates unless calibration exists.
Label conceptual equations clearly as:
CONCEPTUAL REASONING MODEL
NOT EMPIRICALLY CALIBRATED
NOT A PREDICTIVE EQUATION
Do not call a principle or human judgement process an executable algorithm.
Use:
STRATEGIC PRINCIPLE
DECISION PROCEDURE
EXECUTABLE MODEL
according to its actual level.
Test any cross-domain application for structural equivalence across:
ACTORS
OBJECTIVES
INCENTIVES
INFORMATION
RESOURCES
TIMING
COORDINATION
REVERSIBILITY
ADAPTATION
AGENCY
HARM
ENVIRONMENT
Transfer only the mechanism.
Do not transfer literal violence, coercion, predation or biological morality.
Write a polished WordPress article containing:
1. Title.
2. Opening strategic problem.
3. Strategic Question.
4. Executive Thesis.
5. Why These Cases Matter.
6. Comparison Boundary.
7. What the Evidence Shows.
8. Central Strategic Contrast.
9. Mechanism Beneath the Comparison.
10. Rival Explanations and Countercases.
11. Conditional Decision Rule.
12. When the Strategy Works.
13. When the Strategy Fails.
14. Relevant Cross-Domain Transfer.
15. Limits, Safety and Ethics.
16. Strategic Summary.
17. Compact Research Basis.
Use precise source names in the title.
When a hybrid is created by StrategizeOS rather than directly observed,
state that it is a StrategizeOS synthesis.
END THE OUTPUT AFTER THE PUBLIC ARTICLE.
DO NOT APPEND:
FULL STRATEGY CARD
CLAIM LEDGER
EVIDENCE DOSSIER
YAML
JSON
MACHINE OBJECT
REGISTRY RECOMMENDATION
RUNTIME SPECIFICATION
PRODUCTION CHECKLIST
Prepare these internally where needed, but do not display them in
PUBLIC_ARTICLE mode.

		

39. Master Prompt: Technical Bundle

			
OUTPUT.MODE: TECHNICAL_BUNDLE
Create the StrategizeOS Protocol v3.0 technical bundle for:
[INSERT ARTICLE OR CASE]
Do not reproduce the full public article.
Produce:
1. Technical Identity.
2. Evidence and Validation Note.
3. Claim Ledger.
4. Strategy Card.
5. Machine-Readable StrategizeOS Object.
6. Novelty-Gate Assessment.
7. Registry Recommendation.
8. Required Tests.
9. Revision Triggers.
10. Outcome Memory Fields.
Use honest source-quality, inferential-distance and validation labels.
Do not call the object a runtime unless its inputs, states, transitions,
outputs, warning signals, abort logic and telemetry are defined.
Recommend one of:
REGISTER AS NEW CASE
REGISTER AS NEW PRIMITIVE
REGISTER AS PROVISIONAL LAW
REGISTER AS RECIPE
REGISTER AS DOCTRINE
RETAIN AS RUNTIME CANDIDATE
MERGE WITH EXISTING OBJECT
RETAIN AS UNREGISTERED RESEARCH
REJECT OR RETIRE

		

40. Master Prompt: Full Research Package

			
OUTPUT.MODE: FULL_RESEARCH_PACKAGE
Create two separate StrategizeOS Protocol v3.0 deliverables for:
[INSERT TOPIC]
DELIVERABLE A:
A complete PUBLIC_ARTICLE following the public article master prompt.
DELIVERABLE B:
A complete TECHNICAL_BUNDLE following the technical bundle master prompt.
Do not merge the two deliverables into one ordinary public webpage.
Label each deliverable clearly.
The public article must remain readable without the technical bundle.
The technical bundle must remain useful without reproducing the full article.

		

41. Compact Commission Template

			
STRATEGIZEOS PROJECT
OUTPUT.MODE:
PUBLIC_ARTICLE | TECHNICAL_BUNDLE |
FULL_RESEARCH_PACKAGE | RUNTIME_SPECIFICATION
TOPIC:
[Insert source case or comparison]
STRATEGIC PROBLEM:
[What difficult decision does this illuminate?]
OPERATOR:
[Who must make the decision?]
OBJECTIVE:
[What outcome matters?]
CONSTRAINT:
[What makes the decision difficult?]
SOURCE CASES:
[Cases to investigate]
TARGET DOMAIN:
[Optional transfer domain]
ARTICLE TYPE:
Case analysis | Comparative analysis | Mechanism synthesis |
Strategy recipe | Doctrine | Runtime specification
PUBLIC DEPTH:
Concise | Standard | Flagship
SPECIAL BOUNDARIES:
[Ethical, legal, factual or publication constraints]

		

When only the topic is provided, the first production task is to infer and state the strategic problem.

42. Canonical Closing Principle

Every StrategizeOS investigation should satisfy this sequence:

			
A PROBLEM DEFINES THE SEARCH.
CASES PROVIDE OBSERVATIONS.
RESEARCH TESTS THE OBSERVATIONS.
EVIDENCE CONSTRAINS INTERPRETATION.
INTERPRETATION PROPOSES MECHANISMS.
COUNTERCASES CHALLENGE THE MECHANISMS.
MECHANISMS PRODUCE REUSABLE PRIMITIVES.
PRIMITIVES FORM CONDITIONAL LAWS AND RECIPES.
STRUCTURAL EQUIVALENCE GOVERNS TRANSFER.
CAPABILITIES DETERMINE WHETHER EXECUTION IS POSSIBLE.
PROTECTED BASE FLOORS LIMIT ACCEPTABLE RISK.
EXIT AND REPAIR LOGIC BOUND COMMITMENT.
OUTPUT MODE CONTROLS PUBLICATION.
VALIDATION DETERMINES CONFIDENCE.
OUTCOME MEMORY IMPROVES THE SYSTEM.

		

The final institutional law is:

			
A STRATEGIZEOS PUBLIC ARTICLE EXPLAINS THE MOVE.
AN EVIDENCE DOSSIER SHOWS WHY THE MOVE IS PLAUSIBLE.
A STRATEGY CARD DEFINES HOW THE MOVE MAY BE USED.
A MACHINE OBJECT MAKES THE MOVE RETRIEVABLE.
A RUNTIME SELECTS OR ADAPTS THE MOVE ONLY AFTER ITS
INPUTS, STATES AND TRANSITIONS ARE SUFFICIENTLY DEFINED.
OUTCOME MEMORY DETERMINES WHETHER THE MOVE SHOULD BE
STRENGTHENED, NARROWED, MERGED, REVISED OR RETIRED.

		

StrategizeOS should not become a warehouse of impressive comparisons.

It should become a disciplined library of:

researched cases;
bounded mechanisms;
reusable primitives;
conditional laws;
operational procedures;
validated runtimes;
and continuously corrected strategic memory.

The objective is not to make every article display the entire system.

The objective is to make every conclusion know:

			
WHAT IT IS
WHAT SUPPORTS IT
WHERE IT APPLIES
WHERE IT FAILS
WHAT IT REQUIRES
WHAT IT PROTECTS
WHEN IT MUST STOP
HOW IT CAN RECOVER
WHAT WOULD DISCONFIRM IT
HOW FUTURE OUTCOMES SHOULD CHANGE IT

		

StrategizeOS Article Production Protocol v3.0

Problem-First Research, Mechanism Extraction, Public Publishing, Technical Registration and Strategic Memory

1. Purpose of StrategizeOS

2. The Central Architectural Law

2.1 The Public Article

2.2 The Evidence Dossier

2.3 The Strategy Card

2.4 The Machine Object

2.5 The Runtime

3. Mandatory Output Mode

3.1 PUBLIC_ARTICLE

3.2 TECHNICAL_BUNDLE

3.3 FULL_RESEARCH_PACKAGE

3.4 RUNTIME_SPECIFICATION

4. Core Production Sequence

5. Problem Before Comparison

6. Comparison Boundary

7. Variation Before Archetype

8. Mechanism Before Metaphor

9. Evidence Before Architecture

10. Evidence Classification

10.1 Source Quality

10.2 Inferential Distance

10.3 Validation Status

11. The Evidence Dossier

12. Claim Ledger

13. Evidence-to-Mechanism Chain

Observation

Domain Interpretation

Proposed Mechanism

Operational Variable

Expected Effect

Disconfirming Signal

Transfer Status

14. Rival Explanations Are Mandatory

15. Countercase Testing

16. StrategizeOS Object Taxonomy

16.1 Case

16.2 Primitive

16.3 Law

16.4 Recipe

16.5 Doctrine

16.6 Runtime

16.7 Alias

17. Novelty Gate

18. Precision and Calibration

19. Principle, Procedure and Executable Model

19.1 Strategic Principle

19.2 Decision Procedure

19.3 Executable Model

20. Capability Before Execution

21. Protect the Base Floor

22. Exit, Withdrawal and Repair

23. Structural Transfer Test

24. Article Types

24.1 Case Analysis

24.2 Comparative Analysis

24.3 Mechanism Synthesis

24.4 Strategy Recipe

24.5 Doctrine Article

24.6 Runtime Specification

25. Public Article Architecture

H1: Title

Opening

H2: The Strategic Question

H2: Executive Thesis

H2: Why These Cases Matter

H2: What the Evidence Shows

H2: The Central Strategic Contrast

H2: The Mechanism Beneath the Comparison

H2: What Else Could Explain the Result?

H2: The Conditional Decision Rule

H2: When the Strategy Works

H2: When the Strategy Fails

H2: Transfer into a Relevant Domain

H2: Limits, Safety and Ethics

H2: Strategic Summary

H2: Compact Research Basis

26. Public Article Hard Stop

27. Technical Bundle Architecture