The AI System Had Logs. Nobody Could Find the Approval.

A marketing agency published a client video with visual artifacts that its own review had missed. The technology provider had the generation logs, the model version, the input parameters and the timestamps. The agency could not say who had approved the final output, or when.

That is the incident Runbo Li, co-founder and CEO of Magic Hour AI, describes in a written reply to PSEEDR. His company supplied the video-generation system and the infrastructure. The agency supplied the brand guidelines, the client relationship and the review process. Each organization controlled an important part of the work. Neither held a complete account of how the video moved from generation to publication.

Li places the gap on the human review side rather than the AI side. In his account, Magic Hour responded by exposing more metadata per generation, which he describes as confidence signals and render quality flags. The agency added a simple sign-off log recording which team member approved each asset before it went to the client. Every generation on his side now carries a model version, parameters, an output hash and a timestamp, he says, and the agency mirrors that with its own approval record. He also names the limit. Smaller teams skip the sign-off step when they are moving fast, and when they skip it the gap returns.

A defect in the generated video and a missed review can both contribute to the same failure. Li's account does not establish how much responsibility belongs to each organization. To decide what to fix, the teams need to identify the generated file, the file a person reviewed and the file that reached the client. That connection can disappear even when each organization keeps detailed records of its own work. The business problem begins where those records stop connecting.

Approval belongs to a particular version

A generation log can establish what the system produced. An approval record can establish what a person agreed to release. Those two statements refer to the same work only if both records identify the same output.

Consider a hypothetical agency workflow. A producer approves the first cut of a video. Someone then changes the voiceover, regenerates one scene and publishes the revised cut. A log that says the campaign was approved does not establish approval of the revised video. In the other direction, an incident involving the published revision does not establish that the producer approved its defect. Both conclusions need a connection to the actual versions involved.

The W3C PROV primer separates the things involved in a process from the activities that use or produce them and from the agents responsible for those activities. It also treats each revision as a new thing that can be related to the one it replaced. Applied to an agency's work, the video file, the generation, the edit and the approval are distinct parts of the history. Treating them as one campaign status loses information that an incident may need.

For a small agency, this can be a practical naming problem rather than a standards project. The sign-off needs to identify the particular file the reviewer saw. A version identifier or durable asset reference supplies that link; a message saying the campaign looks good may not. Li's reported output hash, a value calculated from a file's contents, can help identify that file on the provider's side. The approval record must still refer to it. A hash alone says nothing about who reviewed the asset.

Li's example also changes how a business should read a provider's quality signals. Flags and metadata can help the customer make a review decision. They cannot record a decision the customer never made, and they cannot show that the reviewer saw the version later published. Better generation telemetry and better approval records address different missing facts.

The permissions that matter are the ones in force then

Kruno Sulić, founder and SaaS product builder at Cliprise, describes a recurring pattern in AI and API-driven workflows. An action fails after a customer administrator changes workspace roles. The provider can identify the request ID, timestamp, status code, billing event and the exact service account or API key used. The customer can explain the role change and what the administrator expected to remain possible.

What is often missing, he says, is a clean shared record tying the permission change to the later failed action in a form a non-technical reviewer can follow. Support staff or the product owner assemble the explanation by hand from application logs, audit events, support messages and the administrator's account of who approved what. That works, but it is slow and fragile. Logs kept in different systems with different retention windows make the reconstruction harder, and the chain stays incomplete if either side logs weakly.

The reconstruction requires both the permission history and the customer's instruction. Today's account settings may differ from the settings when the request ran, so inspecting the current account cannot settle whether the action was allowed then. Technical permission also differs from business approval. An account may be able to send messages while its owner has authorized only a draft. Connecting the task, the approval and the permissions in force at execution separates an access problem from an action the customer never wanted.

The same gap appears in much simpler systems. Victor Smushkevich, founder of Tested Media, describes marketing automations that run inside the business owner's accounts while their logs live in the provider's tool. When a follow-up text hits the wrong list or an email sequence fires twice, he says, the missing record is usually the approval of the trigger. The yes happened on a call or in a chat thread, apart from the workflow history. Permissions at the time of the change are gone too, because access gets adjusted over months. The owner reconstructs events from old texts and emails, and the provider fills the rest from memory.

His remedy is a one-page change log in a shared folder the owner controls. Each new automation or edit gets a line describing what it does, the accounts it touches, who approved it and the date. Workflow logs are exported monthly into the same folder so they outlive the provider's access.

