Enterprise publication architecture

Provenance is a system, not a head-tag checklist.

For shared SPAs, trustworthy publication requires seven coordinated layers: stable identity, share previews, semantic meaning, visible evidence, rights signals, delivery integrity, and verifiable authenticity.

Adopt the default profile Copy implementation templates

IdentityCanonical work and revision

HTML links

PreviewPortable share card

Open Graph

SemanticsMachine-readable entities

JSON-LD

EvidenceClaims, sources, review

PROV-O

RightsLicense and usage policy

TDM / AI prefs

DeliveryHTTP integrity and policy

Digest / CSP

AuthenticitySigned content history

C2PA 2.4

Recommended default

Publish generated research at the “trustworthy shared” profile.

Every externally shared artifact should arrive with complete initial metadata, visible authorship and AI disclosure, an immutable revision identity, a source ledger, and a correction path. Add cryptographic signing only when the publishing workflow can preserve and verify final bytes.

Share-complete initial responseNo post-hydration dependency for title, description, image, or canonical identity.

Visible and machine-readable evidenceThe human panel and JSON ledger must agree.

Mutable latest + immutable revisionSeparate discoverability from exact citation.

No false verification claimsA checksum is not a signature. A valid signature is not proof of truth.

Assign each trust question to the right layer.

Metadata becomes coherent when each representation has a single job. Do not force HTML meta tags to carry lineage, licensing, delivery security, and cryptographic proof at once.

Layer	Question answered	Primary mechanism	Failure if omitted	Status
Identity	What work and revision is this?	`canonical`, `cite-as`, version links, identifiers	Routes collapse into an ambiguous document identity.	Stable
Preview	How should this URL render when shared?	Open Graph and a public absolute image URL	Generic, stale, or empty cards.	Stable
Semantics	What entities and relationships are present?	Schema.org JSON-LD	Search and downstream systems infer structure inconsistently.	Stable
Evidence	What supports each material claim?	Visible source anchors, claim ledger, PROV-O sidecar	Sources become decorative rather than auditable.	Stable
Rights	What use is permitted, reserved, or licensed?	`license`, `usageInfo`, TDMRep; emerging AIPREF	Provenance is mistaken for permission.	Mixed maturity
Delivery	Was this response delivered intact and under what policy?	HTTP headers, digest fields, CSP, caching	The page can be correct at build time but altered or mis-served.	Stable
Authenticity	Can signed assertions be verified against this exact asset?	Content Credentials / C2PA	“Verified” remains a self-asserted badge.	Advanced

Fact

The initial response is the share contract.

LinkedIn requires Open Graph fields in source markup and may cache previews. Route-specific metadata should therefore exist before application hydration. S2 S3

Analysis

One normalized model should drive every view.

Generate HTML tags, JSON-LD, the visible panel, source ledger, and signing inputs from the same canonical artifact record.

Boundary

Trust signals are not truth judgments.

Content Credentials can verify association and tamper evidence, but provenance alone cannot establish that content is accurate or complete. S9

Start with a deployable head profile.

Use absolute production URLs, explicit lifecycle dates, registered link relations, and a stable preview image. Do not include a C2PA link until a real manifest exists and verifies.

Recommended shared-artifact head

<meta charset="utf-8">
<meta name="viewport"
  content="width=device-width, initial-scale=1, viewport-fit=cover">

<title>Artifact title · Publisher</title>
<meta name="description" content="Factual, standalone synopsis.">
<meta name="author" content="Accountable person or organization">
<meta name="generator" content="Artifact pipeline 4.0">
<meta name="robots" content="index,follow,max-image-preview:large">
<meta name="referrer" content="strict-origin-when-cross-origin">

<!-- Work identity and rights -->
<link rel="canonical" href="https://example.com/research/provenance">
<link rel="cite-as" href="https://example.com/research/provenance/v/2.1.0">
<link rel="latest-version" href="https://example.com/research/provenance">
<link rel="author" href="https://example.com/authors/name">
<link rel="license" href="https://example.com/licenses/content">

