A consuming application (web portal, mobile app, in product display) should have quick and easy way to be able to fetch the latest information available for the end user.
For a product (for example model, market, year, variant) be able to give the consuming application of the information a way to check what available content is added/deleted/updated in order to not need to fetch all information, only what is changed.
Content that is included in an object matched by a recipe needs to be resolved before exposure to consuming systems.
This feature delivers the new CDP metadata contract based solely on MetadataDomain assignments and removes legacy response semantics. It solves the cutover problem by aligning endpoint payloads, projection logic, and contract validation with the clarified requirement that CDP returns values only, with no backward compatibility for legacy metadata fields or governance sources. The technical approach updates delivery response DTOs, endpoint behavior, projection models, and service helpers so existing CDP endpoints emit the new assignment-only shape directly. It adds and serializes the clean metadata response fields, removes old dictionary or value-view fields, strips legacy governance mapping paths from both release capture and delivery projection, and ensures publication, direct object, content package, catalog, media, search, and sync flows all resolve against publish-complete releases through shared delivery logic. Contract examples, OpenAPI validation, endpoint integration coverage, and explicit tests proving legacy governance sources are ignored provide confidence that the new interface is consistently enforced across the platform. Implementers must treat this as an intentional breaking change and avoid preserving old fields, old mapping behavior, or dev-era compatibility shims. Acceptance is signaled by regenerated OpenAPI output, passing contract tests against the new payload shape, integration proof that endpoints serialize only the new assignment-based metadata, and delivery flows consistently filtering to publish-complete releases before projection.
This feature packages the developer-facing guidance and final validation steps needed to roll out the metadata contract and release snapshot behavior safely. It solves the adoption problem by documenting the new released metadata semantics and by making sure the final implementation is exercised through focused and full-solution validation. The work updates API guidance, documentation indexes, and quickstart notes so consumers and maintainers can understand the new assignment-only contract, release immutability behavior, and expected validation pathways. It also runs documentation validation, targeted service and integration test suites, and full build and test validation across the solution so the release snapshot foundation, CDP delivery cutover, and breaking contract changes are verified together rather than in isolation. Acceptance is straightforward: the docs must describe the final field names and behavior actually implemented, documentation checks must pass, and the targeted plus solution-wide validation commands must complete successfully. These tasks should happen after the contract, projection, and lifecycle changes stabilize so the published guidance and verification results reflect the real final state.
This feature establishes the release-time snapshot model and publication lifecycle needed to make released metadata durable and trustworthy. It solves the core consistency problem by ensuring release artifacts carry their own governed metadata snapshot and by introducing explicit publication state so incomplete or failed publications are not treated as consumable releases. The implementation spans shared models, repository persistence, release orchestration, test data builders, and service-level verification. It adds publication-state fields to release records, extends manifest and released item snapshot models with metadata snapshot timestamps and canonical hash fields, introduces repository operations for state persistence with optimistic concurrency, and implements release service behavior for initialization, publish-complete, failure, retry, and reconciliation paths. Canonical content/metadata/binding hash helpers and audit helpers in the release service provide the verification backbone, while API, Azure repository, integration seed helpers, and unit/integration tests validate state transitions, mismatch handling, persistence behavior, and hidden visibility of non-complete releases across downstream consumption paths. Implementers must preserve the post-feature cutover rule: only post-feature releases participate in the new publication-state semantics, and only publish-complete releases are eligible for downstream delivery. Acceptance signals include deterministic transition coverage for in-progress, failed, retried, reconciled, and publish-complete states, durable recording of failure details and snapshot evidence, and proof through integration tests that failed or in-progress coordinates remain hidden from publication, object, and content package delivery flows.
This feature delivers metadata parity between the authoring platform and CDP for governed profile assignments while restoring immutability for released 150% publications. It solves the problem where CDP responses could drift from approved release-time values by ensuring governed profile and classification metadata are captured into release snapshots and projected only from those snapshots. The implementation adds MetadataDomain-based snapshot fields to released item models, captures object-level, version-level, and classification assignments during release creation, excludes keys without effective released values, and incorporates those assignments into metadata hash calculations so release verification reflects governed metadata changes. On the delivery side, snapshot-backed fields are added to projections and mapped through shared Azure helper logic so direct object lookups and content package objects use the same projection path, removing reliance on live object metadata for post-feature released responses. Unit, service, and seeded integration tests prove parity across direct and packaged delivery, verify snapshot capture, show that post-release edits do not mutate old publications, and confirm that republish is required before new values appear in CDP. A key constraint is scope: only object-level and version-level governed metadata are included, while subversion-level metadata remains out of scope. Acceptance depends on demonstrating that historical live metadata sources no longer influence post-feature released responses, that classification and governed profile assignments remain frozen in old release artifacts after authoring changes, and that only a new approved release plus recipe republish exposes updated metadata values.
No description available
No description available
No description available
No description available
No description available
No description available
No description available
No description available
User stories linked from other projects
## Story Statement As a digital delivery lead, I want a topic-based information model so that content can be delivered dynamically instead of being constrained by publication-only workflows. ## Business Value - Enables digital-first delivery beyond publication-centric workflows. - Improves content discoverability and targeted delivery. - Supports scalable reuse through topic-based architecture.
View in Azure DevOps →## Story Statement As an integration consumer, I want published content to include associated metadata so that downstream systems can identify, filter, and process content correctly. ## Business Value - Improves content filtering and precision in delivery channels. - Supports scalable taxonomy management across products. - Increases downstream automation through richer metadata context.
View in Azure DevOps →Title: Propagate topic relationship changes to downstream systems Story Statement:As a Publishing/Integration Manager, I want topic-link relationship changes from the CCMS to propagate reliably to downstream systems, so that end users receive consistent, up-to-date cross-topic navigation. Business Value: Keeps downstream outputs aligned with CCMS relationships. Ensures downstream outputs navigate correctly. Reduces manual rework and integration drift. Improves trust in published relationship data.
View in Azure DevOps →## Story Statement As a digital content owner, I want HTML outputs from the platform so that information can be delivered in web-ready formats. ## Business Value - Improves publishing throughput and release predictability. - Reduces output defects across variants and formats. - Strengthens downstream readiness with consistent publish artifacts.
View in Azure DevOps →## Story Statement As a publishing operator, I want to deploy outputs and metadata to predefined external targets on demand so that downstream business systems can consume updates reliably without manual transfer steps. ## Business Value * Improves interoperability with AGCO enterprise systems. * Reduces manual transfer steps in downstream delivery. * Increases reliability of automated data exchange.
View in Azure DevOps →Related requirement tasks from other projects
Description Platform Status: PPT Status: MVP: Yes Must Have: Priority 1 (A) Use Case Many topics link to each other or relate. Is this capability possible (link from topic A to B and E and then back to A) Current Challenges Loss of relationship table functionality with PTC WC.
View in Azure DevOps →