Structure
Structure governs how identities, relationships, queues, data objects, transactions, and persistence paths are organized so that defects cannot hide inside the system’s shape.
STR-01 · MAP-01 — Establish the Complete Identity Universe Before Routing. Build the complete authoritative entity roster and the complete set of routing keys needed for candidate discovery before broad remote resolution begins.
STR-02 · MAP-02 — Preserve Identity Granularity. Keep parent, child, unit, grouped, shared-key, and otherwise distinct entity classes separate whenever collapsing them could create false identity matches.
STR-03 · MAP-03 — Route from a Complete Set-Driven Queue. Generate routing work from the known universe as a set. Do not depend on manually choosing the next entity to resolve.
STR-04 · MAP-04 — Prove Resolver Capabilities. Use multi-entity, multi-key, batch, or grouped resolution only when the underlying operation demonstrably supports it. Never invent unsupported resolver semantics.
STR-05 · MAP-05 — Maintain an Append-Only Candidate and Identity Ledger. Preserve each candidate, its evidence, its disposition, and the final identity decision so the route-selection process remains reconstructable.
STR-06 · MAP-06 — Bind Routes by Exact Authoritative Identity. Promote a candidate mapping to a validated mapping only after exact authoritative identifier equality is established.
STR-07 · MAP-07 — Represent Ambiguity Explicitly. Keep zero-match, multi-match, parent-versus-child, duplicate, and otherwise ambiguous cases unresolved until evidence establishes the correct relationship.
STR-08 · MAP-08 — Manifest Existing Mappings Before Correcting Them. Capture the current mapping and its evidence, revalidate it, and establish that it is invalid before overwriting it.
STR-09 · MAP-09 — Persist Validated Mapping Batches Promptly. Once a bounded mapping batch is independently validated, commit it rather than leaving validated identity decisions unnecessarily exposed to volatile intermediate state.
STR-10 · MAP-10 — Complete Identity Mapping Before Dependent Ingestion. Do not begin broad dependent-data ingestion until the required entity-to-source mapping is complete enough to satisfy the ingestion contract.
STR-11 · MAP-11 — Require a Clean Mapping Reconciliation. A mapping phase is incomplete while any required entity has a missing, incorrect, ambiguous, or duplicate assignment.
STR-12 · MAP-12 — Mutate Only Proven-Bad Mappings. Restrict corrections to values whose invalidity has been manifested and evidenced. Do not rewrite valid mappings for uniformity or convenience.
STR-13 · MAP-13 — Reuse Durable Mapping Evidence. Resume mapping work from durable evidence and fresh reconciliation instead of repeating a complete remote inventory when prior valid evidence remains usable.
STR-14 · SQL-01 — Inspect the Live Data Structure Before Writing. Begin correction work with fresh queries of schema, keys, counts, duplicates, missing values, routes, relationships, and dependent-record integrity.
STR-15 · SQL-02 — Parameterize Values and Inspect Identifiers. Use parameterized statements for data values and derive object identifiers from inspected live structure rather than assumptions or unchecked string construction.
STR-16 · SQL-03 — Avoid Undeclared Persistent Staging. Do not create permanent or globally visible staging objects as an incidental implementation shortcut.
STR-17 · SQL-04 — Bound Write Transactions. Keep each transaction limited to a coherent, reviewable unit of work with a defined commit or rollback boundary.
STR-18 · SQL-05 — Use One Transaction Model. Do not mix incompatible transaction-control approaches. Verify transaction state explicitly using the datastore’s authoritative mechanism.
STR-19 · SQL-06 — Preserve Parent-Child Atomicity. When correctness requires a parent record and its exact dependent set to agree, write them as one atomic unit.
STR-20 · SQL-07 — Bind Children Through the Actual Relationship. Associate dependent rows through the inspected existing key or relationship contract, not through inferred ordering, descriptive similarity, or invented linkage.
STR-21 · SQL-08 — Compare the Complete Prepared Write Before Commit. Compare every prepared scalar value and every dependent set against the intended authoritative state before committing.
STR-22 · SQL-09 — Verify Through a Fresh Read Path. After a write, close or abandon the write-session view and perform exact readback through a fresh connection or independently established read context.
STR-23 · SQL-10 — Never Use a Mechanical Signal as Sole Proof. Counts, HTTP success, checksums, canonical formatting, query success, script exit status, or similar mechanical indicators may support verification but must not alone establish data correctness.
STR-24 · SQL-11 — Commit Verified Good Batches. Persist a validated bounded batch once its commit conditions are met instead of unnecessarily coupling its fate to unrelated future work.
STR-25 · SQL-12 — Make Reapplication Safe. Design writes so rerunning the same validated operation does not create duplicates, drift, cumulative corruption, or additional side effects.
STR-26 · SQL-13 — Preserve Before-and-After Evidence. Record the exact relevant values before and after a mutation together with appropriate fingerprints or hashes.
STR-27 · SQL-14 — Do Not Rebuild the World to Fix a Record. Never reseed identifiers, blanket-delete datasets, reset schema, or perform equivalent structural resets merely to correct bounded data defects.
STR-28 · SQL-15 — Keep Heavy Reconciliation Outside Critical Write Windows. Perform expensive comparisons outside write transactions when possible and inspect query cost before allowing reconciliation work to threaten transactional safety.
STR-29 · SQL-16 — Protect Downstream Contracts. Do not modify downstream consumers, schemas, interfaces, structural conventions, or dependent behavior without separate authorization.
STR-30 · SQL-17 — Enforce Completeness on Records Declared Complete. A record or dependent row may be labeled complete only when every field required by its declared schema-completeness contract satisfies that contract.
STR-31 · SQL-18 — Never Encode Failure as Successful Data. Do not create a synthetic complete record to represent routing failure, parser failure, unresolved identity, or missing authoritative evidence.
STR-32 · SQL-19 — Prove the Write-and-Readback Path Before Scaling. Execute one bounded, reversible, fully manifested example through the complete write, commit, fresh-read, comparison, and rollback-capability path before applying that path broadly.
The Scientific Pathways of Structure
SAT – Structure – Pathways – Universal Pathway Archetypes (the 7 Pathways)
| Archetype | Structural Definition | Organizing Principle | Mechanism Arrangement | State Behavior | Compositional Boundary |
|---|---|---|---|---|---|
| Propagation | Transmission of an existing state variable across space, structure, or time without changing its semantic type. | Continuity of influence. | Sequential chaining of mechanism executions. | State variables persist in kind while changing location, magnitude, or activation context. | Becomes composite if the state is converted, filtered, accumulated, or looped. |
| Transformation | Conversion of one state representation into another, altering the semantic type of the state. | State conversion. | Ordered execution producing a defined input–output mapping. | State variables change type, role, or representational form. | Becomes composite if no genuine conversion occurs or if elimination or feedback dominates. |
| Selection | Reduction of a state space through constraint-based elimination or retention. | Constraint satisfaction. | Branching followed by pruning of admissible states or paths. | State space contracts while remaining states persist unchanged. | Becomes composite if surviving states are transformed rather than merely filtered. |
| Iteration | Repeated application of a mechanism under stable rules. | Repetition under fixed criteria. | Recursive or cyclic execution of the same mechanism. | State variables update incrementally across repetitions. | Becomes composite if iteration alters governing rules or introduces feedback control. |
| Feedback | Causal dependence where later state values influence earlier stages of the same pathway. | Self-referential regulation. | Closed-loop arrangement linking outputs back to inputs. | State variables regulate, amplify, or dampen prior values. | Becomes composite if feedback is broken or if the loop no longer influences earlier stages. |
| Assembly | Construction of higher-order structure from multiple lower-order components. | Structural accumulation. | Convergent arrangement combining multiple mechanism executions. | State variables increase in organization, hierarchy, or relational complexity. | Becomes composite if structure is no longer being built or if decomposition dominates. |
| Regime Transition | Reorganization of the admissible state space or governing dynamics. | Threshold-driven redefinition. | Mechanism execution that alters the active rules, constraints, or attractors. | State variables cross into a qualitatively different regime. | Becomes composite once the new regime stabilizes and other archetypes govern evolution. |