<!-- Share preview -->
<meta property="og:title" content="Artifact title">
<meta property="og:description" content="Standalone synopsis.">
<meta property="og:type" content="article">
<meta property="og:url" content="https://example.com/research/provenance">
<meta property="og:image" content="https://example.com/assets/provenance-v2.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Meaningful description of the preview image.">
<meta property="article:published_time" content="2026-07-21T18:48:00-04:00">
<meta property="article:modified_time" content="2026-07-21T18:48:00-04:00">

<!-- Add only after signing and deployed-byte verification -->
<link rel="c2pa-manifest"
  href="https://example.com/provenance/artifact-v2.c2pa"
  type="application/c2pa">

Identity

Use absolute production URLs

Relative URLs are acceptable in a downloadable file but are not a public deployment contract.

Citation

Use `cite-as` for the immutable record

The registered relation identifies the preferred permanent citation target. S10

Authorship

Separate accountable author from generator

Google recommends a resolvable author URL or sameAs to disambiguate identity. S4

Preview

Publish before distributing

Share systems cache previews. Version the image URL and inspect the final public URL before launch. S3

Model a compact semantic graph.

Use Schema.org for public meaning and discovery. Use a separate evidence ledger or PROV-O sidecar for detailed generation events, source retrieval, review, and revision lineage.

Schema.org 30.0 profile

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://example.com/authors/name#person",
      "name": "Accountable Author",
      "url": "https://example.com/authors/name"
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/report#webpage",
      "url": "https://example.com/report",
      "name": "Artifact title",
      "mainEntity": { "@id": "https://example.com/report#article" }
    },
    {
      "@type": ["TechArticle", "DigitalDocument"],
      "@id": "https://example.com/report#article",
      "mainEntityOfPage": { "@id": "https://example.com/report#webpage" },
      "headline": "Artifact title",
      "author": { "@id": "https://example.com/authors/name#person" },
      "publisher": { "@id": "https://example.com/#publisher" },
      "datePublished": "2026-07-21T18:48:00-04:00",
      "dateModified": "2026-07-21T18:48:00-04:00",
      "version": "2.0.0",
      "creativeWorkStatus": "Published",
      "isBasedOn": [{ "@id": "#primary-standard" }],
      "citation": [{ "@id": "#supporting-source" }],
      "correction": "https://example.com/report/corrections",
      "license": "https://example.com/licenses/content",
      "usageInfo": "https://example.com/content-usage",
      "sdPublisher": { "@id": "https://example.com/#publisher" },
      "sdDatePublished": "2026-07-21",
      "sdLicense": "https://example.com/licenses/structured-data"
    }
  ]
}

Separate the page from its main work

WebPage describes the delivered page. TechArticle or another CreativeWork subtype describes the intellectual work. Connect them with mainEntity and mainEntityOfPage.

Use isBasedOn only for derivation

A work can cite a source without being derived from it. Keep citation, isBasedOn, and detailed provenance relationships semantically distinct.

Expose corrections and lifecycle

Use a visible correction policy and the Schema.org correction property when applicable. Keep creativeWorkStatus aligned with the visible status.

Do not hide meaning only in JSON-LD

Google’s structured-data guidance requires markup to describe visible page content. The visible provenance panel should reflect the same author, dates, status, and sources. S4

Make evidence inspectable at the claim level.

A bibliography answers “what was consulted.” A claim ledger answers “what supports this statement, what kind of statement is it, and how confident are we?”

Human interfaceShow provenance near the artifact, not behind metadata tooling.

Readers should see the accountable author, generator, publication and review dates, version, status, source methodology, limitations, correction path, and verification state.

Machine interface

Use PROV-O when event lineage matters

Model sources and revisions as entities, generation and review as activities, and people or software as agents. Relationships such as used, wasGeneratedBy, wasAttributedTo, and wasRevisionOf preserve audit detail without bloating public Schema.org markup. S7

Fact

Externally verifiable

A direct statement from an authoritative source or observed artifact.

Analysis

Reasoned synthesis

A conclusion produced by connecting facts. Cite the supporting premises.

