Source record: Tencent Cloud’s official Hunyuan supported-operation catalogue was updated 28 July 2026. Its international event-detail page was updated 23 July 2026; its current field table supersedes the earlier 26 May snapshot. The tracking-set guide was updated 23 July, and the current CloudAudit data-structure page was updated 28 January. All four pages were retrieved directly. Last checked 1 August 2026. Open the Hunyuan catalogue · Open event details.
FactHunyuan actions can enter CloudAudit’s event system

Tencent’s catalogue assigns CloudAudit event names to chat, translation, embedding, file, thread, model-listing, and other Hunyuan operations.

InferenceThe record improves attribution and correlation

Identity, time, source, action, and request identifiers can anchor an investigation and connect control-plane activity to another execution record.

UnknownPayload completeness is not Hunyuan-specific here

The checked pages do not guarantee which prompt, output, tool, stream, model-version, or policy fields are retained or redacted for a Hunyuan call.

Audit systems invite a dangerous compression. A row says ChatCompletions; the API request succeeded; therefore the run is accounted for. The first two statements may be documented. The conclusion is not. A control-plane event can establish that an operation crossed an administrative boundary without preserving everything needed to reproduce the model execution behind it.

The catalogue adds Hunyuan to a named control-plane vocabulary

Tencent Cloud’s official catalogue, updated 28 July 2026, lists CloudAudit-supported Hunyuan operations and their event names. The table includes ActivateService, ChatCompletions, ChatTranslations, CreateThread, FilesUploads, GetEmbedding, GetThread, GetThreadMessage, ListMessageRecord, and ListModels, among many others. source ↓

The provider-defined vocabulary is useful because it distinguishes operations that should not be collapsed into “used AI”: activation, file upload, embedding, thread creation, model listing, and chat completion are different administrative events.

Yet the catalogue is a support matrix, not a content schema. It says the operation participates in CloudAudit and names the event. It does not say that every semantic input and output of that operation appears in an audit record, or that the event contains a complete model receipt.

The generic event record is rich in administrative context

Tencent’s current event-detail documentation describes fields for requester identity, request ID, API version, source type, read/write action type, authentication and API errors, client user agent, event time, source IP address, event name and source, input parameters, response information, resources, and tags. The separate current data-structure page defines an EventId, RequestID, event name, event source, event time, source IP, and a CloudAuditEvent detail field. source ↓

That is not a thin record. It can establish the administrative actor or credential context, the temporal sequence, the source, the named API action, and failure state. An EventId gives the audit object its own identity. A RequestID gives an investigator a candidate correlation key for the API request. Error fields can separate rejected authentication from an accepted request that failed later.

The wording around content remains generic. requestParameters is described as the request’s input parameters; the response field is described as response information. Those descriptions do not provide a Hunyuan-specific inventory, completeness promise, redaction rule, or retention guarantee. It would be wrong to claim that CloudAudit omits all request and response content. It would be equally wrong to claim that the generic field names preserve a complete Hunyuan exchange.

Attribution is not reproducibility, but it is the first join

An incident reviewer often begins with questions that CloudAudit is positioned to answer: Which identity invoked the operation? From which address and client? At what time? Was the action read or write? Which event and request identifiers were assigned? Did authentication or the API report an error? These are control-plane questions, and the official schema gives them structure.

From those facts follows a narrower inference: the record can improve operator attribution and request correlation. “Improve” matters. A request ID only becomes a cross-system join if the application, gateway, or receipt store preserves the same identifier—or records an explicit mapping to its own trace ID. Similar timestamps and matching event names are clues, not a deterministic join.

A successful ChatCompletions event can therefore support the statement that a named API operation was accepted or completed under the recorded event semantics. It cannot, by itself, show that a particular visible answer came from a particular resolved checkpoint under a particular policy and tool state. The event is an anchor. The execution lineage must be attached.

The missing guarantee is not “content”; it is execution completeness

The checked documents do not establish exactly which Hunyuan prompt, output, tool, or streaming content is retained, omitted, truncated, transformed, or redacted inside the generic request and response fields. They do not establish the resolved model checkpoint or serving version, sampling configuration, system and policy version, safety decisions, tool payloads and results, completeness of streaming chunks, or transformations applied by the calling application.

Some of those facts may appear in a particular event, another Tencent product, an application trace, or production logs. The source record examined here does not guarantee them. That is the unknown boundary. It is narrower and more defensible than saying “CloudAudit contains no content,” and more operationally useful than assuming a successful event is a forensic replay.

