Profiles

draft

Status of this Document

This report was published by the User Journal Graph Community Group . It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups .

Status: CG-DRAFT
Version: 1.0-rc1
Published: 2026-07-27
Last Update: 2026-07-28
Editors: Seva Dolgopolov
Group: User Journal Graph Community Group
Repository: View Source
License: W3C-Software-and-Document

1. Overview

Profiles define named interoperability bundles for UJG implementations. A profile identifies a set of required UJG modules and the conformance classes that an implementation claims for that set. Profiles do not define new JSON-LD terms, ontology classes, or SHACL shapes.

The Optional Modules published in this release candidate are the official optional capability family. A profile can require one or more optional modules when a capability needs shared semantics across tools. Opaque Core extensions remain outside semantic profile claims except for preservation and pass-through behavior.

Archived extension specifications under specs/archive/extensions are historical material only. Profiles MUST NOT treat those archived packages as active release-candidate capabilities.

2. Profile Model

UJG Profile: A named conformance bundle that declares required UJG modules and required conformance classes.
Profile claim: An out-of-band statement that a producer, consumer, validator, or tool conforms to a profile for one or more conformance classes.
Profile identifier: A URI or document-fragment identifier that names a profile.
Required module: A UJG module whose semantic constraints, JSON-LD context, and SHACL validation rules are required by a profile.

A UJG Profile MUST identify each required UJG module.
A UJG Profile MUST identify the conformance classes to which a claim can apply.
A profile claim MUST be made out of band, such as in implementation statements, package manifests, product documentation, HTTP metadata, registry entries, or other deployment metadata.
A profile claim MUST NOT be inferred from JSON-LD document content alone.
A profile claim MUST NOT use opaque Core extensions to satisfy a missing required module.
Unknown profile identifiers have no standardized conformance meaning.

This release candidate does not define a JSON-LD property for profile declarations. Documents MAY contain deployment-private profile metadata in extensions, but such metadata is not a standardized UJG profile claim and cannot affect profile conformance.

3. Profile Conformance

Profile conformance is claimed per conformance class. A tool can conform as a Producer for a profile without also claiming Consumer or Validator conformance for that profile.

A Producer claiming conformance to a profile MUST generate documents that satisfy every required module for that profile.
A Consumer claiming conformance to a profile MUST process terms from every required module according to that module's semantics.
A Validator claiming conformance to a profile MUST validate documents against the SHACL shapes for every required module in that profile.
A profile-conforming implementation MUST satisfy the dependency closure of each required module.
A document MAY use modules outside a claimed profile, but those modules are outside the profile claim unless another profile claim covers them.
A consumer that does not implement an optional module MAY ignore that module's semantics only where the module permits graceful degradation, and SHOULD preserve recognized JSON-LD data during read-transform-write when possible.

Profile conformance does not replace module conformance. It packages module requirements so implementations can make precise interoperability claims without requiring every tool to implement every optional module.

4. Starter Profiles

The following starter profiles are document-fragment identifiers in this Profiles draft. Future versions can publish additional profile identifiers without changing the module semantics below.

Profile	Required modules	Intended use
`#core`	Core	UJG document containers and addressable nodes.
`#graph`	Core, Graph	Intended journey topology.
`#surface-runtime`	Core, Graph, Surface, Runtime	Surface-aware runtime traces.
`#mapping-metrics`	Core, Graph, Surface, Runtime, Mapping, Metrics	Resolved mappings and aggregate metrics.
`#localized-observability`	Core, Graph, Surface, Localization, Observability	Accessible recognition contracts with localized names and descriptions.
`#design-system`	Core, Graph, Surface, Design System	Design-system realization of graph-facing surfaces.
`#automation-resources`	Core, Graph, Surface, Phase, Observability, Entry Binding, Effect, Artifact	Automation-oriented entry selection, observable resources, declared effects, and portable artifacts.

4.1. Core

The #core profile requires UJG Core. It is suitable for tools that exchange UJG document containers, imports, top-level nodes, and opaque node extensions without claiming graph semantics.

4.2. Graph

The #graph profile requires UJG Core and UJG Graph. It is suitable for tools that exchange intended journey topology, entries, states, transitions, exits, outgoing navigation, and indexes.

4.3. Surface Runtime

The #surface-runtime profile requires UJG Core, UJG Graph, UJG Surface, and UJG Runtime. It is suitable for tools that connect runtime observations to graph-facing surfaces.

4.4. Mapping Metrics

The #mapping-metrics profile requires UJG Core, UJG Graph, UJG Surface, UJG Runtime, UJG Mapping, and UJG Metrics. It is suitable for tools that compute mapping-derived measurements over observed journeys.

4.5. Localized Observability

The #localized-observability profile requires UJG Core, UJG Graph, UJG Surface, UJG Localization, and UJG Observability. It is suitable for tools that recognize surface instances through accessibility-oriented locators and localized names or descriptions.

4.6. Design System

The #design-system profile requires UJG Core, UJG Graph, UJG Surface, and UJG Design System. It is suitable for tools that connect graph-facing surfaces to design-system components, templates, slots, token sources, and realizations.

4.7. Automation Resources

The #automation-resources profile requires UJG Core, UJG Graph, UJG Surface, UJG Phase, UJG Observability, UJG Entry Binding, UJG Effect, and UJG Artifact, including the dependency closure of those modules. It is suitable for automation tools that need stable entry selection values, observable surface/resource context, phase-oriented grouping, declared effects, and portable resources.

5. Opaque Extensions And Profiles

Core extensions are useful for deployment-private data, vendor integration, local hints, and experimental metadata. They are not a substitute for profile-required modules.

A profile claim MUST NOT require consumers to interpret unknown Core extensions.
A profile claim MUST NOT treat an opaque extension key as equivalent to a required UJG module.
Profile-specific interoperable semantics SHOULD be published as UJG modules instead of hidden in opaque extension payloads.