Activity log

Every consequential thing that happens to a piece of content on the platform is written down once, the moment it happens, and never changed afterwards. A manuscript is imported, a chapter is translated, a keynote is summarised into a short book, an AI model drafts product copy — each is recorded as an Activity: an immutable entry naming what went in, what came out, who was responsible, and the contract or legal basis that authorised it. Together these entries form the Activity log — the platform's audit record for content.

The log is not an internal engineering artefact. It is available to every platform user, scoped to their own tenant, as the tool for answering audit questions about content. Four of those questions recur constantly, and each becomes a single filtered lookup rather than a forensic exercise:

• What did an AI model touch, and under what contract?
• What was this content derived from?
• Who is owed a share of what it earns?
• Who changed this, and when?

What makes the log trustworthy is that it records fact, not reconstruction. Nothing is written after the event from memory or inferred later from timestamps: the entry is created at the moment the action is taken, by the same system that takes it, and is append-only thereafter. No entry is ever edited or deleted, so a query today and the same query in five years return the same answer.

This page is the reference for the log as an audit tool: what a single entry contains, the full taxonomy of the eighteen activity types, and worked examples of real entries. It is deliberately distinct from Provenance & attribution, which tells the lineage story — how content nodes derive from one another as a graph you can walk. The relationship between the two is explained under The log and the graph below.

What a log entry records

Every entry, whatever the activity, answers the same handful of questions in the same shape. Read plainly, an entry says: this action, of this type, happened at this time; these agents were responsible; these tools were used; it acted on this content and produced that content; and it relied on this authority to do so.

The load-bearing parts are worth understanding before the field reference:

• A stable identity. Each entry has an activity_id with the act_ prefix and a readable slug — act_translate_mastering_x_fr — so it can be cited in a report, a ticket, or an audit finding and found again unchanged.
• A type. One of eighteen activity types, which says what kind of act this was — an ingestion, a translation, an AI enrichment, and so on.
• A timestamp. When the entry was recorded (created_at), and, where the real-world event happened earlier — a keynote captured the day before it was processed — a separate occurred_at.
• The agent, or agents, responsible. One or more agents, each with a kind of HUMAN, SYSTEM, or ORGANISATION. The agent is the accountable party. This is the single most important audit rule on the page: an AI model is never an agent. When a model does the work, the organisation that operated it is the agent — recorded with the role GENERATOR — and the model itself is recorded separately as tooling.
• The tooling used. The instrument: the model, its version, and the prompt, for AI-assisted work; the pipeline or automation, for a system action. An LLM lives here, so "exactly what did an AI model produce or touch?" is a filter over tooling, not an investigation.
• The subject and target. What content the action consumed (used) and what it produced (generated) — each a reference to a Resource, Source, Work, or ContentUnit, version-pinnable so the exact material is unambiguous.
• The rights basis. The authority the action relied on — either the governing Contract (with its version pinned at the moment of the action) or, where no grant covered the use, an asserted statutory exception. This is what turns the log from "what happened" into "what happened, and were we entitled to do it?"

{
  "AgentRef": {
    "agent_id": "agt_chandra",
    "kind": "HUMAN | SYSTEM | ORGANISATION",
    "name": "A. Chandra | Packt Publishing Limited | Ingestion pipeline",
    "role": "AUTHOR | TRANSLATOR | NARRATOR | GENERATOR | OPERATOR"
  },
  "NodeRef": {
    "node_id": "res_mastering_x_en",
    "node_type": "RESOURCE | SOURCE | WORK | CONTENT_UNIT | MANIFESTATION | PRODUCT | CONTRACT",
    "version": "ver_0195aaa",
    "role": "PRIMARY | SUPPORTING | BACKBONE | …"
  }
}

{
  "observed": {
    "source_medium": "TEXT",
    "output_medium": "TEXT",
    "source_language": "en",
    "output_language": "fr",
    "output_size": { "words": 78500 }
  }
}

The rights basis on every entry

Because the log is an audit tool, the field auditors reach for most is rights_basis: the recorded authority for an action that consumed content. It takes one of two forms, distinguished by a basis_type:

• Contract basis (the default). A governing contract grants the use, and the basis pins the contract version that was in force when the action happened. Consequential actions validate against that pinned version, and if the contract later changes, the platform reprojects the affected rights — so "under what contract was this done?" is answerable exactly, at the version that applied.
• Statutory-exception basis. Where no grant covers a use but the law permits it directly — quotation for criticism or review, parody, incidental inclusion, text-and-data mining — the entry records the asserted exception instead: which exception, in which jurisdictions, whether the source had been made public, a written justification, and who asserted it.

The platform records assertions; it never adjudicates them. Whether a use actually qualifies is a legal judgement. What the log contributes is evidence and accountability: the used edges pin exactly which content, at which version, was consumed; the observed snapshot freezes the proportions; and the assertion names the accountable agent. Full treatment lives in Provenance & attribution.