Model aliases sharpen the problem. A request may name a model family while the serving layer resolves an exact deployment, checkpoint, or revision. Policy and safety systems may change independently. Tools can call external systems whose results alter the answer. A streaming client can drop a chunk; an application can rewrite a system message or post-process the output. None of these layers is recoverable from an event name alone.

Join the CloudAudit anchor to an application-level model receipt

The editorial judgment is to preserve two linked records with different duties. Let CloudAudit remain the provider-side control-plane anchor. At the application boundary, create a model receipt whose identifier is joined to the CloudAudit RequestID, EventId, or an explicitly mapped correlation ID. The receipt should describe the execution contract without becoming an indiscriminate copy of production content.

A useful receipt binds the resolved provider and model identity; model or endpoint version where available; application release and adapter version; generation and sampling settings; policy and safety configuration; tool-call identifiers, payload/result hashes, and lineage; input and output hashes or retained content references; streaming completion status; transformations before and after the provider call; timestamps; and the declared retention class. Field presence should be versioned so absence is distinguishable from a parser that silently lost data.

Hashes can verify retained bytes; they cannot replay bytes never kept. Exact replay requires the necessary content inside an access-controlled window. Attribution alone may justify narrower metadata.

Sensitive content should be segregated rather than treated as all-or-nothing. Identity and correlation metadata may deserve longer retention than raw prompts, outputs, uploaded files, or tool payloads. Encryption, access roles, deletion, legal basis, and incident access can differ by class. CloudAudit is neither presumed complete content storage nor dismissed as useless because it is not the whole trace.

A tracking set moves selected events; it does not change their semantics

Tencent’s tracking-set guide says CloudAudit can aggregate and deliver operation events covering the recent three months, or 90 days. For management events, a tracking set can combine filters by management-event type, resource type, and event name, then deliver logs to a selected storage destination. The current Storage structure lists COS, CLS, and CKafka storage types. source ↓

Delivery improves durability and query access. It does not enrich an event with fields the underlying record never guaranteed. Nor should “90 days” be read as a universal retention promise for every destination: the guide describes the recent-event aggregation available to the tracking set, while destination lifecycle and organizational retention remain separate controls.

What teams should prove before calling the record incident-ready

The following gates are editorial consequences of the checked record, not claims that Tencent mandates this receipt design:

  1. 01
    Prove the identifier join.

    Start with a CloudAudit Hunyuan event and deterministically locate the corresponding application receipt. Reject timestamp-only matching as the primary key.

  2. 02
    Resolve the model, not only the event.

    Record the requested and resolved model identities, provider endpoint or deployment version, adapter version, and generation settings available to the application.

  3. 03
    Version policy and tool lineage.

    Bind policy and safety configuration to tool-call identifiers, tool results or hashes, and any application transformation that changes the model-visible state.

  4. 04
    Test streaming completeness.

    Distinguish a complete response from cancellation, timeout, dropped chunk, retry, or post-processing failure. A successful control-plane event must not silently certify application delivery.

  5. 05
    Declare retention by data class.

    Separate identity and correlation metadata from sensitive content. State whether the system promises attribution, integrity verification, partial reconstruction, or exact replay—and retain only what that promise requires.

Control planeFind the Hunyuan event

Use identity, time, source, action, error state, event ID, and request ID to establish the provider-side anchor.

Application planeJoin the model receipt

Resolve model, policy, tools, transformations, hashes or retained bytes, streaming state, and application version.

Incident reviewState what can be reproduced

Separate attribution from integrity proof, reconstruction, and replay. Do not let one record silently inherit another record’s claim.

What the checked record does not establish

The four official Tencent Cloud pages do not establish Hunyuan-specific completeness for requestParameters or response information; the retention or redaction of every prompt, output, uploaded file, tool payload, or stream chunk; a resolved model checkpoint; a policy or safety-decision record; an application’s transformations; or deterministic replay. They also do not establish that these fields are always absent. This issue did not inspect a production CloudAudit event or call a Hunyuan API.

Limit

This is a source-bounded reading of official documentation checked on 1 August 2026. The international event-detail page had been updated after the supplied 26 May snapshot; this issue uses its live 23 July field table. Receipt design, content segregation, join rules, and acceptance gates are editorial engineering recommendations, not statements of Tencent policy or legal advice.

What would change this assessment

A Hunyuan-specific CloudAudit field and redaction specification; an official model-version resolution field; documented policy, tool, and streaming lineage; a retention guarantee for exact request and response content; or reproducible samples showing that a CloudAudit record alone contains every byte and configuration item required for the replay claim being made.

An event name can tell you where to begin. It cannot absolve the system from remembering what actually ran.