The simplicity is the point, and it has a stated limit. "The line has to be written before the change ships, and nothing enforces that except habit," Smushkevich writes. His log records that a step was approved to run. It cannot explain why an AI step produced a particular output.

A one-page record and a technical trace answer different questions

The choice is not between a spreadsheet and sophisticated observability. The two record different facts. The sheet can say who agreed to change a trigger and what the change was meant to do. A trace can show the services a request passed through and the result of each step. Neither record substitutes for the other. Connecting them lets an investigator compare the authorized change with the operation that actually ran.

OpenTelemetry's context-propagation documentation explains how a trace identifier and a span identifier travel with a request from one service to the next, so that the receiving service's work is recorded as part of the same trace. The SDKs can inject the same identifiers into log records. That gives an investigator a way to follow one request through several systems instead of searching unrelated dashboards for events that happened at roughly the same time.

For an AI workflow, the corresponding task is to connect the request to the model call, any tool action and the result. A shared identifier works like a reference number carried through those steps: it helps the investigator find records belonging to the same operation. It does not create those records. The output version, permission decision and human approval still need to be captured, and a phone conversation remains missing if nobody recorded the decision.

The distinction matters when buying an AI service. A provider may demonstrate a trace of model calls and tool execution. A customer may demonstrate an approval workflow. The question is whether a specific approval can be retrieved from the action it authorized, and whether the approval names the same version or change. Two attractive dashboards do not establish that relationship.

Smushkevich's owner-controlled folder also addresses access, which can disappear when the commercial relationship changes. His monthly export is his practice, not a safe interval for every system. If a required source log expires sooner than a month, the next scheduled export arrives too late. The export rhythm has to fit the shortest-lived record being preserved and how long a problem can take to surface.

An intact record can still leave the decisive fact missing

Sudhanshu Dubey, delivery manager and enterprise solutions architect at Errna, argues for what he calls a split-custody model: the provider keeps operational telemetry and the customer keeps a record of the decision logic. He reports a multi-party middleware deployment in which the provider logged raw system execution while the customer recorded input-output pairs. When a critical failure occurred, the provider's logs showed a healthy system responding within latency targets. The customer's records showed a logical error that should not have been possible under the agreed model parameters.

The missing fact, in Dubey's account, was which model version and state had served that request. Neither record held it: the provider's logs showed that the system ran, and the customer's pairs showed what came back. The provider had to reconstruct it from internal snapshots, which delayed the incident response by several days, he says.

The provider now signs the inference metadata and sends a hash of that state to the customer alongside the response, Dubey writes. The receipt is meant to give the customer a reference to the request-time state, the fact that had been missing. He recommends anchoring a chosen subset of critical features rather than trying to capture everything. His reply does not establish what the implemented receipt contains, how the state hash is authenticated or checked, or that the referenced state is retained for inspection, and PSEEDR has not inspected the implementation. A receipt of that kind can help both parties check recorded information later. That does not mean it holds every fact needed to explain an incident.

AWS's description of CloudTrail log-file integrity validation offers a concrete example of what a signed record does and does not do. CloudTrail creates a hash for each delivered log file and an hourly signed digest file that references those hashes, so a user can later check whether delivered files were modified or deleted. AWS also separates enabling the delivery of digest files from actually validating them. Turning the feature on does not perform the check.

Integrity checking concerns what happened to recorded data after it was written. It does not establish that an application captured a missing approval, that a business rule was appropriate or that a model's output was correct. A valid receipt for one version cannot settle an incident concerning a different version whose connection to it was never recorded.

That distinction is easy to lose when a vendor offers an audit trail as a single feature. Before relying on it, a customer needs to know which events enter the trail and which facts each event preserves. A valid signature can help establish that a generation record was not altered; it cannot fill an approval field that was never written. A signed but incomplete history remains incomplete. The practical question is whether the missing fact can be retrieved, not whether the dashboard uses the word immutable.

Connecting histories should not mean pushing sensitive information through every service. OpenTelemetry's baggage guidance warns that propagated key-value data travels in request headers, can reach unintended downstream systems including third-party APIs, and has no built-in integrity check, so a receiving service cannot assume the values are its own. The related propagation guidance says not to put credentials, API keys or personal data in baggage. A tracing field is not a substitute for authorization, and it is the wrong place for confidential customer material. Controlled references to protected records can establish connections without making every participant a custodian of the full payload.

Evidence has to survive the handoff

Dora Bloom, chief revenue officer at iotum, sees the custody problem from the platform side of white-label communications. A provider sells the service under its own brand and holds the permissions and approvals. The platform holds the application logs. The notes on what the customer actually reported sit with whoever took the call. The contract names the provider as the single face of the service and rarely names anyone as keeper of the record.

