{"slug": "you-recorded-every-event-can-you-still-reconstruct-the-execution", "title": "You Recorded Every Event. Can You Still Reconstruct the Execution?", "summary": "A developer working on AI monetization infrastructure argues that recording every runtime event in a distributed AI workflow is insufficient to reconstruct an execution, because the relationships between events — retries, parallel branches, fallbacks, and asynchronous continuations — are lost even when individual events are preserved. The engineer contends that request_id and HTTP request/response boundaries break down once work outlives the original request, and calls for preserving identity and lineage rather than events alone.", "body_md": "Imagine that, months after an AI workflow ran, you want to reconstruct exactly what happened.\n\nThe customer asked for a research report. The report was eventually delivered, and your system recorded every relevant runtime event along the way.\n\nNothing is obviously missing.\n\nYou have events for planning, search, tool calls, model calls, validation and the final successful result. Each record has a timestamp. The provider calls are there. The failures are there too.\n\nYour data might look something like this:\n\n```\n10:00:01  request accepted\n10:00:03  planning started\n10:00:07  search\n10:00:08  search\n10:00:12  tool call\n10:00:15  tool call failed\n10:00:18  tool call\n10:00:26  model call\n10:00:31  validation failed\n10:00:37  model call\n10:00:44  validation succeeded\n10:00:45  report delivered\n```\n\nAt first glance, this looks like a pretty good execution history.\n\nBut try answering a few questions from it.\n\nWas the second tool call a retry of the failed one, or a different operation? Did the two searches run sequentially or as parallel branches? Was the second model call a retry, a fallback, or a new stage of the workflow? And if some of this work continued asynchronously, did it still belong to the execution initiated by the original request?\n\nThe individual events may all be accurate.\n\nThe structure that connected them may already be gone.\n\nThat's the part I've been thinking about while working on AI monetization infrastructure. It's tempting to treat reconstruction as an aggregation problem: preserve the events now, group them later, and the execution history will still be there when you need it.\n\nI'm becoming less convinced that this is enough.\n\nA distributed workflow is not only a collection of things that happened. It also contains relationships: one operation spawned another, two operations ran as siblings, an attempt retried an earlier attempt, a worker continued work after the original request ended, or several branches eventually contributed to the same result.\n\nIf those relationships disappear, having every event does not necessarily give us the execution back.\n\n**We didn't lose the events. We lost the relationships between them.**\n\nThat suggests a different engineering question.\n\nNot only:\n\nWhat events should an AI runtime preserve?\n\nBut:\n\nWhat identity and lineage must survive if we want to reconstruct how those events belonged together?\n\nHTTP gives us a very convenient mental model:\n\n```\nrequest\n   ↓\n  work\n   ↓\nresponse\n```\n\nFor simple synchronous operations, that model can also provide a useful boundary for observability. A request arrives, the application performs some work, returns a response, and much of what we care about happens within that lifetime.\n\nDistributed AI workflows can break that assumption very quickly.\n\nSuppose generating the research report takes long enough that we don't want the client to keep an HTTP connection open. The API accepts the request, creates some work and returns `202 Accepted`.\n\n```\nHTTP request\n     ↓\n  accepted\n     ↓\n  enqueue job\n     ↓\n202 Accepted\n     X\n     │\n     │ execution continues\n     ↓\n   worker\n     ↓\n  planning\n     ↓\n   fan-out\n  /   |   \\\n /    |    \\\n```\n\nsearch search tool\n\n   A      B     C\n\n                ↓\n\n             retry\n\n         \\      |      /\n\n          \\     |     /\n\n           aggregation\n\n                ↓\n\n           validation\n\n                ↓\n\n             outcome\n\nThe request may have lived for a few hundred milliseconds.\n\nThe work it initiated may live for minutes.\n\nThat difference matters because a `request_id` can still correctly identify the interaction that entered the system without necessarily being the right identity for everything that happens afterward.\n\nThe queue message may be delivered later. A worker may create several child jobs. One branch may retry independently. Another may call an external service and wait for a callback. The workflow may pause and resume after the original process that handled the HTTP request no longer exists.\n\nWe can propagate the original request context through those boundaries, and doing so is extremely useful. Distributed tracing is specifically designed to carry context across services and process boundaries so related operations can remain observable as part of a distributed flow.\n\nBut propagation does not make the original request and the resulting domain execution the same concept.\n\nConsider:\n\n```\nreq_123\n   ↓\nexecution_123\n   │\n   ├── search_job_A\n   ├── search_job_B\n   └── tool_job_C\n           ↓\n         FAILED\n           ↓\n         retry\n```\n\nThe request tells us where this interaction entered the system.\n\nWhat we're trying to reconstruct later is something slightly different: the logical work that continued because of it.\n\nThat distinction becomes more important when work can resume without a new customer request, when one request initiates multiple independent executions, or when a later callback continues an execution that started somewhere else.\n\nSo I don't think the useful conclusion is simply:\n\nReplace request IDs with execution IDs.\n\nWe still want request identity. It answers a real operational question.\n\nThe problem is assuming that one identifier can represent every kind of identity we care about.\n\nA request belongs to the transport interaction. An execution may need to survive beyond that interaction.\n\nAnd once an execution can survive its request, another problem appears almost immediately.\n\nWhat happens when the same logical work is attempted more than once?\n\nRetries make the identity problem harder because one piece of logical work can produce multiple physical attempts.\n\nSuppose one branch of our research workflow calls an external tool:\n\n```\nexecution_123\n     ↓\n  tool_call\n     ↓\n attempt_01\n     ↓\n  provider\n     ↓\n   timeout\n```\n\nFrom our side, the call timed out. We don't know whether the provider rejected it, started processing it, completed it but failed to return the response, or consumed resources before something else went wrong.\n\nSo we retry:\n\n```\nexecution_123\n     ↓\n  tool_call\n     │\n     ├── attempt_01\n     │       ↓\n     │    timeout\n     │\n     └── attempt_02\n             ↓\n          success\n```\n\nFrom the workflow's perspective, this may still be one logical operation: call the tool and obtain a result.\n\nFrom the runtime's perspective, two attempts happened.\n\nThat difference matters because several questions that look similar are actually independent.\n\nDid the retry produce duplicated application state? An idempotency mechanism may help us prevent or detect that.\n\nDid the provider execute the first attempt despite our timeout? That depends on evidence we may or may not have.\n\nDid both attempts consume billable resources? That's another question.\n\nAnd if both consumed resources, should both eventually be associated with the execution that produced the customer outcome? That's an attribution question we haven't answered yet.\n\nIdempotency is particularly easy to overextend conceptually. An idempotency key can help a system recognize repeated processing of the same logical operation and avoid applying the same effect more than intended.\n\nBut that does not mean only one physical attempt occurred.\n\n**A retry can be safe from the perspective of application state while still representing additional runtime work.**\n\nFor reconstruction, preserving only the final logical state can therefore hide something important:\n\n```\nlogical operation\n       ↓\n    SUCCESS\n```\n\nCompare that with:\n\n```\nlogical operation\n       │\n       ├── attempt_01\n       │      ↓\n       │   timeout\n       │\n       └── attempt_02\n              ↓\n           SUCCESS\n```\n\nBoth representations may describe the same final application state.\n\nThey do not preserve the same execution history.\n\nThis is why I find it useful to distinguish, at least conceptually, between an **execution identity** and an **attempt identity**.\n\nThe execution identifies the logical work we're trying to follow. The attempt distinguishes a particular try at performing some part of that work.\n\nI don't think every system needs those exact names or separate persisted identifiers for every operation. The useful distinction is semantic, not terminological.\n\nIf multiple attempts can happen and those attempts matter to questions we may ask later, the runtime needs some way to preserve that relationship.\n\nOtherwise:\n\n```\ntool_call   timeout\ntool_call   success\n```\n\nleaves us trying to infer whether we observed a retry, two independent operations, or something else entirely.\n\nAnd retries are still the easy shape.\n\nOnce one execution starts creating several pieces of work in parallel, a flat sequence of individually accurate events becomes even less representative of what actually happened.\n\nFan-out makes the problem more obvious.\n\nOur research workflow might reach a planning stage and perform several operations in parallel:\n\n```\nexecution_123\n       ↓\n    planning\n       ↓\n    fan-out\n  /    |     \\\n /     |      \\\n```\n\nsearch_A search_B tool_C\n\n     \\     |      /\n\n      \\    |     /\n\n       aggregation\n\n           ↓\n\n       validation\n\n           ↓\n\n        outcome\n\nEach branch can produce perfectly accurate events.\n\nStored individually, the data could look something like this:\n\n```\n10:00:07  search     success\n10:00:08  search     success\n10:00:09  tool_call  started\n10:00:15  tool_call  failed\n10:00:18  tool_call  started\n10:00:24  tool_call  success\n10:00:26  model_call success\n10:00:31  validation failed\n10:00:37  model_call success\n10:00:44  validation success\n```\n\nThere is nothing necessarily wrong with those records. They may be exactly what happened.\n\nBut a flat list does not necessarily preserve why those events exist in relation to one another.\n\nWas the tool call at `10:00:18` a retry of the failed call, or another branch? Did both searches belong to the same fan-out? Did the model call at `10:00:37` retry the earlier model call, replace it through a fallback path, or execute because validation created a new stage of work?\n\nTimestamps can help us infer some of this. Operation names, logs, traces and application metadata may provide additional clues.\n\nBut inference from proximity is different from preserving the relationship itself.\n\nThe same set of events can represent different execution structures:\n\n```\nA\nB\nC\nD\nE\n```\n\ncould have happened as:\n\n```\nA\n↓\nB\n↓\nC\n↓\nD\n↓\nE\n```\n\nor:\n\n```\nA\n├── B\n│   └── D\n└── C\n    └── E\n```\n\nor even:\n\n```\nA\n↓\nB\n↓\nC FAILED\n↓\nC RETRY\n↓\nE\n```\n\nIt is tempting to treat relationships such as parent/child, retry-of or belongs-to-execution as metadata around the real evidence.\n\nBut for reconstruction, those relationships may themselves be part of the evidence.\n\n**A list can tell us what exists. A lineage graph can preserve how those things belonged together.**\n\nThat does not mean every runtime needs to persist an elaborate execution graph. It means that if we expect to answer structural questions later, the structure cannot always be recovered from flat measurements alone.\n\nThe design question therefore isn't simply how many events we retain.\n\nIt's which relationships would become impossible — or dangerously ambiguous — to recover if we didn't preserve them when the execution happened.\n\nAnd this is where the problem starts to overlap with distributed tracing.\n\nA trace already preserves relationships between operations across a distributed system.\n\nSo if we have tracing, do we actually need another notion of execution lineage at all?\n\nAt this point, there is an obvious objection.\n\nA distributed trace already exists to connect work across services. If a request moves from an API to a worker, then to a model provider and an external tool, trace context can be propagated across those boundaries so that related operations remain observable as part of a distributed flow.\n\nThat's exactly what tracing is good at, and I don't think it makes sense to invent a parallel model for information that tracing already preserves well.\n\nA simplified trace might give us something like:\n\n```\ntrace\n│\n├── API request\n│\n└── enqueue job\n    │\n    └── worker\n        │\n        ├── search\n        ├── model call\n        └── tool call\n```\n\nThat is already much richer than a flat list of events.\n\nWe can inspect timing and reconstruct important technical relationships between operations. With correctly propagated context, those relationships can survive process and service boundaries too.\n\nBut there is a subtle distinction between reconstructing technical relationships and identifying the logical unit of work our domain cares about.\n\nConsider a workflow that pauses after the initial trace and resumes later because an external system sends a callback:\n\n```\ntrace_01\n   │\n   ├── request\n   ├── planning\n   └── external tool request\n\n            time passes\n\ntrace_02\n   │\n   ├── callback received\n   ├── workflow resumed\n   ├── validation\n   └── outcome\n```\n\nDepending on how the system is instrumented, representing those activities as separate traces may be completely reasonable.\n\nFrom the perspective of our domain, however, they may still be two parts of the same logical execution.\n\nThe opposite shape is possible too. One technical operation may process a batch containing work associated with several logical executions.\n\nFan-out, messaging and asynchronous processing can create relationships that are not always represented cleanly by assuming one trace is equivalent to one domain execution.\n\nOpenTelemetry accounts for some non-tree relationships through span links. A span can link to other span contexts without making them its parent, which is useful in cases such as asynchronous processing, batching and scatter/gather patterns.\n\nThat reinforces the point rather than weakening it: distributed execution does not always fit into one simple request-shaped hierarchy.\n\nSo I would be careful with an assumption like:\n\n```\ntrace_id = execution_id\n```\n\nSometimes that mapping may be useful.\n\nIt is not a semantic guarantee we get from tracing itself.\n\nA trace answers an observability question about technical operations and their relationships. The application may still have a domain question about which logical execution those operations participated in.\n\nAnd neither one automatically answers the economic question.\n\nSuppose our trace shows that a failed tool call was followed by a retry and that both occurred before the final report was delivered.\n\nWe have learned something important about the technical execution.\n\nWe still haven't decided whether the cost of both attempts should be attributed to that report, whether some of the work was shared with another outcome, or which economic boundary the business wants to analyze.\n\nThat leaves us with three related but different models:\n\n```\nTECHNICAL CAUSALITY\nWhat happened across the distributed system?\n            ↓\nDOMAIN IDENTITY / LINEAGE\nWhat logical work belonged together?\n            ↓\nECONOMIC ATTRIBUTION\nWhich economic unit should bear that work?\n```\n\nInformation can flow between these layers. Technical traces can provide strong evidence for reconstructing domain lineage, and domain lineage can provide evidence for later economic analysis.\n\nBut one layer does not automatically define the semantics of the next.\n\nThe lesson isn't that tracing is insufficient.\n\nThe more useful question is whether the semantics already captured by our tracing system are the same semantics we'll need when we reconstruct the execution later.\n\nIf they aren't, adding more telemetry isn't necessarily the answer.\n\nWe first need to decide which identities and relationships are worth making durable.\n\nOnce we accept that reconstruction depends on relationships as well as events, it's easy to move too far in the other direction.\n\nWe could attach an identifier to everything, persist every transition and build a detailed graph of the entire runtime.\n\nThat would preserve information. It doesn't mean all of that information would be useful.\n\nA better starting point, I think, is not:\n\nWhat fields might we want someday?\n\nWhat questions would become impossible to answer if this relationship disappeared?\n\nSuppose we want to know whether two provider calls were independent operations or two attempts at the same logical work.\n\nThen we need enough information to distinguish the operation from its attempts:\n\n```\nexecution_123\n     │\n     └── tool_operation\n             │\n             ├── attempt_01 → timeout\n             └── attempt_02 → success\n```\n\nThe exact representation is less important than preserving the fact that `attempt_02` exists in relation to `attempt_01`, rather than merely happening a few seconds later.\n\nIf we want to know whether several operations were created by the same execution, some notion of execution identity and parent/child relationship becomes useful:\n\n```\nexecution_123\n     │\n     ├── search_A\n     ├── search_B\n     └── tool_C\n```\n\nAnd if the domain eventually produces a meaningful result that we care about independently from the execution itself, an outcome reference may be useful too:\n\n```\nexecution_123\n     │\n     ├── attempts\n     ├── child executions\n     └── runtime operations\n              │\n              ↓\n         outcome_789\n```\n\nBut `outcome_id` is a good example of why I wouldn't turn this into a universal schema.\n\nNot every execution produces one identifiable outcome. One execution might produce several results. Several executions might contribute to one result. Some workflows may fail without producing an outcome at all.\n\nThe identity model has to reflect the questions the domain actually needs to answer.\n\nA minimal conceptual event might therefore look something like this:\n\n```\n{\n  \"event_id\": \"evt_42\",\n  \"execution_id\": \"exec_123\",\n  \"attempt_id\": \"attempt_02\",\n  \"operation\": \"tool_call\",\n  \"occurred_at\": \"2026-09-16T08:42:17Z\",\n  \"status\": \"failed\"\n}\n```\n\nThis is not a schema recommendation. A real implementation might represent these relationships very differently.\n\nWhat matters is what each piece of information buys us.\n\n`event_id` gives the event a stable identity. `execution_id` gives us a logical context in which to interpret it. `attempt_id` prevents repeated physical work from collapsing into one final logical state. `occurred_at` tells us when the event happened rather than relying only on when we happened to receive or persist it.\n\nThe useful design principle is not to maximize metadata.\n\nIt's to preserve the smallest set of identities and relationships that keeps the questions we care about answerable.\n\nAnd in a distributed system, even preserving that structure doesn't mean the evidence will arrive neatly.\n\nImagine two branches running in parallel:\n\n```\nexecution_123\n     │\n     ├── search_A\n     │      ↓\n     │   completed at 10:00:12\n     │\n     └── tool_B\n            ↓\n         completed at 10:00:10\n```\n\nIf the search event reaches our evidence store immediately while the tool event is delayed by a queue or network boundary, we might persist them in the opposite order:\n\n```\nreceived 10:00:12 → search_A completed\nreceived 10:00:15 → tool_B completed\n```\n\nNothing is necessarily wrong.\n\nThe order in which we learned about the events is simply different from the order in which they occurred.\n\nRetries and duplicated delivery complicate this further. The same event may be delivered more than once, while evidence about an earlier attempt may arrive after evidence about the retry that followed it.\n\nReconstruction therefore shouldn't assume that ingestion order is execution order.\n\nAt minimum, it helps to preserve a stable identity for an event and distinguish when the event occurred from when the system received or persisted it:\n\n```\nevent occurred\n      ↓\n  10:00:10\n\n      │\n      │ network / queue delay\n      ↓\n\nevent recorded\n      ↓\n  10:00:15\n```\n\nThose timestamps answer different questions.\n\nThis isn't an argument for storing every possible timestamp or building a full event-sourcing architecture.\n\nThe narrower point is that lineage should not depend entirely on arrival order. If an attempt is explicitly related to the operation it retried, or a child execution preserves its relationship to a parent, that structure can remain meaningful even when the evidence arrives late or out of order.\n\nOtherwise, reconstruction can quietly become an exercise in guessing relationships from timestamps.\n\nAnd that difference becomes much more important when the question we're asking is no longer only operational.\n\nIt becomes economic.\n\nSo far, none of this requires an economic use case.\n\nExecution identity, retries, causal relationships and distributed tracing are established backend concerns. AI didn't invent them.\n\nThe economic relevance appears when different execution paths can consume different resources.\n\nSuppose the cost associated with our research workflow increases between two periods:\n\n```\nAugust\nResearch workflow\n1,000 completed outcomes\nprovider spend: $200\n\nSeptember\nResearch workflow\n1,000 completed outcomes\nprovider spend: $310\n```\n\nWe know more was spent.\n\nBut that doesn't tell us what changed inside the execution.\n\nMaybe the workflow started retrying an external tool more often. Maybe a validation failure caused additional model calls. Maybe one branch began falling back to a more expensive model. Maybe the execution path didn't change at all and the applicable provider rate changed instead.\n\nThose are different explanations.\n\nSome require historical pricing context. Others require historical execution context.\n\nI explored the first problem in [**Your AI Cost Calculation Can Be Correct — and Still Be Historically Wrong**](https://dev.to/thelastciroandrea/your-ai-cost-calculation-can-be-correct-and-still-be-historically-wrong-4eof). Here I'm interested in the second: whether enough of the execution structure survived to explain what changed.\n\nIf the question is whether retries increased, knowing that ten thousand provider calls occurred is useful but not sufficient. We also need some way to distinguish independent operations from repeated attempts at the same logical work.\n\nIf the question is whether a fallback path became more common, we need to know which operations belonged to that path. If one child execution started consuming more resources, we need to be able to identify that child execution across the evidence we preserved.\n\nThe economic question therefore exposes something about the earlier architecture.\n\n**A system may have retained enough data to calculate total spend while retaining too little structure to explain how that spend emerged from runtime behavior.**\n\nConceptually:\n\n```\nPROVIDER EVENTS\n       ↓\n   aggregate\n       ↓\n  total spend\n```\n\ncan answer a different class of questions from:\n\n```\nexecution_123\n     │\n     ├── attempt_01\n     │      └── tool call\n     │\n     ├── attempt_02\n     │      └── tool call\n     │\n     └── child execution\n            └── model call\n\n       ↓\n\nreconstruct runtime behavior\n```\n\nThe first view is useful.\n\nThe second preserves a different kind of information.\n\nThis connects to a broader problem we've been exploring in the Licenzy Guide [**One AI Outcome. Many Runtime Operations. What Actually Belongs to Its Cost?**](https://licenzy.app/guides/one-ai-outcome-many-runtime-operations-cost).\n\nThat Guide asks which runtime work should be considered when reasoning about the economics of an outcome.\n\nThe engineering question I'm interested in here comes one step earlier:\n\n**Did the runtime preserve enough identity and lineage to reconstruct that work in the first place?**\n\nWithout meaningful lineage, a later analysis may need to infer relationships from timestamps, operation names, customer references and whatever logs happen to remain.\n\nWith meaningful lineage, more of those relationships can be investigated from structure that was preserved when the execution happened.\n\nThat still doesn't guarantee a complete or correct economic explanation. Provider evidence can be missing. Shared work can complicate the boundary. Historical rates may need to be reconstructed separately. Evidence can arrive late or be corrected.\n\nBut there is an important difference between asking the system to recover a relationship it preserved and asking an analyst to infer a relationship that disappeared.\n\nFor some economic questions, execution lineage can move us from:\n\n```\n\"These events happened around the same time.\"\n```\n\ntoward:\n\n```\n\"These events were related as part of this execution.\"\n```\n\nThat's stronger evidence.\n\nIt is still not the final answer.\n\nBecause even if we reconstruct the execution perfectly, we haven't yet decided what that execution means economically.\n\nImagine that we solved the reconstruction problem perfectly.\n\nMonths later, we can recover the execution graph:\n\n```\nexecution_123\n     │\n     ├── search_A\n     ├── search_B\n     │\n     ├── tool_call\n     │      │\n     │      ├── attempt_01 → timeout\n     │      └── attempt_02 → success\n     │\n     ├── model_call\n     ├── validation → failed\n     ├── fallback_model_call\n     └── validation → success\n                ↓\n            outcome_789\n```\n\nWe know which attempts belonged to the same logical operation. We know which child work belonged to the execution. We know the retry relationship, the fallback path and the result eventually produced.\n\nThat's a much stronger foundation for historical investigation.\n\nBut it still doesn't tell us how every piece of work should be interpreted economically.\n\nTake the failed tool attempt. Technically, it belongs to the execution. It happened because the workflow was trying to produce `outcome_789`.\n\nShould its cost therefore be attributed entirely to that outcome?\n\nMaybe.\n\nNow imagine a retrieval operation populated a cache that was reused by ten later executions. Technically, we may know exactly which execution created the cached result and which executions later consumed it.\n\nWhich one should bear the cost?\n\nOr imagine a batch operation processed work for several customer outcomes at once.\n\nThe technical relationship can be perfectly reconstructable while the economic allocation still requires a policy.\n\nThis is where I think three questions need to remain separate:\n\n```\nTRACE\nWhat technically happened?\n    ↓\nLINEAGE\nWhat work belonged together?\n    ↓\nATTRIBUTION\nWhat economic unit should bear that work?\n```\n\nEach layer can provide evidence for the next.\n\nNone automatically defines it.\n\nEconomic attribution introduces semantics that may not exist in the technical graph.\n\nOtherwise, it's easy to make a subtle leap:\n\n```\n\"We know this operation belonged to the execution.\"\n```\n\ntherefore:\n\n```\n\"We know where its cost belongs.\"\n```\n\nThose are not necessarily equivalent statements.\n\nI started this investigation with a fairly narrow question: what identity would an AI runtime need if we wanted to reconstruct an execution later?\n\nI now think identity is only part of the answer.\n\n**The events are evidence. The relationships between them can be evidence too.**\n\nThis isn't a new distributed-systems problem created by AI. What makes it especially interesting in AI monetization infrastructure is that different execution paths can also have different economic consequences.\n\nIf the structure disappears, we may still know how much was consumed while losing part of our ability to explain how that consumption emerged from the execution.\n\nPreserving lineage gives us a better foundation for that investigation.\n\nIt doesn't decide the economics for us.\n\nAnd that leaves me with the question I think comes next:\n\n**If technical lineage tells us what happened together, who decides what should count together economically?**", "url": "https://wpnews.pro/news/you-recorded-every-event-can-you-still-reconstruct-the-execution", "canonical_source": "https://dev.to/thelastciroandrea/you-recorded-every-event-can-you-still-reconstruct-the-execution-2kfk", "published_at": "2026-09-16 10:18:47+00:00", "updated_at": "2026-09-16 10:42:53.462530+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-agents", "mlops", "developer-tools"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/you-recorded-every-event-can-you-still-reconstruct-the-execution", "markdown": "https://wpnews.pro/news/you-recorded-every-event-can-you-still-reconstruct-the-execution.md", "text": "https://wpnews.pro/news/you-recorded-every-event-can-you-still-reconstruct-the-execution.txt", "jsonld": "https://wpnews.pro/news/you-recorded-every-event-can-you-still-reconstruct-the-execution.jsonld"}}