Product data governance

Product data governance is the set of rules that controls when product information can be edited, checked, reviewed, approved, published, shown publicly, repaired by stewards, or updated in bulk.

Governance is not one status. A product can be approved but still internal. It can be published but still hidden from public search. It can have a ready workflow but still be blocked by data, identity, category-template, variant-family, or brand-authority rules.

Core idea

Actualog separates product governance into several axes:

• human review workflow;
• publication intent;
• data quality;
• calculation state;
• identity readiness;
• record state;
• effective public visibility;
• company or stewardship authority.

Product Overview and Product Stewardship combine these axes into readable rows, filters, repair queues, actions, and Mass Update scope.

Workflow status

Workflow status describes human review state for canonical product data.

Workflow controls review. It does not replace data checks, publication, or public visibility gates.

Publication status

Publication status describes whether a product is intended to be visible outside management workspaces.

Published is not the same as public. It is one required condition for public visibility.

Data status

Data status comes from the latest successful data check.

Data status is stored. Product Overview reads it; it does not recalculate the product while rendering the row.

Calculation status

Calculation status describes the technical state behind the data status.

Use Check data when calculation is missing, stale, failed, or required after significant data changes.

Identity status

Identity status describes whether Actualog can determine the product's canonical identity.

Identity can depend on category identity policy, product identifiers, brand, manufacturer, Brand Owner, variant axes, and category-template data.

Effective visibility

Effective visibility is the materialized result of all public visibility gates.

A product appears in public search, public category pages, public company product lists, public catalog rows, public media, and sitemap only when all required gates pass.

Product comparison is a signed-in working surface, not a publishing gate. It follows public visibility for products the viewer cannot manage, and it can include Internal products only when the server confirms that the signed-in user has product management, Brand Owner, or category stewardship access. Comparing an Internal product does not make it discoverable in public lists.

Public visibility normally requires:

• active, non-deleted record state;
• workflow is Approved;
• publication is Published;
• data status is Ready;
• calculation status is Current;
• identity is complete;
• no blocking quality reasons;
• effective visibility is public;
• if the product belongs to a variant family, the family also allows public visibility.

If any gate fails, public discovery routes hide the product. Managers use Product Overview, Product Edit, Product Stewardship, catalog management, management popovers, or authorized comparison to inspect internal records.

Record state and family gates

A product can also be blocked by record or family state.

Examples:

• deleted or merged records are not public;
• a concrete variant can be blocked by a parent variant group;
• a variant family can be public only when the family is approved, published, ready, active, and has at least one public child variant;
• a family-level command can affect many child variants and may log cascade counts.

For this reason, Product Overview rows sometimes show both group-level and representative-product status details.

Authority model

Governance authority answers: "Who is allowed to change or finalize this product?"

Authority is different for Brand products and Standard products.

Brand products

Brand products are governed by the resolved Brand Owner company.

The Brand Owner company is the canonical authority for brand product data and final governance. Users from that company still need the required product permissions, such as Manage product data or governance approval permissions.

If a Brand product has no Brand Owner, conflicting Brand Owners, or a brand that is not valid for the Brand Owner/category scope, final governance is blocked until repaired.

Other companies can have ordinary relationships to the Brand product, such as Distributor, Supplier, Consumer, Designer, Service provider, or Manufacturer. Those relationships can make the product visible or useful in their workspace, but they do not make those companies the Brand Owner.

Standard products

Standard products are governed through stewardship rather than one hidden owner company.

Application Administrators can support and repair Standard products globally.

Category Stewards can repair and govern Standard products inside their server-resolved assigned product-category scope.

Company contributors can edit some Standard product data while the product is Draft or Rejected and Internal, when the active company relationship and user permissions allow it. Company contributors do not automatically get final approval or publication authority for Standard products.

Company relationships

Products use explicit company relationships. There is no hidden product owner column.

Ordinary relationship roles include:

• Manufacturer;
• Designer;
• Consumer;
• Distributor;
• Service provider;
• Supplier.

Brand Owner is special. It is part of brand authority and is not edited as an ordinary related-company role in Mass Update.

Variant families can also have group-scoped company relationships. Product Overview and media visibility can read both product-scope and group-scope relationships.

Who can do what

Permissions are checked on the server. The UI may hide or disable actions, but server-side permission and state checks are authoritative.

Product Overview

Use Product Overview for products your selected company can manage.

Product Overview can show unpublished products because it is a management workspace, not a public page. It is the right place to find and repair:

• drafts;
• rejected products;
• internal products;
• incomplete products;
• invalid data;
• identity conflicts;
• missing brand or invalid brand assignment;
• products ready to publish;
• products needing Check data;
• products affected by category-template changes.

Product Overview uses company authority. For Brand products, that normally means the workspace company is the Brand Owner authority. For Standard products, the company must have an allowed contributor relationship and the product state must allow company editing.

Product Stewardship

Use Product Stewardship when products need platform-level or category-level repair instead of ordinary company management.

Product Stewardship is for Application Administrators and Category Stewards. It uses the same row components, status badges, filters, queue behavior, selection model, and Mass Update platform as Product Overview, but the scope is resolved from stewardship authority rather than company workspace authority.

Stewardship helps find and repair:

• missing brand;
• missing manufacturer;
• missing or invalid Brand Owner;
• missing company relationship;
• data check required;
• incomplete data;
• invalid data;
• identity or grouping conflicts;
• Standard products outside ordinary company-managed scope.

Public surfaces

Public category browse, public company product lists, public catalogs, public media, sitemap, and global/navbar search use public-only access.

