DIDO Solutions technical documentation and FX Demo knowledge base https://wiki.didosolutions.com/ 2026-10-21T18:52:30+00:00 https://wiki.didosolutions.com/ https://wiki.didosolutions.com/_media/wiki/logo.png text/html 2026-09-15T17:15:51+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-001-xmi-representation-of-omg-language-models?rev=1789492551&do=diff GPR-001 — XMI Representation of OMG-Language Models Go to Annex C: Requirements Statement A Submission containing models expressed using an OMG modeling language SHALL include a machine-readable OMG XML Metadata Interchange (XMI) representation of those models. Requirement Level Mandatory Rationale A machine-readable XMI representation enables exchange, processing, validation, comparison, and review of models expressed in applicable text/html 2026-09-15T17:16:15+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-002-xmi-representation-of-non-omg-language-models?rev=1789492575&do=diff GPR-002 — XMI Representation of Non-OMG-Language Models Go to Annex C: Requirements Statement A Submitter using a non-OMG modeling language SHOULD make a best effort to include a machine-readable OMG XML Metadata Interchange (XMI) representation of the models. Requirement Level Recommended Rationale An XMI representation may improve model accessibility, interchange, comparison, and evaluation even when the original model is expressed using a non- text/html 2026-09-15T17:28:41+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-003-pim-to-psm-mapping-definition?rev=1789493321&do=diff GPR-003 — PIM-to-PSM Mapping Definition Go to Annex C: Requirements Statement A Submission that specifies a Platform Independent Model (PIM) and one or more corresponding Platform Specific Models (PSMs) SHALL reference an applicable standard mapping or specify the rules used to map the PIM to each PSM. Requirement Level Mandatory when applicable text/html 2026-09-15T17:29:02+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-004-pim-to-psm-normative-authority?rev=1789493342&do=diff GPR-004 — PIM-to-PSM Normative Authority Go to Annex C: Requirements Statement A Submission that specifies a Platform Independent Model (PIM) and one or more corresponding Platform Specific Models (PSMs) SHALL identify whether the mapping rules or the resulting PSMs govern resolution of inconsistencies between them. Requirement Level text/html 2026-09-15T17:37:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-005-precise-and-functionally-complete-submission?rev=1789493823&do=diff GPR-005 — Precise and Functionally Complete Submission Go to Annex C: Requirements Statement The Submission SHALL be precise and functionally complete. Requirement Level Mandatory Rationale A precise Submission defines its normative concepts, relationships, constraints, behaviors, and conformance conditions without material ambiguity. text/html 2026-09-15T17:37:21+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-006-implementation-assumptions-and-context?rev=1789493841&do=diff GPR-006 — Implementation Assumptions and Context Go to Annex C: Requirements Statement The Submission SHALL identify the assumptions and provide the contextual information necessary to implement the specification. Requirement Level Mandatory Rationale Unstated assumptions can cause independent implementers to interpret the same specification differently. Missing contextual information can also make otherwise precise requirements difficult to apply. text/html 2026-09-15T18:32:24+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-007-reuse-of-existing-standards?rev=1789497144&do=diff GPR-007 — Reuse of Existing Standards Go to Annex C: Requirements Statement The Submission SHALL reuse applicable existing OMG and other recognized standards rather than define new models that provide equivalent capabilities. Requirement Level Mandatory Rationale Reusing established standards promotes interoperability, consistency, implementation reuse, and compatibility with the existing standards ecosystem. It also reduces the risk of introducing overlapping concepts, conflicting defini… text/html 2026-09-15T19:06:22+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-008-required-changes-and-extensions-to-existing-omg-specifications?rev=1789499182&do=diff GPR-008 — Required Changes and Extensions to Existing OMG Specifications Go to Annex C: Requirements Statement A Submission that requires a change or extension to an existing OMG specification for its adoption SHALL identify, justify, and fully specify each required change or extension. text/html 2026-09-15T19:13:32+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-009-context-independent-functional-factoring?rev=1789499612&do=diff GPR-009 — Context-Independent Functional Factoring Go to Annex C: Requirements Statement The Submission SHALL separate functionality reusable across multiple contexts from functionality specific to an individual context. Requirement Level Mandatory Rationale Define functionality that applies across multiple contexts once and reuse it. Repeating equivalent functionality within context-specific models creates duplication, increases maintenance effort, and allows inconsistent definitions to … text/html 2026-09-15T19:13:50+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-010-separate-specification-of-reusable-elements?rev=1789499630&do=diff GPR-010 — Separate Specification of Reusable Elements Go to Annex C: Requirements Statement The Submission SHALL specify reusable Models, Interfaces, and related elements as distinct, independently referenceable specification elements. Requirement Level Mandatory Rationale A reusable element must be identifiable independently of the particular context in which it is used. Distinct and independently referenceable specification elements can be cited, governed, versioned, implemented, tested… text/html 2026-09-15T19:18:10+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-011-necessary-normative-dependencies?rev=1789499890&do=diff GPR-011 — Necessary Normative Dependencies Go to Annex C: Requirements Statement The Submission SHALL introduce a normative dependency on another specification only when that dependency is necessary to satisfy an applicable requirement or provide a required capability. Requirement Level text/html 2026-09-15T19:18:34+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-012-avoidance-of-gratuitous-reuse?rev=1789499914&do=diff GPR-012 — Avoidance of Gratuitous Reuse Go to Annex C: Requirements Statement The Submission SHOULD avoid reusing a specification when that reuse introduces unnecessary functionality, constraints, or dependencies. Requirement Level Recommended Rationale Reuse can reduce duplication and improve interoperability, but reuse is not beneficial when a specification introduces capabilities, constraints, implementation assumptions, or dependencies unrelated to the architectural need. text/html 2026-09-15T19:29:07+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-013-compatibility-with-existing-standards?rev=1789500547&do=diff GPR-013 — Compatibility with Existing Standards Go to Annex C: Requirements Statement The proposed specification SHALL be compatible with and usable alongside applicable existing OMG specifications and specifications published by other recognized standards bodies. Requirement Level text/html 2026-09-15T19:29:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-014-combined-use-of-complementary-specifications?rev=1789500565&do=diff GPR-014 — Combined Use of Complementary Specifications Go to Annex C: Requirements Statement The proposed specification SHOULD support combined use with separate specifications that provide distinct, complementary functionality when such combined use is applicable. Requirement Level text/html 2026-09-15T20:21:54+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-015-multiple-conforming-implementation-approaches?rev=1789503714&do=diff GPR-015 — Multiple Conforming Implementation Approaches Go to Annex C: Requirements Statement The proposed specification SHALL permit multiple implementation approaches capable of satisfying its normative requirements. Requirement Level Mandatory Rationale Permitting multiple conforming implementation approaches preserves implementation flexibility, supports technological innovation, and avoids coupling the specification to a particular product, platform, architecture, or deployment appro… text/html 2026-09-15T20:22:26+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-016-avoidance-of-normative-implementation-descriptions?rev=1789503746&do=diff GPR-016 — Avoidance of Normative Implementation Descriptions Go to Annex C: Requirements Statement The Submission SHOULD NOT include implementation-specific descriptions as normative specification content. Requirement Level Recommended Rationale Implementation-specific descriptions can unintentionally constrain otherwise valid implementations or cause readers to interpret an example implementation as a conformance requirement. text/html 2026-09-15T20:22:43+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-017-minimal-interoperability-constraints?rev=1789503763&do=diff GPR-017 — Minimal Interoperability Constraints Go to Annex C: Requirements Statement The proposed specification SHALL NOT constrain implementations beyond what is necessary to support required Interoperability. Requirement Level Mandatory Rationale Interoperability may require normative constraints on externally observable behavior, information structures, interfaces, interaction rules, or conformance conditions. Constraints unrelated to an identified Interoperability requirement unnecess… text/html 2026-09-15T20:31:52+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-018-independent-substitutable-and-interoperable-implementations?rev=1789504312&do=diff GPR-018 — Independent, Substitutable, and Interoperable Implementations Go to Annex C: Requirements Statement The proposed specification SHALL define externally observable behavior, Interfaces, and conformance conditions that permit independently developed implementations to be substitutable and text/html 2026-09-15T20:32:11+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-019-implementation-replacement-without-client-changes?rev=1789504331&do=diff GPR-019 — Implementation Replacement Without Client Changes Go to Annex C: Requirements Statement An implementation SHOULD be replaceable by an alternative implementation satisfying the same applicable Interface Contracts and conformance conditions without requiring changes to conforming clients. text/html 2026-09-15T20:41:24+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-020-secure-implementation-and-deployment?rev=1789504884&do=diff GPR-020 — Secure Implementation and Deployment Go to Annex C: Requirements Statement The Submission SHALL demonstrate that the proposed specification can be implemented and deployed securely in environments governed by applicable security requirements. Requirement Level text/html 2026-09-15T20:41:46+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-021-security-analysis?rev=1789504906&do=diff GPR-021 — Security Analysis Go to Annex C: Requirements Statement The Submission SHALL provide a security analysis identifying the security-sensitive elements introduced by the proposed specification, the applicable security-policy controls, the required security awareness, the recommended default security policies, and the security considerations applicable to implementers. text/html 2026-09-15T20:50:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-022-internationalization-support-classification?rev=1789505428&do=diff GPR-022 — Internationalization Support Classification Go to Annex C: Requirements Statement The Submission SHALL identify the degree of internationalization support provided by the proposed specification using one of the Internationalization Classifications defined by this requirement. text/html 2026-09-15T20:54:20+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-023-inspectable-and-testable-conformance?rev=1789505660&do=diff GPR-023 — Inspectable and Testable Conformance Go to Annex C: Requirements Statement The proposed specification SHOULD define sufficient constraints on Interfaces, externally observable behavior, conformance-relevant implementation characteristics, and required evidence to permit unambiguous conformance assessment through manual inspection and automated testing. text/html 2026-09-15T20:59:53+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/gpr-024-xmi-representation-of-metadata-models?rev=1789505993&do=diff GPR-024 — XMI Representation of Metadata Models Go to Annex C: Requirements Statement A Submission that incorporates metadata specifications SHOULD provide a machine-readable OMG XML Metadata Interchange (XMI) representation of each applicable metadata model. Requirement Level text/html 2026-09-14T20:37:14+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-001-platform-independent-reference-architecture?rev=1789418234&do=diff SIP-001 — Platform-Independent Reference Architecture Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL be platform independent. Rationale Platform independence allows the Reference Architecture to define architectural concepts, responsibilities, relationships, and interactions without requiring a particular operating system, runtime environment, middleware product, programming language, data-storage technology, deployment environment, or vendor implementation.… text/html 2026-09-14T20:39:21+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-002-formal-platform-independent-model?rev=1789418361&do=diff SIP-002 — Formal Platform Independent Model Go to Annex C: Requirements Statement The Submission SHALL include a formal Platform Independent Model (PIM) of the proposed Reference Architecture. Rationale A formal Platform Independent Model provides a precise and reviewable representation of the proposed Reference Architecture. It establishes the architectural elements, roles, relationships, interactions, and constraints independently of the technologies used to implement them. text/html 2026-09-14T20:41:09+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-003-reference-architecture-constituents?rev=1789418469&do=diff SIP-003 — Reference Architecture Constituents Go to Annex C: Requirements Statement The architectural Model SHALL define the elements, Roles, relationships, and interaction constructs that comprise the Reference Architecture. Rationale A Reference Architecture requires more than a collection of named components. It must define the architectural constituents, their assigned responsibilities, how they relate, and how they interact. text/html 2026-09-14T20:43:29+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-004-separation-of-architectural-concerns?rev=1789418609&do=diff SIP-004 — Separation of Architectural Concerns Go to Annex C: Requirements Statement The architectural Model SHALL represent Data, Structure, Semantics, and Interpretation as separable but coordinated architectural concerns. Rationale Data, Structure, Semantics, and Interpretation serve different purposes and have different authorities, dependencies, and lifecycles. Treating them as separate architectural concerns lets you identify, govern, version, reuse, and change each one without silent… text/html 2026-09-14T20:43:54+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-005-structured-information-flow?rev=1789418634&do=diff SIP-005 — Structured Information Flow Go to Annex C: Requirements Statement The information-flow Model SHALL define an architectural construct representing the flow of structured information between architectural elements. Rationale Structured information processing requires an explicit representation of how information moves through the Reference Architecture. Without an information-flow construct, exchanges may remain implicit within implementation behavior, making the source, destination… text/html 2026-09-14T20:48:15+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-006-ordered-modular-processing-flows?rev=1789418895&do=diff SIP-006 — Ordered Modular Processing Flows Go to Annex C: Requirements Statement The processing-flow Model SHALL define ordered processing flows composed of modular components connected through governed interaction constructs. Rationale Structured information may pass through multiple processing components before producing an outcome. The order of processing affects which Structures, Semantics, rules, transformations, and Interpretations apply. text/html 2026-09-14T20:50:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-007-structured-information-attachment-points?rev=1789419057&do=diff SIP-007 — Structured Information Attachment Points Go to Annex C: Requirements Statement Each architectural element that exchanges structured information SHALL expose explicit attachment points through which that information enters or exits the element. Rationale Explicit attachment points define where an architectural element participates in structured information exchange. They prevent the exchange from remaining implicit within implementation-specific behavior. text/html 2026-09-14T20:51:22+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-008-information-boundary-constructs?rev=1789419082&do=diff SIP-008 — Information Boundary Constructs Go to Annex C: Requirements Statement The architectural Model SHALL define boundary constructs governing the ingress, transformation, and egress of structured information. Rationale Structured information may cross architectural, organizational, jurisdictional, trust, or security boundaries. Each crossing may require validation, transformation, filtering, authorization, recording, or other governed processing. text/html 2026-09-14T20:51:56+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-009-version-controlled-interface-contracts?rev=1789419116&do=diff SIP-009 — Version-Controlled Interface Contracts Go to Annex C: Requirements Statement Each Interface Contract SHALL be version-controlled and SHALL govern the exchange of structured information across applicable attachment points. Rationale An Interface Contract establishes the agreed conditions under which architectural elements exchange structured information. Those conditions may include the information Structure, applicable Semantics, interaction behavior, constraints, and responsibili… text/html 2026-09-14T20:52:13+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-010-structural-artifact-lifecycle-governance?rev=1789419133&do=diff SIP-010 — Structural Artifact Lifecycle Governance Go to Annex C: Requirements Statement The Governance Model SHALL define lifecycle controls for structural Artifacts. Rationale Structural Artifacts define how Data elements are identified, organized, related, constrained, and represented. Changes to these Artifacts can affect validation, transformation, exchange, processing, and Interpretation across multiple Systems and Domains. text/html 2026-09-14T20:55:59+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-011-semantic-artifact-lifecycle-governance?rev=1789419359&do=diff SIP-011 — Semantic Artifact Lifecycle Governance Go to Annex C: Requirements Statement The Governance Model SHALL define lifecycle controls for semantic Artifacts. Rationale Semantic Artifacts establish or reference the meanings associated with Data, structural elements, concepts, values, and relationships. Changes to those meanings can alter how information is understood even when its Data and Structure remain unchanged. text/html 2026-09-14T20:56:23+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-012-interpretive-artifact-lifecycle-governance?rev=1789419383&do=diff SIP-012 — Interpretive Artifact Lifecycle Governance Go to Annex C: Requirements Statement The Governance Model SHALL define lifecycle controls for interpretive Artifacts. Rationale Interpretive Artifacts define or support the rules, calculations, classifications, transformations, reasoning, or decision logic applied to structured information. Changes to these Artifacts can change an outcome even when the input Data, Structure, and Semantics remain unchanged. text/html 2026-09-14T20:56:50+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-013-reproducible-interpretation?rev=1789419410&do=diff SIP-013 — Reproducible Interpretation Go to Annex C: Requirements Statement The Interpretation Model SHALL support reproduction of an Interpretation using identified, version-controlled conditions. Rationale An Interpretation may depend on more than its input Data. Its outcome may also depend on the applicable Structure, Semantics, interpretive rules, Policies, configuration, processing order, and execution context. text/html 2026-09-14T20:57:48+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-014-jurisdictional-control-of-structural-definitions?rev=1789419468&do=diff SIP-014 — Jurisdictional Control of Structural Definitions Go to Annex C: Requirements Statement The Governance Model SHALL allow each Jurisdiction to retain Authority over the structural definitions applicable within its operational boundary. Rationale Organizations, governments, regulatory bodies, security authorities, and other Jurisdictions may establish different structural definitions for information under their Authority. Federation requires those definitions to be related without si… text/html 2026-09-14T20:58:40+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-015-jurisdictional-control-of-semantic-definitions?rev=1789419520&do=diff SIP-015 — Jurisdictional Control of Semantic Definitions Go to Annex C: Requirements Statement The Governance Model SHALL allow each Jurisdiction to retain Authority over the semantic definitions applicable within its operational boundary. Rationale Different Jurisdictions may assign different meanings to the same term, identifier, code, value, or structural element. They may also use different designations for equivalent or related concepts. text/html 2026-09-14T21:00:02+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-016-cross-jurisdictional-integration?rev=1789419602&do=diff SIP-016 — Cross-Jurisdictional Integration Go to Annex C: Requirements Statement The integration Model SHALL define modular constructs supporting operations across Jurisdictional boundaries. Rationale Participating Jurisdictions may maintain different Structures, Semantics, Policies, Interpretations, authorities, and implementation technologies. Cross-jurisdictional operations require mediating these differences without forcing every participant to adopt a single internal model or surrender… text/html 2026-09-14T21:12:31+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-017-cross-security-boundary-integration?rev=1789420351&do=diff SIP-017 — Cross-Security-Boundary Integration Go to Annex C: Requirements Statement The security architecture SHALL define modular integration constructs supporting operations across Security Boundaries. Rationale Structured information may need to pass between Systems operating under different trust conditions, security Policies, access restrictions, classifications, or handling requirements. Such exchanges require explicit architectural mediation rather than implicit or unrestricted conne… text/html 2026-09-14T21:03:32+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-018-information-flow-segmentation?rev=1789419812&do=diff SIP-018 — Information-Flow Segmentation Go to Annex C: Requirements Statement The information-flow Model SHALL define mechanisms for enforcing segmentation based on applicable Governance or security constraints. Rationale Not all structured information may flow among all architectural elements, Domains, Jurisdictions, or security environments. Governance and security constraints may restrict which information can move, where it can move, who may receive it, and which processing may be appli… text/html 2026-09-14T21:03:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-019-data-plane-and-control-plane-separation?rev=1789419838&do=diff SIP-019 — Data Plane and Control Plane Separation Go to Annex C: Requirements Statement The Reference Architecture SHALL separate the Data Plane from the Control Plane. Rationale The Data Plane carries and processes operational structured information. The Control Plane distributes, selects, configures, and governs the Artifacts, Policies, constraints, and other control information that determine how operational processing occurs. text/html 2026-09-14T21:06:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-020-governance-constraints-and-interface-contracts?rev=1789420017&do=diff SIP-020 — Governance Constraints and Interface Contracts Go to Annex C: Requirements Statement The Governance Model SHALL distinguish Governance constraints from Interface Contracts. Rationale A Governance constraint expresses a Policy, Authority, obligation, prohibition, or condition governing structured information or its processing. An Interface Contract defines the conditions under which architectural elements interact and exchange structured information. text/html 2026-09-14T21:07:23+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-021-independent-conformance-requirements?rev=1789420043&do=diff SIP-021 — Independent Conformance Requirements Go to Annex C: Requirements Statement The conformance Model SHALL define conformance requirements independently of Interface interaction definitions. Rationale Conformance to a Reference Architecture may involve architectural elements, Roles, Models, Governance capabilities, lifecycle behavior, information Structures, or other obligations that cannot be evaluated solely by observing Interface interactions. text/html 2026-09-14T21:08:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-022-technology-independent-conformance-points?rev=1789420083&do=diff SIP-022 — Technology-Independent Conformance Points Go to Annex C: Requirements Statement The conformance Model SHALL define conformance points that support inspection and verification independently of implementation technology. Rationale A platform-independent Reference Architecture may have multiple implementations that use different products, programming languages, protocols, deployment environments, or processing technologies. Conformance must therefore be evaluated against architectura… text/html 2026-09-14T21:08:36+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-023-governance-evolution-and-operational-execution?rev=1789420116&do=diff SIP-023 — Governance Evolution and Operational Execution Go to Annex C: Requirements Statement The Reference Architecture SHALL separate the evolution of Governance Artifacts from execution of the operational processing flow. Rationale Governance Artifacts may change while operational processing continues. Applying every change to an active processing flow immediately could alter outcomes without an explicit transition, invalidate comparisons, or prevent reproduction of earlier Interpretati… text/html 2026-09-15T00:16:43+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-024-domain-specific-content-exclusion?rev=1789431403&do=diff SIP-024 — Domain-Specific Content Exclusion Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL NOT define Domain-specific Data content or operational Data Models. Rationale SIP-RA provides architectural abstractions for structured information processing across multiple Domains. Defining the operational Data content of a particular Domain would narrow the Reference Architecture and could conflict with existing Domain standards, authorities, and information Models… text/html 2026-09-15T00:17:02+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-025-transport-and-runtime-mechanism-exclusion?rev=1789431422&do=diff SIP-025 — Transport and Runtime Mechanism Exclusion Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL NOT define transport protocols, message-exchange frameworks, or runtime communication mechanisms. Rationale Transport protocols, message-exchange frameworks, and runtime communication mechanisms are platform-specific realization choices. Incorporating them into the Reference Architecture would constrain portability, limit implementation alternatives, and risk d… text/html 2026-09-15T00:21:11+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-026-preservation-of-existing-omg-specifications?rev=1789431671&do=diff SIP-026 — Preservation of Existing OMG Specifications Go to Annex C: Requirements Statement The Submission SHALL NOT replace, supersede, or modify existing OMG specifications addressing information exchange, interoperability, or semantic federation. Rationale OMG has adopted specifications that address information exchange, distributed interaction, interoperability, modeling, and semantic technologies. SIP-RA should provide an architectural framework that relates to and uses applicable spec… text/html 2026-09-15T00:21:32+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-027-ontology-vocabulary-and-taxonomy-exclusion?rev=1789431692&do=diff SIP-027 — Ontology, Vocabulary, and Taxonomy Exclusion Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL NOT standardize a specific Ontology, Vocabulary, or Domain Taxonomy. Rationale Ontologies, Vocabularies, and Domain Taxonomies express concepts and meanings established for particular communities, Domains, authorities, or purposes. Selecting one such Artifact as the required semantic content of SIP-RA would limit applicability and could displace existing aut… text/html 2026-09-15T00:27:16+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-028-doctrine-procedure-and-policy-exclusion?rev=1789432036&do=diff SIP-028 — Doctrine, Procedure, and Policy Exclusion Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL NOT define operational doctrine, mission procedures, or Domain Policy rules. Rationale Organizations, Jurisdictions, Communities of Interest, and other authorities responsible for a particular operational context establish operational doctrine, mission procedures, and Domain Policy rules. text/html 2026-09-15T00:27:40+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-029-implementation-and-deployment-independence?rev=1789432060&do=diff SIP-029 — Implementation and Deployment Independence Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL NOT prescribe specific implementation technologies, deployment topologies, or System architectures. Rationale A Reference Architecture identifies common architectural concepts, responsibilities, relationships, and constraints. Implementation technologies, deployment topologies, and individual System architectures are realization decisions made for particular o… text/html 2026-09-15T00:28:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-030-tool-and-technology-neutrality?rev=1789432083&do=diff SIP-030 — Tool and Technology Neutrality Go to Annex C: Requirements Statement The conformance requirements SHALL NOT require a specific modeling language, transport framework, or vendor tooling environment. Rationale Conformance to SIP-RA must depend on satisfaction of its architectural requirements rather than on the technology or commercial tool used to describe, implement, transport, or evaluate a conforming realization. text/html 2026-09-15T00:39:23+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-031-architectural-positioning?rev=1789432763&do=diff SIP-031 — Architectural Positioning Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL be positioned at the architectural Governance and structural abstraction layer. Rationale Positioning the Reference Architecture at the Governance and structural abstraction layer establishes its responsibilities and separates them from the implementation mechanisms used to transport, exchange, or process information. text/html 2026-09-15T00:39:45+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-032-separation-from-existing-mechanisms?rev=1789432785&do=diff SIP-032 — Separation from Existing Mechanisms Go to Annex C: Requirements Statement The architectural model SHALL distinguish Governance constructs from transport, information-exchange, message-exchange, and Federation mechanisms defined by existing OMG specifications. Rationale Governance constructs establish authority, applicability, constraints, lifecycle controls, and decision processes. Transport, information-exchange, message-exchange, and Federation mechanisms provide operational cap… text/html 2026-09-15T00:40:10+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-033-architectural-layering?rev=1789432810&do=diff SIP-033 — Architectural Layering Go to Annex C: Requirements Statement The architectural model SHALL define layering that separates structural and Governance concerns from transport, information-exchange, message-exchange, and Federation mechanisms. Rationale Explicit architectural layering assigns responsibilities to distinct architectural concerns and defines how those concerns interact. This separation allows structural definitions and Governance Artifacts to evolve independently of the … text/html 2026-09-15T00:40:32+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-034-preservation-of-existing-transport-and-exchange-constructs?rev=1789432832&do=diff SIP-034 — Preservation of Existing Transport and Exchange Constructs Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL NOT redefine, duplicate, or supersede transport, information-exchange, message-exchange, or message-layer constructs defined by existing OMG specifications. text/html 2026-09-15T00:46:01+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-035-complementarity-with-exchange-and-interoperability-specifications?rev=1789433161&do=diff SIP-035 — Complementarity with Exchange and Interoperability Specifications Go to Annex C: Requirements Statement The Submission SHALL describe how the proposed Reference Architecture complements existing OMG specifications addressing information exchange and Interoperability. Rationale OMG specifications already provide capabilities for information exchange and Interoperability. The proposed Reference Architecture provides Governance and structural abstractions that complement these capabi… text/html 2026-09-15T00:46:21+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-036-relationship-to-semantic-federation-and-ontology-modeling?rev=1789433181&do=diff SIP-036 — Relationship to Semantic Federation and Ontology Modeling Go to Annex C: Requirements Statement The Submission SHALL describe how the proposed Reference Architecture relates to existing OMG specifications addressing semantic Federation and Ontology-based modeling. Rationale Existing OMG specifications provide mechanisms for representing meaning, relating independently governed semantic resources, mapping concepts, and supporting semantic Federation. text/html 2026-09-15T00:46:47+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-037-technology-neutral-integration-points?rev=1789433207&do=diff SIP-037 — Technology-Neutral Integration Points Go to Annex C: Requirements Statement The architectural model SHALL identify integration points with information-exchange and semantic-Federation frameworks while remaining independent of any specific transport, exchange, or modeling standard. text/html 2026-09-15T00:47:08+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-038-nonduplication-of-existing-capabilities?rev=1789433228&do=diff SIP-038 — Nonduplication of Existing Capabilities Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL NOT redefine or duplicate capabilities standardized by existing OMG information-exchange, Interoperability, or semantic-Federation specifications. Rationale Redefining or duplicating standardized capabilities creates overlapping responsibilities, inconsistent terminology, competing conformance requirements, and potential incompatibilities among text/html 2026-09-15T00:56:17+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-039-platform-independent-modeling?rev=1789433777&do=diff SIP-039 — Platform-Independent Modeling Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL be defined at a platform-independent level without requiring a specific modeling language or notation. Rationale The proposed Reference Architecture defines architectural concepts and relationships independently of the technologies used to implement them. Its normative meaning must not depend on constructs available only within a particular implementation platform, modelin… text/html 2026-09-15T00:56:35+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-040-representation-independent-architectural-constructs?rev=1789433795&do=diff SIP-040 — Representation-Independent Architectural Constructs Go to Annex C: Requirements Statement The architectural model SHALL define its constructs, roles, relationships, and Governance mechanisms independently of any particular modeling syntax or diagrammatic representation. Rationale text/html 2026-09-15T00:56:55+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-041-modeling-and-tooling-conformance-neutrality?rev=1789433815&do=diff SIP-041 — Modeling and Tooling Conformance Neutrality Go to Annex C: Requirements Statement The conformance requirements SHALL NOT require implementations to use a specific modeling language, model-interchange format, or vendor tooling environment. Rationale Conformance to the proposed Reference Architecture concerns the implementation of its architectural constructs, relationships, constraints, and externally observable responsibilities. It should not depend on the modeling language, inter… text/html 2026-09-15T01:12:05+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-042-complete-reference-architecture-specification?rev=1789434725&do=diff SIP-042 — Complete Reference Architecture Specification Go to Annex C: Requirements Statement The Submission SHALL include a complete specification of the proposed Reference Architecture that addresses all applicable requirements defined in Section 6.2 Scope of Proposals Sought and Section 6.3 Relationship to Other OMG Specifications. Rationale A complete specification provides the architectural models, definitions, relationships, constraints, and supporting material needed to evaluate the … text/html 2026-09-15T01:12:32+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-043-integrated-submission-document?rev=1789434752&do=diff SIP-043 — Integrated Submission Document Go to Annex C: Requirements Statement The specification MAY be submitted as a single integrated document. Rationale Allowing a single integrated document gives Submitters the option to present the architectural model, definitions, rationale, conformance material, and supporting information as one coordinated specification. text/html 2026-09-15T01:26:55+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-044-structured-architectural-description?rev=1789435615&do=diff SIP-044 — Structured Architectural Description Go to Annex C: Requirements Statement The Submission SHALL include a structured architectural description of the proposed Reference Architecture. Rationale A structured architectural description provides an organized and reviewable account of the proposed Reference Architecture. It enables evaluators to identify the architectural elements, responsibilities, relationships, interactions, information flows, boundaries, and text/html 2026-09-15T01:27:16+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-045-architectural-visual-representations?rev=1789435636&do=diff SIP-045 — Architectural Visual Representations Go to Annex C: Requirements Statement The Submission SHALL include visual representations of the ordered processing flows and boundary constructs defined by the architectural model without requiring conforming implementations to use a specific modeling notation. text/html 2026-09-15T01:37:24+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-046-platform-independent-model-abstract-syntax?rev=1789436244&do=diff SIP-046 — Platform Independent Model Abstract Syntax Go to Annex C: Requirements Statement The Platform Independent Model (PIM) SHALL define an abstract syntax for its architectural constructs, relationships, and constraints. Rationale An abstract syntax identifies the concepts that may appear in a conforming model and defines how those concepts may be combined. It separates the PIM structure from any graphical notation, textual syntax, serialization format, or modeling tool used to represe… text/html 2026-09-15T01:37:51+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-047-platform-independent-model-formal-semantics?rev=1789436271&do=diff SIP-047 — Platform Independent Model Formal Semantics Go to Annex C: Requirements Statement The Platform Independent Model (PIM) SHALL define the formal Semantics of its architectural constructs, relationships, and constraints independently of any specific implementation technology. Rationale Abstract syntax identifies which model elements and relationships may be expressed. Formal Semantics establishes what those elements, relationships, and constraints mean. text/html 2026-09-15T01:38:13+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-048-platform-independent-model-formal-precision?rev=1789436293&do=diff SIP-048 — Platform Independent Model Formal Precision Go to Annex C: Requirements Statement The Platform Independent Model (PIM) SHALL be defined with sufficient formal precision to support independent implementation and conformance assessment. Rationale A PIM that depends on undocumented assumptions or informal interpretation cannot reliably support independent implementations. Different implementers may assign different meanings to the same constructs or apply constraints inconsistently.… text/html 2026-09-15T01:41:22+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-049-architectural-concern-and-lifecycle-description?rev=1789436482&do=diff SIP-049 — Architectural Concern and Lifecycle Description Go to Annex C: Requirements Statement The Submission SHALL describe the separation and coordination of Data, Structure, Semantics, and Interpretation and the independent definition, versioning, and lifecycle Governance of structural, semantic, and interpretive text/html 2026-09-15T01:41:43+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-050-implementation-independent-interpretive-logic?rev=1789436503&do=diff SIP-050 — Implementation-Independent Interpretive Logic Go to Annex C: Requirements Statement The proposed Reference Architecture SHALL define architectural mechanisms that separate interpretive logic from implementation environments. Rationale When interpretive logic is embedded exclusively within application code, runtime platforms, or proprietary processing systems, the rules used to produce an outcome become difficult to identify, govern, reproduce, and transfer. text/html 2026-09-15T01:44:11+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-051-flow-and-interface-description?rev=1789436651&do=diff SIP-051 — Flow and Interface Description Go to Annex C: Requirements Statement The Submission SHALL describe the structured information flows, attachment points, Interface Contracts, and information-flow segmentation mechanisms defined by the proposed Reference Architecture. Rationale Structured information moves between architectural elements through defined attachment points and governed Interface Contracts. A complete description of these constructs enables reviewers and implementers to … text/html 2026-09-15T01:44:29+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-052-interface-contract-evolution?rev=1789436669&do=diff SIP-052 — Interface Contract Evolution Go to Annex C: Requirements Statement The architectural model SHALL define mechanisms governing the controlled evolution of versioned Interface Contracts. Rationale Interface Contracts may change as structural definitions, semantic definitions, constraints, policies, and operational needs evolve. Uncontrolled changes can cause incompatible exchanges, ambiguous interpretation, and inconsistent behavior among participating systems. text/html 2026-09-15T01:47:48+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-053-governance-and-jurisdictional-authority-description?rev=1789436868&do=diff SIP-053 — Governance and Jurisdictional Authority Description Go to Annex C: Requirements Statement The Submission SHALL describe the lifecycle Governance mechanisms applicable to structural, semantic, and interpretive Artifacts and the architectural mechanisms by which each Jurisdiction retains Authority over structural and semantic definitions within its operational boundary. text/html 2026-09-15T01:51:10+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-054-implementation-conformance-model?rev=1789437070&do=diff SIP-054 — Implementation Conformance Model Go to Annex C: Requirements Statement The Submission SHALL define a Conformance model specifying the conditions under which an implementation conforms to the proposed Reference Architecture. Rationale A Reference Architecture requires explicit Conformance conditions so implementers, evaluators, and acquiring organizations can determine whether an implementation realizes the required architectural responsibilities. text/html 2026-09-15T01:51:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-055-architectural-element-conformance-classification?rev=1789437104&do=diff SIP-055 — Architectural Element Conformance Classification Go to Annex C: Requirements Statement The Conformance model SHALL classify each conformance-relevant architectural element as mandatory, optional, or conditional and SHALL define the conditions applicable to each conditional element. text/html 2026-09-15T01:54:19+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-056-rfp-traceability-map?rev=1789437259&do=diff SIP-056 — RFP Traceability Map Go to Annex C: Requirements Statement The Submission SHALL include a Traceability map covering every applicable mandatory requirement of this RFP. Rationale A Traceability map provides a systematic means of determining whether the Submission addresses every applicable mandatory requirement. It enables evaluators to locate the corresponding specification content, understand how the requirement is satisfied, and identify omissions or incomplete responses. text/html 2026-09-15T01:54:46+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-057-requirement-to-specification-traceability?rev=1789437286&do=diff SIP-057 — Requirement-to-Specification Traceability Go to Annex C: Requirements Statement The Traceability map SHALL link each applicable mandatory requirement associated with Section 5 General Requirements on Proposals and Section 6 Specific Requirements on Proposals to one or more locations within the Submission and SHALL identify how each requirement is satisfied. Rationale text/html 2026-09-15T01:55:04+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/sip-058-incomplete-requirement-disclosure?rev=1789437304&do=diff SIP-058 — Incomplete Requirement Disclosure Go to Annex C: Requirements Statement The Submission SHALL identify each applicable mandatory requirement that it does not fully satisfy and SHALL provide the reason for the incomplete satisfaction. Rationale Explicit disclosure of incomplete satisfaction prevents omissions or partial responses from being mistaken for complete conformance. It enables evaluators to understand the nature, extent, and consequences of each identified gap. text/html 2026-09-15T21:24:51+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/public/00-sip-ra/99-annexes/annex-c-requirements/start?rev=1789507491&do=diff Annex C: Requirements Go to Annexes This annex contains the authoritative requirement records for the Structured Information Processing Reference Architecture (SIP-RA) Request for Proposals. Each requirement record provides a stable identifier, short title, normative Statement, requirement level, rationale, evaluation criteria, and backlinks to the sections in which the requirement is referenced.annex-c-requirements index annex-c-requirements index