Recommendation

Proposed action

A direction chosen under stated constraints, alternatives, and trade-offs.

Limitation

Known boundary

An uncertainty, missing source, implementation dependency, or unresolved decision.

Claim ledger fragment

{
  "id": "C3",
  "selector": "#content-credentials [data-claim='hard-binding']",
  "claim": "An external HTML C2PA manifest binds to the entire stored document bytes.",
  "kind": "fact",
  "confidence": "high",
  "sourceIds": ["S8"],
  "review": {
    "status": "verified-against-primary-source",
    "reviewedAt": "2026-07-21T18:48:00-04:00"
  }
}

Extend the contract beyond HTML.

Response headers can reinforce identity, integrity, caching, and browser security. They complement—not replace—the artifact’s semantic and provenance layers.

Illustrative production response

HTTP/2 200
Content-Type: text/html; charset=utf-8
Content-Language: en-US
Last-Modified: Tue, 21 Jul 2026 22:48:00 GMT
ETag: "sha256-build-2.1.0"
Cache-Control: public, max-age=300, stale-while-revalidate=86400

Link: <https://example.com/report>; rel="canonical"
Link: <https://example.com/report/v/2.1.0>; rel="cite-as"
Link: <https://example.com/report/v/2.1.0.c2pa>; rel="c2pa-manifest"; type="application/c2pa"

Content-Digest: sha-256=:BASE64_DIGEST:
Content-Security-Policy: default-src 'self'; img-src 'self' https: data:; object-src 'none'; base-uri 'none'
Permissions-Policy: camera=(), microphone=(), geolocation=()
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff

✓

Digest fields

Content-Digest and Repr-Digest communicate hashes for HTTP content or representations. They detect changes when a trusted expected digest is available. S11

✓

HTTP Message Signatures

RFC 9421 signs selected HTTP message components and can include a digest field. It authenticates delivery assertions, not the full editorial lineage of the work. S12

Checksum files

A downloadable SHA-256 file is useful for transport verification only when the expected checksum is obtained through a trusted channel. It is not a signer identity.

ETag

An ETag is primarily a cache validator. Its format is server-defined and it should not be presented as cryptographic provenance.

Use Content Credentials for verifiable provenance.

C2PA 2.4 provides native HTML association, AI disclosure, and cryptographic binding. The workflow is strict because the document is treated as stored bytes, not as a normalized DOM.

Normative HTML ruleUse one association. Prefer an external manifest.

C2PA 2.4 allows either one link rel="c2pa-manifest" or one inline script type="application/c2pa". More than one association is invalid. The specification prefers the external form. S8

Critical boundary

Signed provenance does not equal factual truth

Content Credentials establish that assertions are associated with an asset, signed, and tamper-evident. They do not independently establish that every assertion or the depicted content is true. S9

Finalize the publication object

Resolve content, metadata, sources, visible provenance, rights, and lifecycle status.

Apply every byte-changing transformation

Minify, inject production scripts, normalize line endings, set absolute URLs, and complete edge or CDN modifications.

Create the C2PA hard binding

For an external manifest, C2PA hashes the entire stored HTML document with no exclusion range. Reserialization changes the binding. S8

Sign and publish the manifest

Include relevant actions, ingredients, digital source type, AI disclosure, signer identity, and timestamps according to policy.

Verify after public delivery

Fetch the deployed URL through the real CDN path and validate the manifest against the response bytes.

AI disclosure

Use the native assertion

C2PA 2.4 introduces c2pa.ai-disclosure to carry verifiable AI transparency information and complement actions and digital source type. S8

Media assets

Sign ingredients independently

A page-level credential does not replace provenance for generated share cards, charts, screenshots, audio, or video used as ingredients.

Durability

Plan for metadata stripping

Durable Content Credentials can use soft bindings such as fingerprints or watermarks to rediscover provenance when a manifest is separated. S9

Keep provenance, access, and usage rights separate.

Sharing a public URL does not imply permission for every downstream use. Rights signals need their own explicit policy and maturity labels.

