This feature delivers two specialized comparison capabilities that round out the scope: meaningful revision-to-revision comparison inside the same object and structural comparison for recipes. It solves the problem of false positives in XML revision diffs and enables users to inspect how recipe trees change across versions, subversions, and snapshots. The implementation touches dedicated services, models, endpoints, registrations, and tests for both paths. On the object side, ComparisonService is extended to normalize DITA XML before diffing, suppress whitespace, namespace, and attribute noise, detect when there are no meaningful differences, and preserve raw diff toggles at the endpoint. On the recipe side, new request and response contracts, a recipe comparison service interface and implementation, endpoint wiring under the compare recipes route, test data builders, and dependency registration provide tree-diff orchestration for node adds, removals, moves, and criteria changes. Key acceptance signals are that revision comparisons avoid non-semantic noise while still allowing raw inspection when explicitly requested, and that recipe comparison respects existing Object.Read authorization without introducing export or workflow integration concerns. Unit and integration coverage must demonstrate no-difference reporting for revisions and full recipe journey behavior across structural change types and access-control scenarios.
This feature delivers the cross-cutting operational pieces that make the comparison capability supportable in production: request validation, audit and BI telemetry, targeted validation runs, performance checks, and release evidence. It solves the problem of ensuring the new comparison flows are observable, governable, and demonstrably ready beyond just passing functional tests. The technical approach keeps endpoint handlers thin by introducing dedicated comparison request validators, extends captured audit helpers and lifecycle telemetry tests, and adds unified audit and BI event emission inside both object and recipe comparison services. It also formalizes quality gates through focused test-project validation, performance validation against summary-first and lazy-load expectations, UAT procedure documentation, pilot execution, and finally full solution validation. Implementers must make sure validation covers invalid result modes and unknown selectors without leaking transport concerns into domain logic, and that telemetry spans both object and recipe comparison journeys consistently. Acceptance is signaled by passing audit assertions, documented UAT methodology and evidence for the success criteria, representative timing captures for default and section-detail paths, and clean repository-wide validation.
This feature delivers cross-object content comparison so users can compare two different content objects and understand what changed even when the objects do not share an identical structure. It solves the problem of manually reviewing parallel or reused content across separate objects by producing aligned differences, highlighting matched and unmatched sections, and reducing false positives that would otherwise occur when sections have moved, been renamed, or diverged structurally. The technical work is centered in the comparison service and its test coverage. The API comparison layer is extended to align sections across different objects using a structural-first strategy based on stable cues such as DITA identifiers, section titles, and hierarchy, and then fall back to semantic similarity when no reliable structural match exists. The service is also updated to populate summaries of matched and unmatched sections for cross-object results, while unit tests validate the alignment behavior and integration tests exercise the end-to-end comparison journey and reuse-related signals through the platform API surface. This work must handle objects whose structures differ significantly without collapsing into noisy matches, and it should preserve deterministic behavior where structural evidence exists while using semantic fallback only for unresolved sections. Acceptance is indicated by cross-object comparisons returning sensible section alignment, clearly surfaced unmatched content, and automated coverage proving both the structural matching path and semantic fallback path behave as expected.
This feature delivers same-object content comparison across versions and subversions so users with existing read access can identify what changed between branch coordinates, review divergence safely, and detect inconsistencies without introducing a separate approval-flow experience. It solves the core problem of resolving the correct preview-equivalent revision for each selected side, comparing the chosen language variant with clear warnings when fallbacks or cross-language conditions occur, and avoiding misleading results for deleted, obsolete, or non-DITA content by returning the most appropriate comparison behavior for each case. The technical work updates the existing object /compare API rather than adding a parallel route, and extends the comparison service, preview renderer, and endpoint contract in the API layer. Implementation resolves preview-effective version, subversion, language, and last-snapshot fallback rules, adds a metadata-only comparison path for non-DITA objects, performs comparison-time DITA conref and conkeyref resolution before raw, structural, and styled diff analysis, and generates preview-aligned structured responses for same-object comparisons. The endpoint binding and response metadata are updated to expose raw diff mode, section-mode behavior, and warning signals while preserving current Object.Read authorization semantics, with unit and integration coverage validating resolution logic, deferred section loading, warning emission, forbidden access handling, and end-to-end comparison journeys.
This feature adds change-type classification and filtering to content comparison so users can quickly focus on the kinds of differences that matter when comparing objects, versions, subversions, or recipe structures. It solves the problem of noisy, hard-to-scan diffs by assigning each change region a canonical primary classification with optional secondary classifications, then letting users filter results using any matching classification. The result is a comparison experience that reduces false positives, improves review efficiency, and makes summaries and detailed diff output more meaningful for all users who already have read access to the content. The work is centered in the comparison service layer of the platform API. ComparisonService is extended to build canonical change-region classifications, roll those classifications up at the section level, apply server-side any-match filtering across primary and secondary classifications, and emit classification-aware markers in the comparison output consumed by clients. Test coverage is added at both unit and integration levels, with service tests validating classification and filter behavior in isolation and journey tests verifying end-to-end server-side filtering across object comparison flows. The implementation must preserve the spec rule that each diff region has exactly one primary classification and may have secondary classifications, while filters include a region when any attached classification matches. It also needs to behave consistently with existing comparison resolution rules and support large-content comparison patterns where summary and counts are available before detailed diff sections load. Acceptance is indicated by correctly classified regions, accurate section rollups and markers, and externally verified filter results that include or exclude regions based on either primary or secondary change types.
This feature enables users to compare recipe structures between different content coordinates so they can see how a recipe has changed across versions, subversions, or snapshots without manually inspecting tree structures. It solves the problem of identifying structural edits such as added, removed, moved, or criteria-modified nodes, helping users understand recipe evolution, validate consistency, and support content review decisions with a focused structural comparison experience inside the platform. The implementation adds a dedicated recipe comparison capability in the API, including request and response contracts, a comparison service interface, and the service logic that orchestrates tree-diff evaluation for version, subversion, and snapshot comparisons. Platform work touches the API models layer, comparison services layer, endpoint layer, and dependency registration, with endpoint wiring added under the workspace comparison route and aligned to existing Object.Read authorization behavior. Test coverage is expanded with unit tests for recipe node add, remove, move, and criteria change detection, plus integration journey tests for the POST /api/workspaces/{workspaceId}/compare/recipes flow and forbidden-access cases. The feature must preserve existing read-access rules so any caller without Object.Read continues to receive the established forbidden behavior, and it remains limited to in-platform comparison rather than workflow integration or external sharing. Acceptance is signaled when recipe comparisons return structurally accurate diffs for supported coordinate types, correctly classify node-level changes, and pass both service-level and end-to-end test scenarios for authorized and unauthorized requests.
This feature delivers AI-assisted change summaries for content comparisons so users can quickly understand what changed between versions, subversions, or related content without reading the full diff first. It solves the problem of large or structurally divergent comparisons being slow to interpret, reduces false positives in review, and gives users an immediate summary-first experience with categorized change meaning, safety-related callouts, and translation impact signals even when detailed diff sections are loaded later. The technical work extends the comparison orchestration in the API service layer to generate categorized AI summary output, estimate retranslation impact, and surface safety-oriented warnings alongside comparison significance. It also updates the comparison response models to expose AI summary availability, significance, translation-impact, and warning fields to clients, while adding unit and integration test coverage for summary categorization, safety flags, external journey behavior, and graceful fallback when AI is unavailable. The touched layers are the comparison domain/service implementation, API-facing comparison models, and both unit and end-to-end integration test suites. The implementation must degrade cleanly when AI summarization cannot be produced, returning usable comparison results with explicit availability or warning indicators rather than failing the comparison flow. Acceptance is signaled by comparisons returning categorized summary data for supported cases, safety and translation-impact metadata where applicable, and predictable fallback behavior verified in automated unit and journey tests.
This feature delivers revision-level comparison within the same content object so users can inspect what changed between two revisions without being distracted by non-semantic XML noise. It solves the problem of false positives caused by whitespace, namespace, and insignificant attribute differences, and it makes revision comparison trustworthy by clearly reporting when there are no meaningful differences even if the raw source is not byte-identical. The technical work centers on the comparison pipeline in the API. ComparisonService is updated to normalize DITA XML before diffing, suppressing non-semantic changes while still supporting accurate revision-to-revision comparison, and to detect no-meaningful-differences cases with appropriate summary messaging. ComparisonEndpoints is adjusted to preserve raw diff toggle behavior for revision-level responses, and the work is validated through unit coverage for suppression rules and integration journey coverage for same-subversion revision comparison and no-difference reporting. The implementation must preserve the ability to view raw differences when explicitly requested, while making normalized comparison the default behavior for meaningful results. Acceptance is signaled by tests demonstrating that whitespace, namespace, and attribute-noise do not produce semantic diffs, that same-object revision comparisons within a subversion return expected results, and that users receive a clear no-difference outcome when only non-semantic changes exist.
This feature delivers the canonical object comparison experience for versions, subversions, revisions, and cross-object comparisons, giving users a single reliable way to inspect content changes without introducing parallel routes or inconsistent resolution behavior. It solves the core comparison problem by aligning results with the platform’s preview behavior, supporting metadata-only cases, handling lazy section loading, and preserving raw diff access where appropriate. The implementation centers on consolidating the existing comparison surface into the reused /compare path and backing it with shared comparison infrastructure across models, services, rendering, dependency registration, and endpoint wiring. It builds fixture builders for object comparisons, expands comparison contracts for result modes and structured fields, extracts preview-effective reference resolution, adds preview-aligned response rendering, implements same-object and cross-object comparison logic in ComparisonService, and updates the endpoint and service registrations to expose the canonical response shape while keeping authorization behavior unchanged. Implementers must preserve the clarification-driven rules around preview-effective revision resolution, deleted or obsolete fallback behavior, structural-first section alignment with semantic fallback, and non-DITA metadata-only responses. Acceptance is signaled by unit and integration coverage for version or subversion comparison, cross-object matching, deferred loading, warnings, forbidden access cases, and by removal of superseded routes and samples so only the canonical comparison entry points remain.
This feature delivers the higher-level review aids around comparisons: AI-assisted summaries, significance and translation-impact signals, safety-related callouts, and change-type classification with filtering. It solves the problem of making large or complex comparisons understandable quickly while still letting users narrow visible changes by the classifications attached to each diff region. The technical approach extends the comparison response contract and orchestration inside ComparisonService so summary generation and classification happen as first-class parts of the comparison pipeline rather than as separate post-processing. It adds model fields for availability and warning states, implements categorized AI outputs and graceful fallback behavior, computes canonical change-region classifications and section rollups, applies any-match filtering over primary and secondary classifications, emits classification-aware markers, and backs the behavior with focused unit and journey coverage. Implementers must honor the spec clarification that filters match any attached classification, not only the primary one, and that each diff region carries one primary classification plus optional secondary types. Acceptance is reflected in tests covering AI unavailable degradation, categorized summary output, safety and retranslation signals, primary and secondary classification behavior, and server-side filtering results.