What is a Lifecycle Graph
A lifecycle graph is how a company answers “why did this happen?” after AI is involved — the chain of cause and effect, not a chat log.
When people ask what a lifecycle graph is, they are usually asking about causality: why did this number, field, or decision change?
Causality is the difference between “two things happened around the same time” and “this caused that.” If pipeline coverage went up in the same month AI usage went up, that is a coincidence until you can show the actual steps: what was asked, what was used, who approved it, and what the live system did.
A lifecycle graph is the company’s record of those steps. It is not a chat history. Chat history shows that someone talked to a model. A graph shows the chain from the question to the outcome, so the next person — or an auditor — can follow it.
This is an operations problem that existed before generative AI. ERP journals already needed authorisation trails. CRM already had field history. What changed is that a new kind of actor can now propose, and sometimes execute, those changes in fluent language. If the “why” lives only in a personal chat, the company has a causality gap the moment that person leaves, the vendor rotates logs, or the model version rolls.
Words you’ll hear
- Causality. Being able to say what caused what, with evidence. At work, this is “this next-step field changed because this brief ran, cited this playbook version, and this person signed this payload.”
- Correlation. Two things moving together. Not the same as cause. At work, AI usage and pipeline moving in the same quarter is a slide, not an explanation.
- Provenance. The trail of who, what, and when behind a piece of data. W3C PROV is the open standard for that idea: entities, activities, and agents, linked so you can reconstruct derivation. A lifecycle graph is that instinct applied to AI-mediated work, not a claim that you have implemented the full W3C stack.
- System of record. The official live system that holds the fact — Salesforce for an opportunity, NetSuite for a journal. The graph should point at that record, not become a second copy of it. At work, pointing is how you avoid a second CRM that nobody can delete.
- Audit trail. A log that something happened. Useful, but thin if it cannot join the question, the policy, the signer, and the change. Provider API logs are an audit trail of calls. They are not a story of the job.
- Lineage. Which sources fed which proposal. At work, “which wiki version and which CRM records were in scope when this quote was generated?”
- Retention. How long a class of node is kept. A journal that feeds the books may need years. A draft may need weeks.
- Scope. Which job’s chain you are allowed to see. At work, a go-to-market question should not surface People Ops briefs.
Keep this graph apart from two neighbours. A business knowledge graph models customers, products, and sites. Enterprise RAG retrieves documents that exist. Institutional memory is the broader goal — what the company still knows after people leave. The lifecycle graph is the decision-memory layer of that goal: the chain of AI-mediated work.
Why you should care
AI makes it easy to change company systems without leaving a story. Someone asks a model to tidy CRM notes. A field moves. Next quarter, finance or legal asks why. The person who asked has left. The “why” lived in a personal chat. The CRM only shows the new value.
That is a causality problem. You cannot manage what you cannot reconstruct.
It affects you if you:
- Sign off on numbers. Forecasts, journals, and board packs inherit whatever AI changed last month.
- Inherit someone else’s work. You need the exception, not a rumour that “we always do 18% for strategic accounts.”
- Answer auditors or regulators. They will not accept “the chatbot did it.”
- Switch vendors or models. Provider logs are the vendor’s artefact. They are not your company memory.
This is not the same as proving that a discount caused a won deal. That is a statistics question. See What is causal AI for operations. A lifecycle graph answers a more basic one: what did we actually do, and who caused it?
What changes by role
Finance. Close packs and forecasts inherit field history. If an AI-proposed journal posted, finance needs the brief, the playbook version, the named signer, and the ERP response — not a Slack screenshot. Spend also belongs on the chain: a run that stopped because a cap was hit is a causal fact, not a missing invoice. See What is AI token economics.
Legal. Exception language, customer commitments, and “who saw what” are discovery questions. A graph that points at the payload the signer saw is evidence. A chat export from a personal account is not. Legal also cares about retention and deletion: infinite chat fails a privacy review; typed retention with export and legal hold is how records programmes already work.
Operations. Handoffs fail when the next shift cannot see why a run paused. Human wait is a node, not an interruption. Incident reviews need the same chain: which connector was read-only, which write was refused, which wiki page caused the flag.
Go-to-market. Pipeline hygiene and renewal exceptions are where “the bot updated it” becomes a forecast problem. GTM needs to see the quoted fields, not a summary that says “updated pricing.” They also need scope: one team’s competitive notes should not leak into another region’s chain.
Security. The graph is a sensitive store. It should not hold full transcripts with secrets by default, other teams’ out-of-scope work, or the model’s private scratch reasoning. Access control on the graph is as important as access control on the CRM. A query surface that ignores vaults recreates the god workspace.
What belongs on the chain
Keep the links that let a non-engineer reconstruct a change:
- the job and the question
- the sources (which playbook version, which records, which files)
- the people (the model is not an answer for “who”)
- the proposed change, in the language of the live system — fields and values, not “updated pricing”
- the decision, the timestamp, and whether the live system accepted it
Point at the CRM record and the policy page. Do not copy the whole company into the graph. Copies become a second official system, and a deletion problem.
Do not keep, by default: the model’s private scratch reasoning, full transcripts with secrets, or other teams’ work that was never in scope.
Retention should follow the type of record. A journal that feeds the books may need years. A draft may need weeks. “Keep everything forever because AI” fails a privacy review. UK ICO guidance on AI and data protection still wants purpose and minimisation when the “user” is an AI.
What people get wrong
The first mistake is treating chat history as the record. Chat is a user interface. It is not a join of brief, policy, signer, and system response.
The second is retrofitting. Copying six months of ChatGPT and Slack into a warehouse is archaeology. You still need something that emits events at the moment of the brief, the quote, and the approval.
The third is a second CRM. Duplicating every opportunity into the graph “for completeness” creates conflicting official numbers and an erasure nightmare.
The fourth is confusing this with causal science. A fluent model paragraph that says “because” is not identification. Neither is a dashboard of two rising lines. See What is causal AI for operations.
Good looks like reconstructable interventions with pointers, named people, and typed retention. Failure looks like a vendor log, a personal thread, or an infinite lake of tokens.
How this shows up in Nimbus
Nimbus’s Lifecycle Graph is that chain as a product: briefs, playbook citations, connector reads, spend, approvals, and write results are linked as work proceeds.
Perception is how you ask it in ordinary language — “why did this opportunity change last month?” — instead of reconstructing Slack.
The graph records work, not every token the company ever sent to a model. Scope follows the job, so a go-to-market question should not surface People Ops briefs. Connectors default to read-only; a read that did not write is itself a node worth knowing. Fail-closed writes mean a missing named signer is a recorded refusal, not a silent mutation.
Product: Lifecycle Graph and Perception. The job that produces the chain is a workstream.
Questions people actually ask
Is this just a knowledge graph of the business?
No. A business knowledge graph models customers, products, and sites. A lifecycle graph models AI-mediated work — what was asked, who signed, what changed. They can link (the write points at an opportunity). They are not the same thing.
Can’t the warehouse be the record?
You can copy events into a warehouse for reporting. You still need something that emits those events at the moment of the brief, the quote, and the approval. Retrofitting six months of ChatGPT and Slack is archaeology, not operations.
How is this different from the model provider’s logs?
Provider logs show API calls. They do not know your job, your playbook version, your approver, or whether the write was rejected.
How long should we keep it?
Treat it like other control evidence. Align retention with the type of record, legal hold, and storage limits. The product must support export, deletion, and access control — not infinite chat.
How does this relate to a person having to approve?
A human gate only counts if you can later show who signed and what they saw. Without a graph, that gate is a popup that forgets. See What is human-in-the-loop AI.
Does the graph replace CRM field history?
No. Field history says the value changed. The graph says which job, which policy version, and which named signer caused the proposal. Keep both. Point; do not duplicate.
What if the model’s explanation disagrees with the graph?
Trust the structure. Fluent “because” text is often written after the fact. The chain of brief, sources, quote, and signature is the operational cause.
Can we store every prompt and completion?
You can. You usually should not. Completeness is reconstructability, not hoarding. Secrets in transcripts become a new breach class. See What is institutional memory in enterprise AI.
How do permissions work on the graph?
The same least-privilege instinct as the job. If you could not see the People Ops workstream, you should not query its chain in ordinary language either.
Is a screenshot of the approval enough?
For a one-off incident, maybe. For a control, no. Screenshots do not join, do not retain by type, and do not survive the laptop.
Where does spend sit on the chain?
Quotes, caps, and stop-on-budget are causal events. “The run did not write because the ceiling was hit” is an answer finance can use. See What is AI token economics.
How is this different from MLOps experiment tracking?
MLOps tracks model training and deployment. A lifecycle graph tracks operational work that uses models. They stack. They do not substitute.
Related reading
If the goal is what the company still knows after people leave, read What is institutional memory in enterprise AI. The job that produces the chain is a workstream. For the science versus operations cut, What is causal AI for operations.
Sources
See what governed AI looks like on your stack.
Connect your tools, run a workstream, and keep every decision on your ledger - free for 7 days.