Signal	Controls	Mechanism	What it does not do	Maturity
Access control	Who can retrieve the content	Authentication, authorization, network policy	A public metadata tag cannot secure private content.	Established
Crawler access	Which cooperative crawlers may request URLs	`robots.txt`	Not an indexing guarantee, security boundary, license, or downstream usage grant. S15	Established
Indexing and snippets	Search indexing and presentation	`robots` meta, `X-Robots-Tag`, `data-nosnippet`	Does not express licensing or AI training preferences.	Established
Copyright license	Permitted reuse under legal terms	`rel=license`, Schema.org `license`, visible terms	Metadata alone may not satisfy every legal or contractual requirement.	Established
TDM reservation	Reservation of text and data mining rights and policy discovery	W3C TDMRep	It is a Community Group report and must be evaluated against applicable law and platform support.	Final CG report
AI usage preference	Preferences for automated processing uses	IETF AIPREF vocabulary and attachment work	It is not yet a published RFC and should not be treated as a settled standard.	Internet-Draft
Provenance	History, responsibility, transformations	Visible ledger, PROV-O, Content Credentials	Does not itself grant permission for reuse.	Mixed mechanisms

Current

TDMRep 1.0

The W3C Community Group final report defines a protocol for reserving text and data mining rights and discovering licensing policies. S13

Emerging

IETF AIPREF

The working group is standardizing vocabulary and attachment mechanisms, but the current vocabulary is an Internet-Draft. Architect an extension point; do not hard-code it as final. S14

Avoid

Invented “AI meta tags”

Do not publish proprietary tags as if they were interoperable standards. Label vendor-specific signals and experimental drafts explicitly.

Treat publication history like a versioned API.

One URL should orient readers to the current work. Another should preserve the exact revision that was cited, reviewed, hashed, or signed.

Mutable work URL/research/html-provenance

Current version, human sharing, search discovery, and the stable product identity.

Immutable revision URL/research/html-provenance/v/2.1.0

Exact citation, historical audit, source ledger, checksum, and Content Credential binding.

Registered link relations

Use cite-as, latest-version, predecessor-version, successor-version, version-history, and deprecation where they match the lifecycle. S10

Corrections are first-class events

Preserve the original revision, publish a correction record, update the latest pointer, and connect versions in the evidence graph.

Dates have distinct meanings

Track created, first published, materially modified, structured-data published, reviewed, signed, and superseded timestamps separately.

Revision link set

<link rel="canonical" href="https://example.com/report/v/2.1.0">
<link rel="cite-as" href="https://example.com/report/v/2.1.0">
<link rel="latest-version" href="https://example.com/report">
<link rel="predecessor-version" href="https://example.com/report/v/1.4.0">
<link rel="version-history" href="https://example.com/report/history">

Compile all outputs from one typed provenance object.

Separate the knowledge model from its presentation. The same canonical record should render HTML metadata, JSON-LD, visible provenance, source ledgers, HTTP headers, and signing assertions.

TypeScript canonical publication model

type Maturity = "draft" | "shared" | "public" | "verifiable";
type ClaimKind = "fact" | "observation" | "analysis" | "recommendation" | "prediction" | "limitation";

interface PublicationArtifact {
  schemaVersion: "2.0";
  profile: Maturity;

  identity: {
    id: string;
    workUrl: string;
    revisionUrl: string;
    citeAsUrl: string;
    version: string;
    status: "draft" | "reviewed" | "published" | "corrected" | "superseded";
    title: string;
    description: string;
    language: string;
  };

  responsibility: {
    author: Party;
    publisher: Party;
    generator?: SoftwareAgent;
    reviewers: Party[];
    humanOversight: "none" | "sampled" | "reviewed" | "approved";
  };

  lifecycle: {
    createdAt: string;
    publishedAt?: string;
    modifiedAt: string;
    reviewedAt?: string;
    signedAt?: string;
    supersedes?: string;
    supersededBy?: string;
    correctionUrl?: string;
  };