The log and the graph

Every Activity is written to the log — no exception. Only the subset that carries lineage also becomes nodes and edges in the Content Lake graph. Understanding the split matters, because it tells you which audit questions the log alone answers and which need the graph.

• The log holds everything. Whatever the activity — including the three enrichment types that create no new content — it is written to the append-only, immutable log and is searchable and filterable. This is the audit substrate: "what happened, when, by whom, over what?" is always answerable here.
• The graph holds the lineage subset. An Activity also becomes part of the graph if, and only if, it creates a new content node — a Work, Expression, Manifestation, or ContentUnit — or connects existing content nodes with an edge. This is the structure that provenance and royalty traversals run over. The graph is a projection of the log, not a second write: every graph Activity is also a log entry, but the reverse is not true.

In practice the log-only set is small and specific: the three enrichment activities — PI_GENERATION, ENTITY_EXTRACTION, and COVER_GENERATION — which attach metadata but create no new content node. Every origination, derivation, expression, manifestation, and fragment activity reaches the graph as well.

flowchart LR
    ACT["A content action<br/>happens"] --> LOGW["Written to the<br/>Activity log<br/>(always)"]
    LOGW -->|"creates or connects<br/>a content node"| GRAPH["Also becomes a<br/>graph node + edge<br/>(lineage subset)"]
    LOGW -->|"enrichment only<br/>(PI · entities · cover)"| LOGONLY["Stays in the log<br/>(no lineage)"]

The activity type taxonomy

There are eighteen activity types. They group by what they do, following the same five categories the platform uses everywhere: origination brings new content into being; derivation makes a new Work from existing content; expression re-realises the same Work in another language, mode, or corrected state; fragment pulls out a quotable piece; and enrichment attaches metadata without creating content. The Plane column shows whether an activity also reaches the lineage graph (GRAPH) or stays in the log only (LOG).

flowchart TD
    ROOT["The 18 activity types"] --> ORI["Origination<br/>new content"]
    ROOT --> DER["Derivation<br/>new Work from existing"]
    ROOT --> EXP["Expression<br/>same Work, new form"]
    ROOT --> FRA["Fragment<br/>a quotable piece"]
    ROOT --> ENR["Enrichment<br/>metadata only · log-only"]

The taxonomy is open by design; new product lines will add types over time (a future DUBBING, say). Every type — old or new — is always logged and searchable, whichever plane it lands on.

Example log entries

These are real log entries in the exact shape the log serves them. They illustrate what a business user will find when they query the log as an audit tool. Business readers never have to touch the JSON; it is here because the entries are the authoritative record behind every audit answer, and an AI or no-code tool can read them verbatim.

{
  "activity_id": "act_ingest_mastering_x",
  "type": "INGESTION",
  "created_at": "2026-06-20T09:12:00Z",
  "performed_by": [
    {
      "agent_id": "agt_pipe_ingest",
      "kind": "SYSTEM",
      "name": "Ingestion pipeline"
    }
  ],
  "used": [
    { "node_id": "src_mastering_x_manuscript", "node_type": "SOURCE" }
  ],
  "generated": [
    { "node_id": "wk_mastering_x", "node_type": "WORK" },
    { "node_id": "res_mastering_x", "node_type": "RESOURCE" }
  ],
  "creates_tier": "WORK",
  "work_relationship": "NEW_WORK",
  "fidelity": "VERBATIM",
  "rights_basis": {
    "node_id": "ctr_chandra_2026",
    "node_type": "CONTRACT"
  },
  "parameters": {
    "source_uri": "sharepoint://…/mastering-x-manuscript.docx",
    "importer": "sharepoint",
    "transformer": "markitdown",
    "source_format": "docx",
    "raw_checksum": "sha256:0f3a…"
  },
  "automation": "EVENT_TRIGGERED"
}

{
  "activity_id": "act_pi_mastering_x",
  "type": "PI_GENERATION",
  "created_at": "2026-04-12T10:11:12Z",
  "performed_by": [
    {
      "agent_id": "agt_packt",
      "kind": "ORGANISATION",
      "name": "Packt Publishing Limited",
      "role": "GENERATOR"
    }
  ],
  "used": [
    { "node_id": "res_mastering_x", "node_type": "RESOURCE", "role": "PRIMARY" },
    { "node_id": "res_commissioning_42", "node_type": "RESOURCE", "role": "BRIEF" }
  ],
  "generated": [
    { "node_id": "prod_mastering_x", "node_type": "PRODUCT" }
  ],
  "creates_tier": "NONE",
  "work_relationship": "N/A",
  "parameters": {
    "fields_generated": [
      "description_long",
      "keywords_seo",
      "what_you_will_learn"
    ]
  },
  "tooling": {
    "model": "claude-opus-4-6",
    "prompt_id": "prompt_pi_default_v3"
  }
}