"Owning the relationship is not the same as owning the evidence," she writes. Rather than describe a single named deployment, she recommends a short schedule agreed before go-live: the system of record for each kind of log, retention set in days, and a named owner on each side who can produce the record on request. She also states the limit. A schedule tells you where to look. It cannot create logs the software was never built to write, and adding them afterwards is slow.

Retention has to cover the records needed together. Suppose an approval remains available after the referenced output has been deleted. The team may know who signed off but be unable to inspect what they saw. If the output survives but its sign-off has expired, the team faces the opposite problem. When reconstruction requires both, it remains possible only as long as both records, or retained copies with the same connection, can be retrieved.

The contributors do not agree on where the evidence should live by default. Evgeny Leonov, chief technology officer at Ronas IT, wants the operational evidence in the customer's own account so a failure can be inspected without the provider's dashboard. Dubey keeps telemetry with the provider and a signed receipt with the customer. Bloom recommends assigning a system of record per log type. These are different custody arrangements, and none of the replies offers evidence that one works better than the others. Each identifies a way to preserve or retrieve part of the history. Whether the action can actually be connected to its authorization remains a separate question; custody alone does not establish that the connection was recorded.

Ownership and retrieval also differ. A customer may own the cloud account while the person handling the incident lacks permission to open a particular log. A provider may retain the log without having named anyone to export it. The handoff needs to specify who can retrieve each record, through which access route and with which matching identifier. This can be arranged without giving every participant access to every customer record.

Leonov's own deployments illustrate the difference between owning a system and owning the record of an action. His projects start in the client's cloud account. Infrastructure is provisioned from Terraform modules, the pipeline produces a plan for human review before anyone applies it, and application builds update image tags in a separate deployment repository with protected environment branches. Because the client owns the account and the code, another team can inspect the approved changes and take over without moving the infrastructure.

He separates that history from the record of an individual AI action. The plan and the image tag would show what was shipped. They would not show the request that triggered an action or the permissions a tool had when it ran. "Without an action log, neither side can reconstruct that particular decision from a deployment diff," he writes. The installed software is one part of the explanation. The request, the tool's permission at execution time and the outcome are another.

Test a single action before a real incident

Leonov proposes making the evidence handoff part of release acceptance. The customer and provider would trace one synthetic action from the request through authorization, a tool call, approval and an incident ticket, each using its own account. The exercise would show which permissions or logs are missing while the teams can still fix the setup. This is his proposal. No such drill was performed for this article, and his reply does not describe one that has been run.

Its value is that it turns an abstract promise of transparency into a specific retrieval task. Can the customer find the relevant approval? Can the provider identify the execution and the output? Do their references match? Can the incident owner connect them without reconstructing the arrangement from memory?

For a small agency, the exercise might use a deliberately unpublished test asset and the same approval record used for client work. For a tool-using business application, it would need to include the permission and the result relevant to that tool. These are possible applications, not a requirement to build a second production system. The scope should match the action the business would actually need to explain.

The exercise also makes omissions visible without pretending to solve AI interpretability. A complete record of inputs, tools, outputs and approvals may show that an agent acted outside a permitted task, that an integration sent the wrong version, or that a reviewer approved a defective output. It does not necessarily reveal why a model generated a particular phrase or chose a particular intermediate step. Leonov makes the same point about his own proposal: a complete trace does not establish whether the model's reasoning was sound. Those are different questions with different evidence requirements.

For the agency in Li's account, the practical endpoint is an identified output and an identifiable decision to release it. If the generated file was defective, the record directs attention to generation and review. If a different file was approved than the one published, the delivery process needs examination as well. The history should let those possibilities be told apart rather than force each side to argue from the part it happens to control.

The practical test is whether someone who was not on the original call can reconstruct the action after a colleague leaves or a provider login is revoked. They need the relevant version, the authority under which the action ran and the decision that sent its output onward. Adding logs helps when it supplies one of those missing facts or connects records that previously stood apart. It helps little if the decisive approval still exists only in somebody's memory.

Reporting note: The six contributors supplied written accounts to PSEEDR. Reported incidents, delays and implementations were not independently verified. Recurring patterns and recommendations are identified as such; no evidence-handoff drill was performed for this article. The examples applying documentation to agency workflows are PSEEDR analysis. The records discussed can help reconstruct an action, but do not by themselves establish legal responsibility or explain a model's internal reasoning.