MGIMO University

Kalmykov@Kalmykovnn.ru

Applications and Real-Time Individual Submission social architecture socio-technical systems diagnostic profile JSON provenance human review 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.

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. 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.

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 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.

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.

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
• 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

JSON Representation

Common Requirements A SADP JSON document MUST be encoded as UTF-8 JSON . Implementations SHOULD canonicalize JSON when generating stable checksums or signatures. JSON Canonicalization Scheme 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.

schema_version The schema_version member identifies the SADP schema version. This document defines version 0.1.

profile_id The profile_id member is a stable local identifier for the profile. It SHOULD be unique within the producing system.

created_at The created_at member records the profile creation time as a string in RFC 3339 format.

profile_type The profile_type member classifies the profile. Allowed values are synthetic, anonymized_case, public_source_descriptor, and restricted_descriptor.

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.

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.

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.

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.

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.

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.

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.
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.

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.

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 is relevant when implementing SADP in networked systems.

Security Considerations SADP is a data representation format. It does not itself provide authentication, authorization, confidentiality, integrity, or audit logging. 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.

IANA Considerations This document has no IANA actions.

Example The following shortened example illustrates a synthetic public-service profile:

Normative References Informative References

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.

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.