They do not show Internal products just because the visitor is signed in. Direct product detail and product comparison are still server access-checked per actor: authorized managers and stewards may inspect selected Internal products for governance work, while users without that access receive a clear denial or see the product omitted from the comparison.

Use Product Overview, Product Edit, Product Stewardship, catalog management, management popovers, or authorized comparison to inspect internal products.

Product Overview filters and governance

Product Overview filters are governance-aware.

You can filter by:

• workflow;
• publication;
• data status;
• identity status;
• issue flags;
• completeness;
• category;
• brand;
• company role;
• product shape;
• category-template attribute values when one category is selected.

These filters work against the management scope. They help find products that need governance decisions or repair before public release.

Attribute filters and governance

Attribute filters appear in Product Overview after exactly one category is selected. They are based on the selected category's current effective template.

This matters for governance because category templates define many product data rules:

• which attributes are available;
• which attributes are required;
• which attributes affect name generation;
• which attributes affect identity;
• which values are valid;
• which units or lists are allowed;
• which products need rechecking after template changes.

Product Overview attribute filters use filterable Text, Numeric, List, and Boolean attributes from the effective template. They help narrow the management list to products with particular technical or commercial values before running Check data, Mass Update, export, or manual review.

Attribute filters do not override governance authority. They narrow the products inside the scope you are already allowed to see.

Selection and governance operations

Selection in Product Overview and Product Stewardship is part of governance safety.

You can select explicit rows or all products matching the currently applied filters. The header checkbox selects the filtered result scope, not only the visible page. After selecting the filtered scope, you can uncheck visible rows to exclude them.

Bulk operations are disabled while filters are dirty. You must apply filters first so the selected target set matches the visible result list.

When you queue Mass Update, export, Check data, Recalculate identity, workflow, or publication operations, Actualog sends the selected scope to the server. The server validates permissions, freezes the target set, and rechecks permissions and product state while the queued work runs.

Governance actions

Typical Product Overview and Product Stewardship actions include:

• Edit product or family data;
• Save draft while data is changing;
• Submit for approval when data is ready;
• Approve when the actor has review authority;
• Reject with a required reason;
• Return to draft for additional revisions;
• Publish only when public visibility gates allow it;
• Unpublish when a product must be removed from public availability;
• Check data to recalculate quality;
• Recalculate identity after identity-relevant changes;
• Mass Update for queue-backed bulk changes.

The UI asks the workflow service for allowed actions and disabled reasons. Do not assume that a visible row means every action is allowed.

Check data

Check data evaluates product or variant-family readiness against category, attribute, identity, brand, relationship, and quality rules.

It can mark products as Ready, Incomplete, Invalid, or Conflict. It can also refresh blocking and non-blocking quality reasons.

When Check data finds a final non-ready result, safety invariants can move approved or pending records back to draft/internal, and published records can be unpublished. Rejected records remain rejected until a user revises them.

Recalculate identity

Recalculate identity updates identity state and grouping signals. Use it when identity-relevant inputs changed, such as:

• category identity policy;
• brand;
• Brand Owner;
• manufacturer;
• product identifiers;
• identity attributes;
• variant-axis values;
• category template version.

Identity conflicts must be resolved before final public governance can succeed.

Workflow and publication examples

Create or revise a product

1. Save the product as Draft while data is changing.
2. Run Check data.
3. Fix missing or invalid data.
4. Submit for approval when data is Ready.
5. A reviewer approves or rejects the product.
6. If approved and all public gates pass, publish the product.

Fix a rejected product

1. Open the product from Product Overview.
2. Read the rejection reason in governance details or history.
3. Revise the product.
4. Run Check data.
5. Submit again when ready.

Publish a product

1. Confirm workflow is Approved.
2. Confirm publication is Internal.
3. Confirm data status is Ready.
4. Confirm calculation status is Current.
5. Confirm identity is complete.
6. Confirm there are no blocking quality reasons.
7. Confirm the family state does not block the concrete product.
8. Use Publish.

If another public gate is blocking, Product Overview shows the blocker and repair actions instead of a misleading Publish action.

Mass Update and governance

Mass Update is part of the governance platform. It uses the same Product Overview or Product Stewardship selection model and queue behavior.

Use it for queue-backed changes such as:

• Check data;
• Recalculate identity;
• workflow or publication actions;
• update category attributes;
• update names by template;
• update lifecycle stage;
• update localized content;
• update media assets and primary image;
• update related company roles;
• update brand.

Destructive Mass Update actions are explicit. Empty fields do not delete data. The server validates recipes, freezes targets, and writes one aggregate product operation record with target-level details.

Result and audit history

Governance transitions write readable Action Log entries for workflow, publication, data status, calculation status, and effective visibility.

Mass Update writes one aggregate operation-level Action Log entry instead of one top-level log entry per product. Target details are stored with the operation result.

Family commands can store cascade information, such as affected, eligible, or still-internal child variant counts, so history can explain what happened to the family and its members.

Common mistakes

Do not treat Approved as public. Approved data can still be Internal or blocked by visibility gates.

Do not treat Published as public if data, identity, record, quality, or family gates are blocking.

Do not expect public lists or global search to reveal internal products. Use management workspaces or authorized management links.

Do not use global/navbar search to find internal products. Public search is public-only.

Do not assume Product Overview can change another company's Brand Owner authority. Use Product Stewardship or a dedicated repair process when your role allows it.

Do not assume a company relationship makes a company the governance owner. Brand Owner authority and ordinary company roles are different.

Do not run bulk governance actions while filters are dirty. Apply filters first.