S1000D & IPS User Forum 2026 · Arlington, Virginia
Expanding Standard Numbering System (SNS) across engineering and manufacturing
Wednesday 23 September 2026 · 4:30 pm to 5:00 pm. Bryan Solstin, Systems Architect, dism.dev.
"What is the configuration of that tail number?"
Bottom line up front
Problem. Engineering and support each keep their own breakdown. Translation breaks the traceability ACSAA requires.
Proposal. Expand S1000D's SNS upstream: assign it by pairing it with the AP242 occurrence, carry it unchanged to the field.
Payoff. One nomenclature from EBOM to SBOM. The configuration of any line_number.
Ask. Pilot it on one program with S1000D SNS in the EBOM and MBOM.
Slides (PDF) will be posted here after the talk.
1 · Today's state · why answers drift
Translation is the kiss of death
S1000D's Standard Numbering System (SNS) was designed for technical publications and support. Engineering and manufacturing keep their own breakdowns, proprietary work breakdown structures (WBS), so every configuration answer is a human reconciling three registers and three keys: as-designed (EBOM), as-built (MBOM) and post-production (SBOM). Translation between nomenclatures is ambiguous. Some translations can never be fully resolved, because the breakdowns are un-reconcilable. Integrators learned long ago that translation is the kiss of death.
Most impact-analysis and MDO frameworks spend their effort mapping data, not optimizing. Multi-disciplinary integration is the hard part. Optimization is the easy part. Every handoff between disciplines is the same tax: map, re-validate, repeat.
With every program, some EBOM breakdown never translates into the SBOM. Different nomenclature is the foundational problem. SNS across domains gives one single-source definition, the authoritative source of truth, and eliminates ambiguity.
ACSAA: the regulatory forcing function
The Aircraft Certification, Safety, and Accountability Act (ACSAA), Division V of Public Law 116-260, was enacted 27 December 2020 after the MAX accidents: the Senate reforms Senator Cantwell negotiated with Chairman Wicker. It rewired certification oversight: system-level safety analysis and configuration accountability from type design to the delivered line_number (tail number).
Impact analysis is now law. Sec. 115: a system safety assessment for each significant design change, updated for each later change, at the airplane level. Sec. 117: every change evaluated as an integrated whole aircraft, with its impacts.
Traceability and impact analysis are ACSAA-required: the pathfinder. Military airworthiness (MIL-HDBK-516D) and configuration status accounting (EIA-649C, MIL-HDBK-61B) make the same demand. DoD requires the serialized item's UII under IUID (MIL-STD-130).
ACSAA is the pathfinder and the first step. Loop that same analysis and it is Multi-Disciplinary Optimization (MDO), by people and agents alike.
Door-plug failure in flight, then a fleet grounding. Four post-grounding multi-operator messages (MOMs) were rejected. Incongruent nomenclature was part of the MOM rejections. The 737-9 grounding: $443 million in customer considerations.
Sources: NTSB, Aviation Investigation Report AIR-25-04, 24 June 2025. FAA Emergency AD 2024-02-51, docket FAA-2024-0032, 6 January 2024; FAA statements of 9, 12 and 24 January 2024. Boeing, Form 10-Q, quarter ended 31 March 2024, Note 9.
Different nomenclatures, WBS and SNS, hinder impact analysis. Translation is the challenge.
What happened to the promised physical "digital twin" of each tail number?
2 · The proposal · one model-variant nomenclature, carried everywhere
ACSAA enabled. Translation tax repealed.
Expand S1000D's SNS upstream. Assign the SNS system and subsystem while the AP242 occurrence is authored, before release, and carry it unchanged through the EBOM, the MBOM, the SNS data modules and the SBOM. No mapping. Every discipline optimizes against the single-source definition. One line_number is one query, not layers of filters.
The indented Occurrence List (iOL) is the product's DNA
- SNS is unambiguous nomenclature per model-variant.
- SNS starts in the EBOM and the MBOM: a single-source definition eliminates translation.
- SNS designators, SNS titles and descriptions recur as one pattern across occurrences, parts and geosets (h23).
- Millisecond Postgres search for each occurrence DAG (occurrence, part and geoset) in each domain.
It fits standards you already have
Commercial
The SNS support already publishes against, assigned at engineering release: 57-40-01 in the EBOM is the code the data module carries.
A part number says what was designed; an SNS-keyed occurrence per line_number says where it sits on which airplane.
Military
S1000D sets the SNS through project business rules and maintains example SNSs for air vehicles, engines, ships and ground vehicles.
An NSN identifies the item of supply; the SNS-keyed occurrence identifies the position on the individual aircraft.
Sustainment standards
ISO 10303-239 (PLCS) in service and S5000F for data feedback: the SNS-keyed occurrence passes into both without translation.
Editions: ISO 10303-242:2025, ISO 10303-239:2024, S5000F Issue 4.0 (2025).
Common data model
One record shape in every domain: SNS designator, SNS title, description, occurrence, part, geoset (h23), line_number.
EBOM, MBOM and SBOM share the designators and the sealed geometry. Nothing mapped. Translation eliminated.
STEP AP242: instance versus occurrence
The AP242 instance is the logical class. The AP242 occurrence is the physical model: the occurrence is the physical digital twin. DiSM plus the AP242 occurrence is the physical digital twin across the domains, EBOM, MBOM and SBOM, sealed as delivered and revised only by supersession, never deleted. Legacy cannot do a physical twin across EBOM, MBOM and SBOM without complex translations.
The authority representation is the seat of the authored three-dimensional truth, the artifact from which every derived representation is regenerated. Named examples: STEP AP242, ISO 14306 JT. "Authority" names the role, never a format. A shop may simply say "the AP242 model."
Proposal: assign SNS during EBOM, MBOM and SBOM creation.
Thesis: SNS single-source definitions and the AP242 occurrence physical twin for every tail number. Why not?
3 · A working example · SNS assigned before release, carried unchanged
Some pictures are worth a thousand words
How SNS integrates into engineering: the system and subsystem codes are pull-downs on the occurrence form, chosen while the AP242 occurrence is authored, before release. The designator is composed server-side on save.
The occurrence designator is the search key; any leading substring of it is a query. Milliseconds, up or down the DAG. The DAG is built in a Postgres table, and a Directed Acyclic Graph is ideal for bi-directional navigation.
4 · Rapid ACSAA traceability · what is affected, who authored it, when did it change
Traceability held by the structure
What SNS, occurrence and DAG give you
The iOL is the whole article. The iOL is the vehicle's DNA: the complete as-delivered structure, and the sealed DAG extends or links to the current h23 (hashed 2D and 3D).
No third party required.
What ACSAA asks for
Traceability held by the structure. Nothing is overwritten. Revisions layer on top, so who changed it, when, and under whose authority ride in the data itself.
Impact analysis that finishes. Change one occurrence and the affected set is every occurrence up its next-higher-indent (nhi) chain to the aircraft. The DAG is acyclic and configured-complete: the walk terminates, with no legacy one-to-many or many-to-many links to resolve on the way.
With a few SNS keystrokes, the DAG is the basis for fast, contextual 3D visualization. The indented Occurrence List (iOL) is on-demand DNA for every line_number.
Sealed, revised by supersession (immutable)
authority representation
h23 is the authored 2D POV and 3D truth, generated from the authority. Authority examples: STEP AP242 · ISO 14306 JT.
h23
2D-3D hash. A bucket of h23s is interoperable across the work-in-progress DAGs. After pubkey sigs (attestation), the DAG-h23 freezes the one-to-many relationships into a simple, bi-directional index. SNS is the DAG's systemic heart.
authority_sheet
The spreadsheet UI provides access to the highlighted occurrence. A person or agent, with proper pubkey attributes, has access to change authoritative geometry. Easy MDO for persons or AI agents.
The table versus the source: PCT and the DiSM DAG
PCT: S1000D's product cross-reference table, the data module that lists product instances (tails) and their attribute and condition values so a viewer can filter publications. DiSM DAG: the sealed DAG of AP242 occurrences per line_number.
| PCT (product cross-reference table) | DiSM DAG (sealed AP242 occurrences) | |
|---|---|---|
| One row is | one product instance: a tail or serial number | one sealed AP242 occurrence on one line_number: the AP242 occurrence physical twin |
| It holds | attribute and condition values used to filter publications (model, variant, modification state) | structure (iOL), position (nhao, varnhao), geometry (h23), install moment, signer, supersession |
| Keyed by | a product instance identified by attributes the ACT declares (for example serial number) | the SNS occurrence designator plus line_number |
| Kept current by | people, issuing a new version of the data module after the fact | the act itself: each row sealed and signed as it happens, never edited, only superseded |
| Trusted because | someone maintains it and someone checked it | it is content-addressed and signed per pubkey, verified at the receiving node |
| It answers | which data module applies to this tail? | what is on this line_number, where, since when, under whose authority, and what a change affects |
| Relationship | a projection of the DAG: generated output where a legacy viewer still needs one | the source |
Applicability is answered from the iOL source. The PCT's maintained table is one more translation.
No sign-in. Nothing to steal. Proof rides every act.
Who changed what, in which system, under whose authority: cryptographically signed per pubkey sig, sealed with SNS system and subsystem addressing. Access is granted per domain and organization; a pubkey grid says which domains and organizations a key may touch, per model::variant. SNS addresses each record in the Postgres tables.
Every DiSM node verifies without a third party. Pubkey access, no central grant server. sealed · alive · cleared · seated · latest: five checks descending document → section → row, run at the receiving node against its own registry and its own authorization state, never the sender's claims. Refusals are named, replays are inert, and every node converges to the same answer without coordination. Trust is computed (verified) at the receiving end.
Why the regulator cares. Revocation and supersession are one-way and provable: the evidence survives the loss of any single system. Traceability that travels with the data, across the distributed enterprise. What sign-in promised, the signature delivers, per act. Dismkey retires the account: OEM, supplier and operator sign one another's work with nothing to provision, reset or steal.
Scope of the claim: authentication, authorization and integrity. Confidentiality is a separate concern.
Interoperable people and agents
Pubkey sigs, multi-sigs (attestations), pubkey access: one protocol for both. A person pubkey and an agent pubkey are the same. A person or an agent signs without ambiguity, during or after a sig or multi-sig event. One pubkey revocation ends access but not history. One handshake, and every DiSM node gets the required attributes for need-to-know communications. MDO by people and agents alike. Is pubkey person-agentic interoperability the next black-powder revolution?
ao · nhi · nhao · varnhao: DiSM's canonical contextual-architecture
| shorthand | formal written and meaning | pronounced (spoken contexts only) |
|---|---|---|
| ao | axis-origin, congruent and unchanged | "ayoh" |
| nhi | Next-Higher-Indent | N-H-I (said as letters) |
| nhao | Next-Higher-AO (Axis-Origin) | "next-how" (spoken slang) · Next-Higher-AO (formal) |
| varnhao | Vector-And-Rotation-to-Next-Higher-AO | "varn-how" (spoken slang) · formal in full |
nhi places you in the indented occurrence list; nhao and varnhao enable an exact transformation: vector-and-rotation, always bottom-up, from your vantage point. A nhao-varnhao combination provides two definite axis-origins (AOs), enabling definite transformation intrinsic within a DAG.
No root ao, no master axis-origin. nhi: next-higher indent, your place in the list. nhao: next-higher axis-origin. varnhao: the vector and rotation into it. The two, plug and play anywhere, from your vantage: no permission from the possibly-frozen higher-up. Think of nhao and varnhao as bottom-up, plug-and-play "valence electrons".
SNS plus DAGs give highly interoperable 3D and 2D POV models, with millisecond search up or down the DAG. The same nhao and varnhao method can track a solar ao for simulated natural lighting any day of the year, land-based assets, mobile assets, and satellites in real time. Drawings are derived from digital-twin points of view: six old-school, six-sided POVs (front, right, back, left, top, bottom) plus custom, by minimal ao-to-ao transformations. No kernel needed at the consumer: consumption is sealed bytes and stored values.
What SNS in the AP242 occurrence, DAG and Dismkey delivers
- Distributed indented State-Machine (DiSM) reduces attack surface. Nodes and access are distributed.
- Fast ACSAA-required traceability.
- Fast ACSAA impact-analysis compliance, across domains.
- And Multi-Disciplinary Optimization (MDO), by looping impact analysis: ACSAA's requirement is the pathfinder, MDO the overlay, by people and agents.
- SNS-DAG search with AP242 occurrences, providing definite, on-demand, post-production configurations.
- Accurate vehicle health monitoring and preventative maintenance, per line_number.
- Pubkey sigs: agent-person interoperability.
- SNS interoperability · ACSAA traceability · ACSAA impact analysis · agentic-pubkey interoperability · MDO.
The ask
Is SNS across EBOM, MBOM and SBOM already a strategic direction?
Commercial
Pilot one SNS program.
Assign the SNS systems and subsystems in the EBOM, MBOM and SBOM.
Military
A program pilot with a serialized fleet: SNS-keyed occurrences per tail.
A configuration status accounting comparison on one modification: the sealed DAG against the configuration status accounting (CSA) record.
S1000D council
A change proposal (CPF) recommending SNS assignment at engineering release.
Author once, trust everywhere.
DiSM.dev is committed to public domain, Open-Source Protocol in 2046.
Say no to software as a service (saas). No third party required. No central grant server. No sign-in.
Bryan Solstin · contact
Speaker
Bryan Solstin
Bryan Solstin is the Systems Architect at DiSM (dism.dev), a distributed, single-nomenclature configuration-management architecture that extends S1000D's Standard Numbering System (SNS) upstream into Product Development (PD): engineering and manufacturing authoring. His career was spent in Boeing Product Development, as a senior PD propulsion engineer and a senior PD engineer in customer support, and he brings extensive Dassault Systèmes PLM-CAD experience from the PD authoring side. At DiSM, Bryan is now focused on distributed PD configurations, starting with a common breakdown nomenclature. He holds a B.S. in Mechanical Engineering from Brigham Young University. Bryan is also a U.S. Patent Agent and recently filed four patent applications pertaining to this work.
Patent Pending. U.S. Patent Application Nos. 19/799,002; 19/799,005; 19/799,007; and 19/799,009.
Contact
For inquiries or collaboration: