| Internet-Draft | Social Architecture Diagnostic Profile | July 2026 |
| Kalmykov | Expires 3 January 2027 | [Page] |
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.¶
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 (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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.¶
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.¶
SADP is intended for the following use cases:¶
SADP is not intended for the following uses:¶
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:¶
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.¶
The schema_version member identifies the SADP schema version. This document defines version 0.1.¶
The profile_id member is a stable local identifier for the profile. It SHOULD be unique within the producing system.¶
The created_at member records the profile creation time as a string in RFC 3339 format.¶
The profile_type member classifies the profile. Allowed values are synthetic, anonymized_case, public_source_descriptor, and restricted_descriptor.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
A producing system SHOULD follow this workflow:¶
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.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
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",
"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": []
}
}
¶
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.¶
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.¶