Social Architecture Diagnostic Profile: A JSON-Based Format for Exchanging Diagnostic Descriptions of Socio-Technical Environments
draft-kalmykov-socarch-profile-00

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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

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,
              <https://www.rfc-editor.org/rfc/rfc8785>.

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, <https://www.rfc-editor.org/rfc/rfc6973>.

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]