Individual Submission N. N. Kalmykov Internet-Draft MGIMO University Intended status: Informational 2 July 2026 Expires: 3 January 2027 Social Architecture Diagnostic Profile: A JSON-Based Format for Exchanging Diagnostic Descriptions of Socio-Technical Environments draft-kalmykov-socarch-profile-00 Abstract This document specifies the Social Architecture Diagnostic Profile (SADP), a JSON-based format for exchanging diagnostic descriptions of socio-technical environments. A profile records the object under review, the evidence used, the diagnostic dimensions applied, identified breaks or tensions, limitations, confidence levels, and human-review requirements. The format is intended for research tools, educational systems, expert-review workflows, case repositories, and other systems that need portable and inspectable diagnostic descriptions. This document does not define a scoring standard, certification procedure, legal assessment process, psychological assessment process, or automated consequential decision process. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Kalmykov Expires 3 January 2027 [Page 1] Internet-Draft Social Architecture Diagnostic Profile July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. JSON Representation . . . . . . . . . . . . . . . . . . . . . 5 5.1. Common Requirements . . . . . . . . . . . . . . . . . . . 5 5.2. schema_version . . . . . . . . . . . . . . . . . . . . . 6 5.3. profile_id . . . . . . . . . . . . . . . . . . . . . . . 6 5.4. created_at . . . . . . . . . . . . . . . . . . . . . . . 6 5.5. profile_type . . . . . . . . . . . . . . . . . . . . . . 6 5.6. case . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.7. method . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.8. sources . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.9. diagnostic_profile . . . . . . . . . . . . . . . . . . . 7 5.10. breaks . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.11. evidence . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Profile Exchange Workflow . . . . . . . . . . . . . . . . . . 7 7. Versioning and Extensibility . . . . . . . . . . . . . . . . 8 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Normative References . . . . . . . . . . . . . . . . . . . . 10 13. Informative References . . . . . . . . . . . . . . . . . . . 11 Appendix A. JSON Schema . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Many socio-technical environments combine formal rules, user routes, interfaces, organizational handoffs, feedback channels, appeals, informal practices, and trust relationships. Researchers and practitioners often need to exchange structured descriptions of such environments without exchanging raw personal data or confidential case materials. Kalmykov Expires 3 January 2027 [Page 2] Internet-Draft Social Architecture Diagnostic Profile July 2026 The Social Architecture Diagnostic Profile (SADP) provides a compact JSON-based representation for such descriptions. It is designed to make diagnostic reports portable, inspectable, versioned, and easier to compare across tools while preserving the boundary between facts, interpretations, hypotheses, recommendations, and limitations. SADP is intentionally modest. It specifies a representation format. It does not standardize a theory of social architecture, does not define a universal measurement scale, and does not prescribe how organizations must redesign services, platforms, or institutions. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Social architecture A structured configuration of actors, roles, rules, routes, statuses, digital tools, feedback mechanisms, trust relations, barriers, and compensatory practices within a bounded social situation. Diagnostic profile A structured representation of a diagnostic description of a social architecture. Diagnostic dimension A named aspect of the diagnostic profile, such as route clarity, feedback availability, appeal availability, trust, recoverability, digital opacity, or human-review requirement. Break A point where the social architecture does not connect properly, such as a rule-practice mismatch, missing appeal channel, unclear entry point, opaque decision, or excessive route burden. Compensatory mechanism An informal or auxiliary mechanism by which participants keep the system functioning despite breaks, such as personal mediation, manual intervention, repeated submissions, or unofficial instructions. Human review A review by a qualified person before applying the diagnostic output in a consequential context. Kalmykov Expires 3 January 2027 [Page 3] Internet-Draft Social Architecture Diagnostic Profile July 2026 3. Use Cases SADP is intended for the following use cases: * exchanging diagnostic profiles between research tools and case repositories; * exporting anonymized case descriptors for dissertation or publication appendices; * comparing diagnostic cases across educational, public-service, organizational, urban, platform, or communication contexts; * attaching evidence and limitations to expert diagnostic reports; * supporting repeat diagnostics after a route, interface, rule, or feedback mechanism is changed; * teaching structured analysis of socio-technical environments. SADP is not intended for the following uses: * automated legal, medical, psychological, financial, employment, or eligibility decisions; * covert profiling of individuals or protected groups; * publication of raw personal data or confidential case materials; * certification of a method, service, organization, platform, or public authority; * claims that a redesign has caused an outcome without an appropriate research design. 4. Data Model A SADP document is a JSON object. It contains metadata, case description, method versioning, source and evidence information, diagnostic dimensions, breaks, compensatory mechanisms, correction modules, limitations, privacy information, and human-review information. The top-level object MUST contain the following members: * schema_version * profile_id Kalmykov Expires 3 January 2027 [Page 4] Internet-Draft Social Architecture Diagnostic Profile July 2026 * created_at * profile_type * case * method * diagnostic_profile * privacy * limitations * human_review The top-level object MAY contain the following members: * sources * evidence * breaks * compensatory_mechanisms * correction_modules * research_export * links 5. JSON Representation 5.1. Common Requirements A SADP JSON document MUST be encoded as UTF-8 JSON [RFC8259]. Implementations SHOULD canonicalize JSON when generating stable checksums or signatures. JSON Canonicalization Scheme [RFC8785] is one possible approach. String fields SHOULD be concise. A profile intended for public exchange MUST NOT include raw personal data unless there is a lawful basis, a documented purpose, and an explicit access-control model outside this format. Kalmykov Expires 3 January 2027 [Page 5] Internet-Draft Social Architecture Diagnostic Profile July 2026 5.2. schema_version The schema_version member identifies the SADP schema version. This document defines version 0.1. 5.3. profile_id The profile_id member is a stable local identifier for the profile. It SHOULD be unique within the producing system. 5.4. created_at The created_at member records the profile creation time as a string in RFC 3339 format. 5.5. profile_type The profile_type member classifies the profile. Allowed values are synthetic, anonymized_case, public_source_descriptor, and restricted_descriptor. 5.6. case The case member describes the object under review. It MUST include case_id, domain, analysis_level, diagnostic_mode, and source_status. It MAY include title, boundary, actors, affected_groups, route_or_process, and jurisdiction. 5.7. method The method member describes versions of the method or tool that generated the profile. It SHOULD include methodology_version, schema_version, and report_template_version. It MAY include tool_name, tool_version, and review_protocol_version. 5.8. sources The sources member is an array of source descriptors. Each descriptor SHOULD include source_id, source_type, access_status, reliability, and citation_allowed. It MAY include title, date, url, and checksum. Public profiles SHOULD avoid direct links to sensitive or identifying source materials. Kalmykov Expires 3 January 2027 [Page 6] Internet-Draft Social Architecture Diagnostic Profile July 2026 5.9. diagnostic_profile The diagnostic_profile member records the diagnostic dimensions. It SHOULD include dominant_layer, route_status, feedback_status, appeal_status, trust_status, recoverability_status, digital_opacity_status, and human_review_required. dominant_layer SHOULD be one of institutional, spatial_organizational, normative_semiotic, digital, mixed, or unknown. Status members SHOULD use one of absent, weak, partial, present, strong, unknown, or not_applicable. 5.10. breaks The breaks member is an array of diagnostic breaks. Each break SHOULD include break_id, break_type, affected_layer, affected_group, description, confidence, evidence_refs, and human_verification_question. confidence SHOULD be one of low, medium, high, or not_assessed. 5.11. evidence The evidence member is an array linking conclusions to sources. Each evidence item SHOULD include evidence_id, claim_status, summary, source_refs, confidence, and limitation. claim_status SHOULD be one of fact, source_statement, user_description, interpretation, hypothesis, recommendation, or limitation. 6. Profile Exchange Workflow A producing system SHOULD follow this workflow: 1. Register the case and define its boundary. 2. Minimize and classify input materials. 3. Construct a diagnostic profile. 4. Link significant conclusions to evidence. 5. Remove or restrict personal data and confidential materials. 6. Add limitations and human-review questions. Kalmykov Expires 3 January 2027 [Page 7] Internet-Draft Social Architecture Diagnostic Profile July 2026 7. Validate the JSON document against the SADP schema. 8. Export the profile to the receiving system. A receiving system SHOULD validate syntax and schema conformance, inspect privacy and human-review flags, preserve identifiers and limitations, and avoid using the profile for consequential decisions unless human review and local governance requirements are satisfied. 7. Versioning and Extensibility Implementations MUST preserve unknown top-level members unless they have a documented reason to drop them. Extension members SHOULD use a namespaced form such as x-example-org- field. Future versions of this document may define registries for diagnostic dimensions, break types, source types, or correction modules. 8. Privacy Considerations SADP profiles can describe sensitive environments, including public services, education, employment, organizational conflicts, platform sanctions, vulnerable-group access, and other high-impact contexts. A SADP profile MUST include the privacy member. The profile SHOULD state whether it contains personal data, raw text, direct quotations, or identifiability risk. Public SADP profiles SHOULD use synthetic or anonymized examples. They SHOULD NOT contain direct quotes, screenshots, names, contact details, account IDs, student IDs, employee IDs, precise location trails, or other identifiers unless an explicit disclosure model exists. When a profile is derived from user-submitted materials, the producing system SHOULD record consent status outside the public profile or include only a minimal consent descriptor. Privacy guidance in [RFC6973] is relevant when implementing SADP in networked systems. 9. Security Considerations SADP is a data representation format. It does not itself provide authentication, authorization, confidentiality, integrity, or audit logging. Kalmykov Expires 3 January 2027 [Page 8] Internet-Draft Social Architecture Diagnostic Profile July 2026 Implementations that store or exchange SADP profiles SHOULD provide access control, transport security, audit logging, retention limits, integrity checks, separation of public profiles from restricted case materials, safeguards against prompt injection or source-content injection when profiles are processed by language-model systems, and safeguards against over-reliance on profile outputs in consequential contexts. Implementations MUST NOT treat profile conformance as evidence that a diagnostic conclusion is true, complete, unbiased, or suitable for automated action. Implementations SHOULD treat untrusted profile content as untrusted input. Strings from profile fields MUST NOT be executed as code or used as privileged instructions. 10. IANA Considerations This document has no IANA actions. 11. Example The following shortened example illustrates a synthetic public- service profile: { "schema_version": "0.1", "profile_id": "sadp-synth-public-service-001", "created_at": "2026-07-02T00:00:00Z", "profile_type": "synthetic", "case": { "case_id": "synth-public-service-route-001", "title": "Synthetic route with missing appeal", "domain": "public_service", "analysis_level": "service_route", "diagnostic_mode": "route_failure_map", "source_status": "synthetic" }, "method": { "methodology_version": "0.1", "schema_version": "0.1", "report_template_version": "0.1" }, "diagnostic_profile": { "dominant_layer": "spatial_organizational", "route_status": "partial", "feedback_status": "weak", "appeal_status": "absent", Kalmykov Expires 3 January 2027 [Page 9] Internet-Draft Social Architecture Diagnostic Profile July 2026 "trust_status": "weak", "recoverability_status": "weak", "digital_opacity_status": "partial", "human_review_required": true }, "breaks": [ { "break_id": "br-001", "break_type": "missing_appeal_path", "affected_layer": "institutional", "affected_group": "service_applicants", "description": "No appeal step.", "confidence": "medium", "evidence_refs": ["ev-001"], "human_verification_question": "Review path?" } ], "privacy": { "contains_personal_data": false, "contains_raw_text": false, "contains_direct_quotes": false, "identifiability_risk": "low" }, "limitations": [ "Synthetic example; not an empirical measurement.", "No causal claim is made." ], "human_review": { "required": true, "status": "not_reviewed", "review_notes": [] } } 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . Kalmykov Expires 3 January 2027 [Page 10] Internet-Draft Social Architecture Diagnostic Profile July 2026 [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . 13. Informative References [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013, . Appendix A. JSON Schema A JSON Schema for SADP version 0.1 is expected to accompany this Internet-Draft as an implementation artifact. The schema is informative; the normative requirements are defined in this document. Appendix B. Acknowledgements The author thanks the broader communities working on socio-technical systems, digital governance, human review, research data stewardship, and responsible AI documentation. Specific acknowledgements can be added before submission. Author's Address Nikolay N. Kalmykov MGIMO University Email: Kalmykov@Kalmykovnn.ru Kalmykov Expires 3 January 2027 [Page 11]