Structural intelligence makes persistent state operative
Domain deliberation asks which software design is sound, what market Evidence implies, which itinerary satisfies a user's constraints, or which treatment options a qualified human should evaluate. System or Structural Intelligence operates on the architecture that carries those questions: it traces support, derives impact, manages conditional contexts, compiles Context, evaluates structural readiness, and preserves consistency across several semantic authorities. This layer does not solve the domain problem in place of a researcher, architect, solver, or human Decision authority. Its purpose is to keep the accepted structure coherent enough that each Resource can work from explicit state instead of reconstructing the project from prose. Without that capability, durable semantic state remains a database that smarter models periodically reinterpret; with it, the state itself can direct attention, expose consequences, and continue evolving while cognition is paused.
One state supports several typed views
The persistent system cannot be reduced to one relation vocabulary. The same accepted objects participate in several coupled views:
Commitment and Work
Epistemic support
Scenario and SemanticContext
Responsibility and coordination
Capability and Resource
Authority and Policy
Memory and User state
Evidence and Obligation
Domain and world models
Event and ProvenanceA single Decision can govern Work, depend on an Assumption, be accepted by a human, create an Obligation, and carry provenance from a particular Reasoner. Stable object identity connects those views, while typed relations preserve their different laws. These views may share one physical database, span several services, or be materialized on demand. The storage layout is secondary to semantic ownership. Commitment and Work authority admits changes to accepted work; the epistemic authority owns claims and support; Memory owns retained experience; Responsibility and Governance own assignments and permission; Assurance owns Verification and Closure records. Cross-view consistency follows from shared identity, explicit transitions, and dependencies rather than from treating every edge as interchangeable.
Accepted state, projections, and assessments have different status
Structural Intelligence distinguishes what the system has accepted from what it derives for current use. Canonical state contains durable objects such as Commitment, Decision, Assumption, Unknown, ResponsibilityAssignment, AuthorityEnvelope, WorkNode, Obligation, Evidence, MemoryItem, Policy, and DomainModel revision. Those objects change only through admitted semantic transitions.
A deterministic projection is reproducible from identified revisions. DependencyReadiness, ClosureEligibility, Staleness, and ImpactSet belong to this class. Caching a projection does not create a second source of truth; when an input changes, the value must be recomputed, invalidated, or explicitly accepted as stale under Policy.
A policy-derived projection or cognitive assessment evaluates accepted state for a purpose. Frontier, ResourceEligibility, AttentionPriority, MemoryRelevance, RiskAssessment, ResourceSuitability, and PreferenceInference may depend on Policy, a Reasoner, current time, or a particular responsibility. They therefore retain source revisions, purpose, Policy or model revision, confidence, and freshness.
Every material derived value should be able to answer:
derived from which revisions?
under which Policy or model?
compiled when?
for what purpose?
with what freshness?This distinction also separates Provenance from Justification. Provenance explains how an object appeared: producer, activity, Source, inputs, time, and derivation. W3C PROV provides a mature vocabulary for those relations.[1]Provenance, workflow semantics, and process conformancesourceOpen bibliography entry → Justification explains why the object is currently treated as believed, effective, applicable, or verified. A Source snapshot can have impeccable provenance and already be obsolete; a Decision can remain normatively effective after one part of its rationale weakens. The system needs both accounts.
Support and validity direct local revision
There is no universal supports edge because epistemic, normative, work, Decision, and causal relations produce different consequences.
| Family | Examples |
|---|---|
| Epistemic | epistemically_supported_by, derived_from, assumes, contradicted_by, corroborated_by |
| Normative / Authority | authorized_by, required_by_policy, accepted_by, delegated_by |
| Decision | motivated_by, selected_over, reconsidered_due_to |
| Work | depends_on, blocks, requires, satisfies |
| Causal | causally_influences, causally_requires |
Causality belongs to an explicit causal or DomainModel. An epistemic claim supporting a Decision does not establish that the claim physically caused an outcome, while an authorized Decision does not become epistemically true because the right person accepted it.
Validity follows the same discipline. One object can carry EpistemicValidity, NormativeValidity, AuthorityValidity, TemporalValidity, ContextValidity, and VerificationValidity at the same time. Suppose an authorized architecture owner accepted Decision D4 and a later Observation weakens an Assumption in its rationale. The correct state may be:
D4 remains effective
AND
D4 requires reconsiderationDeleting D4 would let epistemic revision override legitimate organizational authority; ignoring the new Evidence would let normative continuity conceal a weakened basis. Typed validity preserves both facts and gives Policy a precise place to define what may continue while reconsideration is open. Doyle's Truth Maintenance System separated the problem solver from a subsystem that recorded reasons for beliefs and revised dependents when assumptions changed.[2]Truth maintenance, cognitive architectures, and metacognitionsourceOpen bibliography entry → De Kleer's ATMS extended the idea to several simultaneous assumption environments.[3]Truth maintenance, cognitive architectures, and metacognitionsourceOpen bibliography entry → Persistent Semantic Agency carries related support semantics across Decisions, Work, Responsibility, Authority, Evidence, and Closure. Consider one accepted chain:
Assumption A1
supports Decision D4
which governs Work W9
whose Evidence supports Verification V7A contradictory Observation first produces typed impact rather than a global replan:
A1 → INVALIDATED
D4 → RECONSIDERATION_REQUIRED
W9 → IMPACT_ANALYSIS
V7 → NEEDS_REVERIFYDescendants can become UNAFFECTED, STALE, NEEDS_REVERIFY, NEEDS_RECONSIDERATION, NEEDS_RECOMPILE, or INVALID. Alternative or independent support may preserve some of them. Cognition is then allocated to the affected region, while completed work outside that region remains valid.
Support strength and independence determine how far the revision travels. A hard Assumption dependency, alternative support, corroborating Evidence, soft rationale, and reconsideration trigger should not share one invalidation rule. Five articles repeating one upstream report are not five confirmations, and two agents using the same model, Context, and Source lineage may not provide independent review. The support system therefore preserves common provenance, shared data origin, model generation, and authorship. It also needs relation-specific cycle policies so that a model-generated Memory cannot gain strength merely because another model retrieves and cites it.
SemanticContexts preserve conditional reasoning
The system may reason within several conditional environments:
ACTUAL_ACCEPTED
ASSUMPTION_ENVIRONMENT
FORECAST_SCENARIO
DESIGN_ALTERNATIVE
COUNTERFACTUAL
EXPERIMENTALAn Unknown records that the system does not know; an Assumption temporarily treats a proposition as true for specified reasoning; an Alternative is a candidate choice; a Scenario describes a materially different conditional world. Preserving those distinctions prevents a speculative design from appearing as accepted reality and prevents missing knowledge from becoming an invisible premise. One law controls the boundary:
A result valid only in a hypothetical SemanticContext cannot directly authorize an irreversible action in the actual world. Promotion into
ACTUAL_ACCEPTEDrequires an explicit transition and the relevant admission. Context lineage must survive retrieval, Memory, Delegation, Decision analysis, and later revision so that a conclusion never loses the conditions under which it was valid. The architecture materializes a SemanticContext only when alternative premises change a Decision, Work region, Risk, Outcome, or Obligation. It does not enumerate every combination of uncertainty. When one result remains valid across several contexts, the system may lift it to a common ancestor if the semantics justify that move. Lazy materialization and context lifting preserve conditional reasoning without allowing scenario growth to consume the architecture.
Frontier and Context are compiled projections
The Work Frontier is the current set of semantically admissible and potentially useful advances:
resolve Unknown U
reobserve Source S
request HumanDecision D
refine Work W
perform Transformation T
delegate Responsibility R
reverify Obligation O
reconsider Decision D
wait for Event EIt is derived from Work, Dependencies, Unknowns, Decisions, Authority, Resources, time, Policy, Commitments, and SemanticContexts. WAIT can be the correct Frontier state, because a persistent system can remain responsible without repeatedly spending model inference to discover that nothing material has changed. When accepted state changes, the Frontier changes through projection; no scheduler needs to own it as a primary queue.
The Context Compiler performs a related operation for one cognitive or execution responsibility. It compiles Work semantics, parent Commitment, Decisions, Unknowns, epistemic state, MemoryRecallSet, UserModelSlice, DomainModelSlice, Policies, Authority, Procedures, Capabilities, and expected Result and Verification requirements. Purpose, privacy, Trust and Influence labels, relevance, budget, and instruction-composition rules determine what enters the ContextPack and what remains excluded. The resulting Context is temporary, versioned, attributable, and rebuildable from its source revisions.
Semantic change is admitted, concurrent, and convergent
Authoritative state changes through a governed path:
current canonical revisions
→ stimulus, cognition, Observation, or human act
→ ProposedSemanticChange
→ schema validation
→ Authority and Policy admission
→ support and Context validation
→ revision-precondition and conflict check
→ accepted revision
→ dependency impact
→ projection invalidation
→ semantic eventsA proposal records its proposer, base revisions, requested changes, rationale, Evidence, and claimed Authority. Rejection preserves the proposal as a provenance-bearing Artifact; acceptance creates new immutable revisions under the semantic authority that owns the changed objects.
Schema validity is not semantic validity
A schema can establish that a proposal is structurally admissible to inspect; it cannot establish that the proposal faithfully represents the underlying reasoning or the world. A mistaken or manipulated Resource can produce valid identifiers, recognized relation types, a plausible rationale, and an internally consistent support graph while omitting a material Assumption, overstating Evidence, or suppressing a Contradiction.
Admission therefore treats structure as one check among several. It evaluates the externalized claims against authoritative Observations, explicit support and Source lineage, domain invariants, independence requirements, and Risk-appropriate deterministic or human review. When those checks cannot establish sufficient support, the correct outcome is provisional state, a new Unknown, or rejection—not canonical certainty. The architecture does not require access to private chain-of-thought: the reviewable object is the semantic claim and the Evidence, assumptions, dependencies, Context, and Authority by which it seeks admission.
Illustrative serialization, not a normative API, storage schema, or wire format. The example shows semantic relationships and admission behavior; implementations may serialize them differently.
proposal:
id: PSC-17
proposer: resource:architecture-reviewer@r4
purpose: reconcile notification-provider semantics
semantic_context: ACTUAL_ACCEPTED
base_revisions:
commitment: C-12@v3
assumption: A1@v2
decision: D4@v4
work: W9@v5
verification: V7@v1
trigger:
observation: O88@v1
requested_changes:
- revise_validity:
object: A1@v2
epistemic: INVALIDATED
because: contradicted_by O88@v1
- revise_validity:
object: D4@v4
normative: EFFECTIVE
epistemic: RECONSIDERATION_REQUIRED
- revise_state:
object: W9@v5
state: NEEDS_RECOMPILE
- revise_state:
object: V7@v1
state: NEEDS_REVERIFY
- create:
type: Unknown
id: U23
question: Which provider acknowledgement point is authoritative?
support:
- from: A1@v2
relation: contradicted_by
to: O88@v1
evidence:
- E44@v1
authority_claim:
assignment: RA9@v2
scope: architecture.notification-delivery
expected_impact:
preserve:
- W10@v3
- W11@v2
reconsider:
- D4@v4
recompile:
- W9@v5The corresponding AdmissionDecision can accept the observed contradiction and local impact without pretending that a replacement architecture Decision has already been proven:
admission:
proposal: PSC-17
decision: ACCEPT
checks:
schema: PASS
authority: PASS
base_revisions: CURRENT
source_authority: PASS
observation_freshness: PASS
evidence_eligibility: PASS
support_consistency: PASS
domain_invariants: PASS
independence: REQUIRED_FOR_NEW_DECISION
admitted_revisions:
- A1@v3
- D4@v5
- W9@v6
- V7@v2
- U23@v1
semantic_outcome:
decision_effective: D4@v5
reconsideration_required: true
follow_up:
- independent review before a replacement Decision becomes effectiveThe example also shows what schema validation does not prove. It does not prove that O88 is authoritative, that E44 is sufficient, or that contradicted_by is the correct relation; those remain separate admission checks. Acceptance need not collapse validity into one Boolean: D4 can remain normatively effective while its epistemic basis requires reconsideration.
Admission is federated by ownership. Shared laws do not require one global service or database to approve every change. Each scoped authority admits changes to its own semantics, while a logical SemanticChangeSet coordinates changes that cross domains. “Cancel the trip and never book this class automatically again” may affect Commitment, Work, Authority, Policy, Delegation, and Preference; the implementation may use a transaction, saga, or another consistency mechanism, but logically inconsistent partial acceptance remains invalid. Close contemporary work narrows the novelty claim. Authority at Commit Time implements proposal-producing agents, declared dependency manifests, current-state verification, selective stale-work rejection, and an authoritative durability boundary.[4]Capability security and authorizationsourceOpen bibliography entry → Its design uses one logically authoritative effect service; the proposal here generalizes admission across several scoped authorities. iCORE couples an observable cooperation graph, an evolving Obligation graph over Work and assignments, and an audit map linking transitions to verifiable properties and Evidence.[5]Obligations, accountable coordination, and closed-loop governancesourceOpen bibliography entry → It establishes a close precedent for coupling Work, Responsibility, Obligations, and Evidence without constituting the complete agency architecture described here. Concurrent cognition adds revision semantics. A ProposedSemanticChange identifies the base revisions it assumed; if another transition changes those revisions before admission, the result becomes explicit:
ACCEPT
MERGE
REBASE_REQUIRED
CONFLICT
REJECT_STALESemantic events retain causal lineage for deduplication, loop detection, audit, replay, and impact analysis. An event-driven system also needs convergence controls: same-state suppression, event identity, reaction generations, bounded reaction budgets, cooldowns, fixed-point or quiescence detection, and escalation for unresolved oscillation. The exact algorithms are implementation choices; the requirement is that reactive components cannot make semantic state oscillate indefinitely without detection.
Reconciliation keeps the system coupled to reality
The system preserves accepted intent and observed history as separate records. Process mining and conformance checking provide a mature precedent for comparing normative models with event logs and treating deviation as diagnostic information.[6]Provenance, workflow semantics, and process conformancesourceOpen bibliography entry → When an Observation diverges from expectation, Structural Intelligence determines whether the difference is immaterial, eligible Evidence, a Contradiction, an Impasse, a reconsideration trigger, or remediation Work.
A payment call that times out illustrates the boundary. The effect becomes AMBIGUOUS_EFFECT; Reconciliation Work obtains an authoritative Observation before the system retries, compensates, or continues. The intended state is not rewritten to make history appear compliant, and the executor's report is not used as a substitute for the world.
Materiality keeps this machinery usable. File reads, search queries, local calculations, retries, and intermediate thoughts may remain executor-local or available only in audit traces. A change enters durable semantic state when it can affect Commitment, Decision, Authority, Responsibility, Obligation, future Work, Memory, Risk, Closure, or a consequential external effect. Modules and Policies can refine that boundary, but they cannot conceal events required for Authority accounting, security, Evidence provenance, external effects, or mandatory audit.
Graph Engineering is a signal of the transition
The 2026 paper Graph Engineering in the Era of LLM Agents describes a movement from individual agent capability toward System Intelligence through task-organization, agent-coordination, and runtime-state graphs, with directions including ontology engineering, graph-native operating systems, and system evolution.[7]Graph Engineering and agent operating systemssourceOpen bibliography entry → Persistent Semantic Agency agrees with that direction and makes the ontology more demanding. The structural substrate includes Commitments, typed epistemic and normative validity, Memory, independent Responsibility, compositional Authority, DomainModels, Evidence, Closure, and semantic admission alongside tasks, agents, and runtime state. Graphs make those relations inspectable. Their types, ownership, and transition laws make them an architecture.
System Intelligence maintains the structure through which distributed cognition remains coherent across time.