  preview: {
    imageUrl: string;
    imageAlt: string;
    width: 1200;
    height: 630;
  };

  evidence: {
    sources: SourceRecord[];
    claims: ClaimRecord[];
    methodologyUrl?: string;
    limitations: string[];
  };

  rights: {
    licenseUrl?: string;
    usageInfoUrl?: string;
    tdmPolicyUrl?: string;
    aiPreferences?: Array<{
      vocabulary: string;
      maturity: "stable" | "emerging" | "vendor-specific";
      value: unknown;
    }>;
  };

  integrity: {
    contentDigest?: string;
    httpSignature?: SignatureRecord;
    c2pa?: {
      manifestUrl: string;
      signer: string;
      verifiedAt: string;
      verificationResult: "valid" | "invalid" | "inaccessible";
    };
  };

  build: {
    buildId: string;
    sourceCommit?: string;
    environment: "development" | "preview" | "production";
    finalByteDigest?: string;
  };
}

Validate

Schema, required fields, URL policy, dates, claim coverage.

Render

HTML head and route-specific initial response.

Describe

Schema.org and evidence sidecars.

Expose

Visible provenance, limitations, correction path.

Harden

Headers, caching, CSP, access policy.

Sign

Final bytes and asset ingredients when required.

Verify

Public delivery, preview rendering, digest, credential.

Gate publication by profile.

The validation pipeline should fail closed when required identity, evidence, rights, or verification fields are missing. Use progressive rigor rather than pretending every draft needs the same controls.

Draft requirements

Clear draft status and owner.
noindex where publicly accessible but not publishable.
No public source URLs that expose restricted systems.
Known limitations captured.

Do not claim

Human approval that has not occurred.
Public readiness.
Cryptographic verification from a local checksum.

Required release gate

Initial HTML contains route-specific title, description, canonical, and preview metadata.
Absolute public preview image with alt text and 1.91:1 landscape dimensions.
Visible author, generator, dates, version, status, methodology, limitations, and sources.
Schema.org graph validates and matches visible content.
Immutable revision URL and correction path exist.
Mobile, dark mode, print, reduced motion, and keyboard navigation pass.
Component contrast passes in light, dark, auto/system, hover, focus, active, selected, and disabled states when present.
Normal text meets 4.5:1; large text and meaningful UI graphics or boundaries meet 3:1.
Focus indicators maintain 3:1 against adjacent colors and remain visible in forced-colors mode.
A machine-readable contrast report records measured ratios, exceptions, and remediations.

Evidence gate

Material factual claims map to primary sources.
Analysis and recommendations are labeled.
Source retrieval dates and access classifications are recorded.
Restricted sources are redacted or represented by safe identifiers.
No false “verified” or “human reviewed” language.

Public authoritative additions

Publisher and author profiles resolve publicly.
License, usage policy, correction policy, and contact path are public.
Version history and supersession links are machine-readable.
HTTP security, caching, digest, sitemap, and robots behavior are tested.
Preview cache inspection is complete.

Operational controls

Owner and review cadence assigned.
Broken-link and source-staleness monitoring enabled.
Retraction or deprecation procedure tested.
Artifact bundle retained in immutable storage.

Verifiable additions

Final production bytes are frozen before signing.
Exactly one valid C2PA association exists.
Signer identity, trust chain, timestamp, assertions, and ingredients are policy-approved.
Public response verifies through the CDN path.
Media ingredients have independent provenance when required.

Failure handling

Invalid or inaccessible manifests never render as “verified.”
Verification state includes time and validator identity.
Signing-key rotation and certificate lifecycle are documented.
Unsigned content is not automatically treated as untrustworthy.

Red team

Can a generic shell be shared?

Inspect raw HTML without JavaScript. Share crawlers must receive the final route’s metadata.

Red team

Can a signer make false claims?

Yes. Validate signer trust and assertion meaning; do not reduce the experience to a green check.

Red team

Can metadata expose secrets?

Yes. Source URLs, prompts, model endpoints, reviewer identities, build IDs, and internal paths need disclosure policy.

This artifact implements its own guidance.