{
  "activity_id": "act_translate_mastering_x_fr",
  "type": "TRANSLATION",
  "created_at": "2026-03-04T00:00:00Z",
  "performed_by": [
    {
      "agent_id": "agt_loc_team",
      "kind": "ORGANISATION",
      "name": "Localisation",
      "role": "TRANSLATOR"
    }
  ],
  "used": [
    { "node_id": "res_mastering_x_en", "node_type": "RESOURCE", "version": "ver_0195aaa" }
  ],
  "generated": [
    { "node_id": "res_mastering_x_fr", "node_type": "RESOURCE" }
  ],
  "creates_tier": "EXPRESSION",
  "work_relationship": "SAME_WORK",
  "fidelity": "VERBATIM",
  "derivation_type": "TRANSLATION",
  "royalty_flow": "INHERIT",
  "observed": {
    "source_language": "en",
    "output_language": "fr",
    "source_medium": "TEXT",
    "output_medium": "TEXT"
  }
}

{
  "activity_id": "act_compile_data_eng",
  "type": "COMPILATION",
  "created_at": "2026-03-10T00:00:00Z",
  "performed_by": [
    {
      "agent_id": "agt_ce_data",
      "kind": "HUMAN",
      "name": "Commissioning editor",
      "role": "OPERATOR"
    }
  ],
  "used": [
    { "node_id": "cu_book_a_ch3", "node_type": "CONTENT_UNIT", "role": "PRIMARY" },
    { "node_id": "cu_book_b_ch7", "node_type": "CONTENT_UNIT" },
    { "node_id": "cu_book_c_ch2", "node_type": "CONTENT_UNIT" }
  ],
  "generated": [
    { "node_id": "wk_data_eng_collection", "node_type": "WORK" },
    { "node_id": "res_data_eng_collection", "node_type": "RESOURCE" }
  ],
  "creates_tier": "WORK",
  "work_relationship": "NEW_WORK",
  "derivation_type": "COMPILATION",
  "royalty_flow": "NET_SHARE",
  "parameters": { "source_works": 3 }
}

{
  "activity_id": "act_adapt_k8s_review",
  "type": "ADAPTATION",
  "subtype": "REVIEW",
  "created_at": "2026-07-06T00:00:00Z",
  "performed_by": [
    { "agent_id": "agt_packt", "kind": "ORGANISATION", "name": "Packt Publishing Limited", "role": "AUTHOR" }
  ],
  "used": [
    { "node_id": "res_thirdparty_k8s_book", "node_type": "RESOURCE", "version": "ver_0197eee", "role": "SUPPORTING" }
  ],
  "generated": [
    { "node_id": "wk_k8s_book_review", "node_type": "WORK" },
    { "node_id": "res_k8s_book_review", "node_type": "RESOURCE" }
  ],
  "creates_tier": "WORK",
  "work_relationship": "NEW_WORK",
  "fidelity": "TRANSFORMED",
  "derivation_type": "ADAPTATION",
  "royalty_flow": "EXCLUDED",
  "rights_basis": {
    "basis_type": "STATUTORY_EXCEPTION",
    "statutory_exception": {
      "type": "FAIR_DEALING_CRITICISM_REVIEW",
      "jurisdictions": ["GB"],
      "source_made_public": true,
      "justification": "Critical review; three quoted excerpts totalling 412 of 78,500 source words, each accompanied by commentary.",
      "asserted_by": {
        "agent_id": "agt_rights_ops",
        "kind": "ORGANISATION",
        "name": "Packt Rights Operations",
        "role": "OPERATOR"
      }
    }
  }
}

Reading and querying the log

The log is available to every platform user, scoped to their own tenant. It is the tool you reach for when you need to answer an audit question about content — and because every entry is append-only and immutable, an answer today and the same answer years from now are identical.

You read the log by filtering it. The filters map directly onto the audit questions:

• By content — everything that touched a given Resource, Work, or other node, to answer "what happened to this?"
• By agent — everything a given person, organisation, or system did, to answer "who did this, and what else did they do?"
• By activity type — all translations, all AI enrichments, all editions, to answer "where has this kind of thing happened?"
• By AI tooling — everything an AI model produced or touched, filtering on the model recorded in tooling, to answer "what did AI do, and under what contract?"
• By time window — everything in a date range, to bound an audit to a period.

GET /v0/content-lake/activities?tool_model=*&from=2026-01-01T00:00:00Z HTTP/1.1
Host: api.packtpub.services
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6...

Related pages

• Provenance & attribution — the lineage half of the story: how content nodes derive from one another, and how "what is this derived from?" and "who is owed?" become graph walks.
• Access, labels & visibility — who can see and do what within a tenant, and how visibility is controlled.
• Enrichment & the Knowledge Graph — the three log-only enrichment activities, and how content gains context.
• Works & rights — where rights live, and how rights_basis pins the contract that authorises each Activity.
• Explorer — Chapter VIII — provenance and derivation, visualised.