IRN Engines

Several different operations lie between a collection of messages and a strategic recommendation. A narrative must be identified, its supporting actors examined, its relevance estimated, the need for an alert considered and the basis for possible actions assessed. Presenting that entire process as a single answer makes it difficult to identify where an assumption entered or evidence is missing. The IRN engine architecture separates these operations so that the reasoning can be reviewed.

Each engine has a bounded responsibility and output. Reading organises narratives; Actors describes relationships and forms of influence; IRN synthesises variables; Alerts interprets changes of state; Recommendations ranks options; Memory preserves the analytical history. This design proposal can be illustrated through a hypothetical situation involving repeated service interruptions. A technical-fault explanation coexists with an interpretation of neglect while a user association gathers accounts. Following that case shows what each operation contributes. The example describes the logic of the architecture rather than a measured performance result.

Reading without confusing coherence with truth

The Reading engine starts with posts, documents or records. It looks for groupings that share a problem, a causal attribution, an evaluation or a demand. The technical formulation combines signals such as textual similarity, shared vocabulary, repetition and persistence. These signals help describe the shape of a narrative; they neither verify its factual claims nor fully explain its meaning.

In the hypothetical case, Reading could distinguish the complaint about the interruption from the attribution of neglect and show the messages supporting each interpretation. Some material reproduces a headline; other posts describe different experiences. Grouping all of it as independent testimony would overstate the observed support. The useful output is more than a narrative label. It is a brief description accompanied by the material that allows it to be accepted, challenged or corrected.

Recognising actors and relationships

The Actors engine asks who originates, amplifies, legitimises or challenges the narrative. The architecture distinguishes legitimacy from amplification capacity. Reach is not the same as standing to address an issue. In the example, the association may gather user experiences; a specialist may discuss technical explanations; someone reproducing the report contributes to its circulation. The output should preserve those differences and identify the relationship to the incident supporting each role. Bridges between communities and the convergence of previously separate actors also matter.

Network measures and activity patterns approximate those relationships. Temporal coincidence or duplication may justify closer inspection, but neither proves deceptive coordination or automated behaviour on its own. Likewise, an estimate of legitimacy describes criteria applied in a particular context rather than certifying the truthfulness of a person or institution. Maintaining these distinctions prevents a provisional classification from becoming an accusation.

Separating the index from the alert

The IRN engine normalises variables and calculates a synthesis of risk. Alongside the score, it should return contributions and triggered rules. In the example, an explanation could distinguish repeated accounts, the challenge to promised service continuity and information still missing about the causes. An absence of historical information should not be presented as established trust. The index from 0 to 100 synthesises signals under a model configuration; it does not represent a probability of crisis. Its explanation preserves the reasons needed to interpret the result.

Alerts addresses time and operational state. A stable score and a rapidly rising one may require different attention. The design considers the rate of change, confidence in the interpretation, exposure and adoption by relevant media or actors. In the hypothetical case, an alert could request a review of the recurring incident and the association's complaint while the cause remains unverified. That output identifies what needs attention and what is still unresolved. The possibility that the interpretation of neglect will gain support is a hypothesis about developments, not an event the alert should treat as having already occurred.

Recommending under conditions

Recommendations ranks courses of action by estimated impact, urgency, certainty and feasibility. It also considers factual verification, the availability of responsible people and the risk of an adverse reaction. For the example, it could propose checking the incidents, gathering confirmed information and assigning someone able to answer technical questions. The options should identify the information they depend on. Reporting on how the problem is being addressed may be justified before a definitive cause can be stated. Urgency in analysing the case can coexist with caution in explaining its causes.

The value of separation becomes visible when a disagreement arises. Imagine that the first reading treats reproductions of the headline as independent experiences and a review detects the mistake. Correcting the grouping changes the available evidence about support for the narrative. That alone does not remove direct testimony or resolve the service interruption. Actors and IRN should review the conclusions that depended on that assumption; Alerts and Recommendations should check whether their reasons still hold. The review can reduce an overstated interpretation without turning it into a declaration that no problem exists.

Memory and the possibility of correction

The Memory engine preserves narratives, analysis versions, alerts, decisions and recorded outcomes. In the example, it should make the initial reading, the reason for correction and the decisions retained or changed afterwards retrievable. Keeping only the latest version would erase the most important learning. Similarity to an earlier case offers a reference, but actors, evidence and context need a fresh assessment. Memory makes reasons and mistakes retrievable alongside conclusions.

The contribution of this architecture is to allow a correction to be located and its consequences followed. An error in recognising a narrative should neither remain hidden inside a final recommendation nor require discarding evidence that was sound. Returning from a decision to its documents and rules makes it possible to identify what needs review. Separating engines becomes meaningful when it distinguishes which conclusion changes, why it changes and which human decision needs reconsideration.