The visible record below mirrors the embedded JSON-LD and claim ledger. It does not claim a Content Credential because no C2PA manifest has been generated or verified.

Artifact record

Modern HTML Metadata & Provenance

Research rebuilt against current primary standards and clearly separated into established, optional, and emerging mechanisms.

Research direction: Jesse Graupmann
Generator: OpenAI ChatGPT · GPT-5.6 Thinking
Generated: July 21, 2026 · 7:15 PM EDT
Version: 2.1.0
Method: AI-assisted research synthesis using primary standards
Review state: Assistant-validated, including component contrast; human sign-off pending
Content Credential: Not attached; no cryptographic verification claimed
Correction path: Publish a new immutable revision and retain this version

Principal claim-to-source map.

The embedded ledger contains the same claims in machine-readable form.

C1recommendationhigh confidence

A shareable SPA should expose route-specific metadata in the initial HTML response rather than relying only on post-hydration mutation. S2 S3 S4

C2facthigh confidence

C2PA 2.4 defines native HTML association through one external link or one inline application/c2pa script; external association is preferred. S8

C3facthigh confidence

For an external C2PA manifest, the hard binding covers the entire stored HTML byte representation, so reserialization can invalidate verification. S8

C4facthigh confidence

Content Credentials establish tamper-evident provenance signals; they do not independently establish that content is true or complete. S9

C5facthigh confidence

Schema.org 30.0 is the current stable release used as the semantic baseline in this artifact. S5

C6analysishigh confidence

HTTP digest fields communicate integrity digests, while HTTP Message Signatures authenticate selected HTTP message components; neither replaces content-level provenance. S11 S12 S8

C7facthigh confidence

TDMRep is a finalized W3C Community Group report, while IETF AI Preferences remains an Internet-Draft and should be labeled emerging. S13 S14

C8analysishigh confidence

Crawler access controls, indexing controls, downstream usage preferences, licensing, and provenance are separate policy planes. S13 S14 S15 S8

C9recommendationhigh confidence

Component-level contrast validation is a mandatory release gate: normal text meets 4.5:1, large text and meaningful non-text UI meet 3:1, and focus indicators remain contrasted against adjacent colors. S17 S18 S19

Primary standards and implementation references.

Research prioritizes normative specifications, standards bodies, and official platform documentation. Emerging work is labeled as work in progress.

Provenance is a system, not a head-tag checklist.

Publish generated research at the “trustworthy shared” profile.

Assign each trust question to the right layer.

The initial response is the share contract.

One normalized model should drive every view.

Trust signals are not truth judgments.

Start with a deployable head profile.

Use absolute production URLs

Use cite-as for the immutable record

Separate accountable author from generator

Publish before distributing

Model a compact semantic graph.

Make evidence inspectable at the claim level.

Use PROV-O when event lineage matters

Externally verifiable

Reasoned synthesis

Proposed action

Known boundary

Extend the contract beyond HTML.

Digest fields

HTTP Message Signatures

Checksum files

ETag

Use Content Credentials for verifiable provenance.

Signed provenance does not equal factual truth

Finalize the publication object

Apply every byte-changing transformation

Create the C2PA hard binding

Sign and publish the manifest

Verify after public delivery

Use the native assertion

Sign ingredients independently

Plan for metadata stripping

Keep provenance, access, and usage rights separate.

TDMRep 1.0

IETF AIPREF

Invented “AI meta tags”

Treat publication history like a versioned API.

Registered link relations

Corrections are first-class events

Dates have distinct meanings

Compile all outputs from one typed provenance object.

Validate

Render

Describe

Expose

Harden

Sign

Verify

Gate publication by profile.

Draft requirements

Do not claim

Required release gate

Evidence gate

Public authoritative additions

Operational controls

Verifiable additions

Failure handling

Can a generic shell be shared?

Can a signer make false claims?

Can metadata expose secrets?

This artifact implements its own guidance.

Modern HTML Metadata & Provenance

Principal claim-to-source map.

Primary standards and implementation references.

Use `cite-as` for the immutable record