Project intelligence · Status typing · Refusal

Discussed Is Not Deployed: Why Project Intelligence Needs a Status Ladder

Multi-source project assembly has just become easy. Without a status ladder, the same fluency that assembles requirement, commit and test into one answer will tell an executive that something is done — when the evidence only supports that it was discussed.

Scott Farrell · LeverageAI · July 2026 · Extends The Deliberation Is Source and Provenance-Coupled Work

A project manager asks an AI assistant why an integration delay is still open. The system has access to the ticket, last week's design meeting, the developer conversation with a coding agent, yesterday's commit, a green test run, the deployment board, and an older incident that looks related. It answers in polished prose. The answer feels like an upgrade over digging through five tools. Then someone forwards that answer to an executive. The sentence that arrives is a single confident claim: the integration work is done. It is not done. It is coded, committed, and tested. It has not been deployed. A dependency owned by another team is still open. The meeting that discovered the constraint is still the best explanation of why the delay exists — and that meeting is not a ship event.

That is the failure mode this article exists to name. Not retrieval. Not "AI hallucinated a ticket number." The failure is more modern and more dangerous: the system joined the right materials, then erased the distinctions that make those materials true.

Why this is urgent now

For most of software's history, multi-source project assembly was expensive. A careful person could do it — open the ticket, open the meeting notes, open the pull request, open the pipeline, open production telemetry — but the labour was the filter. Laziness protected you. You could not casually average a design conversation with a production metric because assembling them took half a morning.

That constraint is gone. Agent stacks, repository access, test logs, deployment APIs and conversation archives can now be joined in one sitting. The first product instinct is obvious: dump everything into one answer. The demo looks miraculous. The pilot report glows. Then the first wrong "done" lands in a leadership thread, and the organisation discovers that fluency is not the same thing as fidelity.

Software delivery was already hard without this new class of error. Classic industry outcome data put only about a third of technology projects in the fully successful bucket, with half challenged and nearly a fifth failing outright.¹ AI-specific work is worse still: estimates compiled in a 2024 RAND study put AI project failure at more than eighty percent — roughly twice the failure rate of non-AI IT projects — with root causes dominated by mis-set problems, data, infrastructure and organisational mismatch rather than model cleverness alone.² Against that background, a tool that makes partial work sound finished is not a convenience feature. It is an accelerant for a known failure pattern: optimising, reporting, or celebrating the wrong state of the work.

McKinsey's 2025 State of AI survey describes a related gap at enterprise scale: most organisations still report AI use, yet nearly two-thirds have not begun scaling AI across the enterprise and remain in experiment or pilot modes.³ "We are using AI on the project" and "the capability is live in the business" are different sentences. Project intelligence that cannot keep those sentences apart will reproduce the pilot-to-production gap inside every status answer it writes. The forecast pressure is only rising: Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027 — a reminder that fluent narratives of progress are not the same as durable delivery.⁴

So the timing is not "AI can read code now." The timing is: multi-source assembly has become cheap enough that the first generation of project intelligence will ship join-everything, type-nothing by default — and it will look like an upgrade until the first executive acts on a flattened status.

Six layers, six questions

A software project does not have one source. It has several source layers, each authoritative for a different question. The sibling argument that deliberation itself is source material — that conversations, drafts and rejected paths are recoverable upstream of finished artefacts — is already established in The Deliberation Is Source; this piece takes that distinction as given and asks what happens when software layers are joined without types. The how of joining conversation to artefact — keys, edges, capture-time coupling — is owned by Provenance-Coupled Work and will not be re-derived here.

What this piece owns is the question table and the maturity ladder that have to survive every join.

Each row is a truth-maker for one question and a liar for the others. Conversation is the only place that reliably holds "we deferred barge-in handling because the media stream made it fiddly." Code is the only place that reliably holds the function bodies that exist. Tests are the only place that holds "this behaviour was demonstrated under these fixtures." Git holds custody and time. Deployment holds environment reality. Telemetry holds operational consequence.

A system that can open all six layers is powerful. A system that then answers as if they were one layer is performing a category error at machine speed. The error does not look like a missing citation. It looks like a confident narrative.

This is the software-specific version of a discipline Engagement World already requires in project knowledge work: origin and authority must travel into every compiled room, because authority flattening is how secondary material starts to look like confirmation. What Engagement World does not hand you ready-made is the eight-state maturity ladder for a project fact, or the layer-to-question table above. That is the unique territory of this piece.

Intent is not the repository — and the gap is information

Before the ladder, one distinction has to be locked hard: the difference between what was meant and what was shipped is not noise. It is signal with a single source class.

Code records final state. The transcript of the work — human–human or human–AI — records dated intent, rejected alternatives, and planned but unbuilt work. Relative to Python and Git, the .py file is source. Relative to the AI-assisted development process, that file is already compiled output from an upstream package of intent, dialogue, tests and decisions. The transcript is a source map: it carries why, what was tried, what failed, and which conditions mattered — material the resulting code cannot reconstruct.

That yields a project fact no repository search can emit:

"Considered X and deferred it."

There is no function, no file, no commit for a deferred path. A system that only reads the repository will report silence. Silence will be read as "we never thought of it." That is a lie of absence. The idea was present. The decision was deferral. The evidence lives in deliberation, not in the tree.

If your project intelligence cannot represent deferred intent as a first-class statused fact, it will systematically under-report the organisation's actual judgment. Teams will re-propose paths already rejected. Capability audits will miss work that was thoughtfully not built. The AI will look thorough while being structurally blind.

The eight-state maturity ladder

Here is the artefact this article wants you to take away and put on the wall next to every project assistant. A project fact — a feature claim, a fix claim, an integration claim, a "we handled the delay" claim — can sit on exactly one highest honest rung at a time. Collapsing any adjacent pair produces a confident false statement.

The ladder:

discussed → proposed → coded → committed → tested → deployed → observed in production → accepted

Eight states. Not five. Not "todo / doing / done." The extra rungs exist because modern delivery creates intermediate truths that executives, clients and AI systems are desperate to compress.

Collapsing adjacent pairs is how the lies form. Discussed → proposed: a chat becomes a plan. Proposed → coded: a design becomes implementation by rhetoric. Coded → committed: a laptop hero becomes team history. Committed → tested: a merge becomes verified behaviour. Tested → deployed: a green suite becomes live. Deployed → observed: presence becomes health. Observed → accepted: uptime becomes stakeholder done. Each step is a small, seductive verb change. Eight small lies make one executive disaster.

One query, two answers — same facts, opposite conclusions

Proof cannot stay abstract. Take one project-manager question and answer it twice on the same underlying evidence set.

Query: "Why is the integration delay still open?"

Underlying facts available to both answers (invented only in the sense of a worked scenario built from the source conversation's nine-part assembly — not as a claim about a named client system):

• A requirement exists for service A to hand off cases to service B within a defined SLA.
• A meeting two weeks ago discovered that B's auth model rejects the token shape A emits.
• A developer discussed the fix with a coding agent and explored two approaches.
• The first implementation approach was rejected in that session.
• Yesterday a commit landed with the second approach on the integration branch.
• The automated integration test for the happy path now passes in CI.
• No production deployment of that commit has occurred.
• An earlier, similar token mismatch on another pair of services was resolved last quarter with a gateway adapter.
• Team C owns the auth service change still required for the long-term fix; that ticket is open and blocked on their sprint capacity.

Same nine ingredients. Opposite operational meaning. The difference is not model quality. The difference is whether the system is allowed to collapse the ladder.

If you only remember one diagnostic from this article, remember this contrast. Whenever a project assistant returns Answer A energy, ask it to restate the answer as Answer B: highest honest rung, evidence class per claim, explicit refusals above that rung.

Walk the nine-part assembly in full

The double answer above used the nine items as a list. The point of this section is to do the work — to show how each item carries its own status and how a manager actually uses that typing.

1. The original requirement

Requirements are not "done work." They are scope commitments. In a typed assembly, the requirement answers: what would acceptance look like if everything else succeeded? It does not answer whether anyone has started. For the integration delay, the requirement establishes the SLA handoff as in-scope. Its maturity as a requirement fact may be accepted (signed scope). Its maturity as a delivered capability is still far down the ladder. Conflating those two uses of "accepted" is a common office foul: scope accepted is not outcome accepted.

2. The meeting where the constraint appeared

This is conversation-layer gold. The auth token mismatch is not inventable from the repository alone if nobody coded the failing path yet; it may only exist as testimony and a failing manual probe. Status: discussed, possibly proposed as a constraint statement ("B requires token shape T2"). Evidence: meeting record, date, attendees, the constraint sentence. Why it matters operationally: without this item, the delay looks like laziness. With it, the delay has a cause. Flattening systems often promote this meeting into "the fix," because meetings feel like progress. They are not deployments.

3. The developer conversation with the coding agent

Human–AI coding sessions are now first-class project records. They hold intent, attempted patches, test commands, and the emotional temperature of uncertainty. Treat them as conversation-layer source maps, not as proof of commit or deploy. Status for most of the content: discussed, with fragments that may rise to proposed or coded when files change. A session that only explores is still valuable — it is where rejected alternatives live.

4. The rejected first implementation

This is the intent-versus-repository distinction under load. The rejected approach may leave no residual code. If the system only searches the tree, the rejection evaporates. Typed assembly keeps it as: proposed → rejected (terminal side-state), with rationale. Operational use: stop the next developer from re-trying the same dead end next sprint. Flattened assembly either drops it or, worse, paraphrases it as "the team tried a few things and succeeded," which erases the cost of learning.

5. Yesterday's commit

Now we have git-layer authority. SHA, author, time, parent, files touched. Status: committed. The commit message may claim "fix integration auth" — believe the tree more than the verb "fix." Commits answer custody. They do not answer production. The most common executive-facing lie in modern tooling is allowing "merged yesterday" to imply "live yesterday."

6. The test that now passes

Test-layer authority: a named suite, a run, a result. Status: tested, for the scope of that suite. If the suite is happy-path only, the typed answer must say so. A flattened answer hears "tests pass" as "safe." A typed answer hears "this claim was demonstrated under these fixtures." Those are different English sentences and should remain different system sentences.

7. The deployment that has not happened

Absence is a fact. Known absence of a deployment record for the SHA is stronger than vague optimism. Status: not deployed — which means the fact cannot be observed in production and cannot be accepted as delivered capability. Engagement-style project worlds already treat known absences as something a compiled room should surface rather than smooth over; the status ladder makes the same move for delivery maturity. Flattened systems hate absences because they ruin narrative smoothness. That is exactly why they must be first-class.

8. The earlier similar problem

Precedent is not progress. Last quarter's gateway adapter is an accepted historical fact about another integration. Status: accepted as precedent, not as work on this delay. Typed assembly may recommend the pattern. It may not count the precedent as completion. Flattened assembly loves precedent because it sounds like proof: "we've solved this class of issue before." Classes are not instances.

9. The unresolved dependency owned by another team

Cross-team dependencies are where status fiction becomes political. Team C's open ticket is proposed or discussed on their side; for your delivery claim it is a hard blocker. Status: open dependency — and therefore the integration delay remains open even if your commit is perfect. Flattened assembly buries this under "coordination." Typed assembly puts it in the first sentence of the summary, because it is often the actual reason the ticket cannot close.

Walked this way, the nine-part assembly is not a dump. It is a score. Each item earns a rung. The delay ticket's honest status is the minimum of what delivery requires: until deploy + observe + accept (and until the blocking dependency clears or is formally waived), the delay stays open. That is not pessimism. That is arithmetic on the ladder.

The tell-phrase: "the project says"

Listen for it in AI answers, status decks, and stand-up summaries:

"The project says the migration is complete."

"According to the project, auth is sorted."

"The system shows we're done with the integration."

Those sentences are almost never true in the way a listener hears them. "The project" is not a witness. It is an average of disagreeing witnesses. Conversation said one thing. Code said another. CI said a third. Production said nothing yet. The averaged voice sounds like authority because it is singular. Singularity is the tell.

Prefer sentences that cannot be spoken without a layer:

• "Conversation records show the constraint was discovered on the 12th."
• "Git shows SHA a1b2… committed yesterday."
• "CI shows the happy-path suite green on that SHA."
• "The deployment board shows no production release for that SHA."
• "Team C's ticket remains open; no code from them yet."

Ugly? Good. Ugly is how types sound before you get used to them. Smooth is how averages sound when they are about to hurt you.

A lint rule you can actually run

Capability without refusal will lose to the next demo that looks smoother. So build refusal into the product. Here is a concrete lint pattern — specific enough to implement as a post-processor on any project-assistant answer.

Example flagged sentence: "Overall the project says the integration is done pending a quick release."

Why it flags: (1) contains the project says; (2) "done" maps to accepted; (3) evidence ceiling is tested (CI green) with explicit not-deployed; (4) "pending a quick release" admits deployment absence while still selling "done."

Rewrite the linter would demand: "Highest honest state: tested. Evidence: CI run {id} green on SHA {sha} for happy-path suite. Not deployed; not observed; not accepted. Open dependency: Team C ticket {id}."

You can implement step 1 with a small classifier or even regex-plus-rules for the first version; steps 3–4 are deterministic once the evidence bundle is typed. The point is not a perfect NLP product. The point is a product that can fail closed: if it cannot prove a rung, it may not assert that rung.

Model the discipline: say which layer you read

The source conversation that produced this doctrine included a precision note worth elevating from anecdote to practice. While assembling a multi-layer account of recent coding work, the assistant had read a recorded development session — including edit operations, commands, test outputs and replay results — plus code pointers from a project page. It had not independently opened and verified the Git diff in that chat. The detailed evidence actually used was primarily the recorded session. Saying so was not a confession of weakness. It was the provenance discipline under discussion, applied to the discussion itself.

That is the standard project intelligence should meet on every non-trivial claim:

• Name the layers opened.
• Name the layers not opened.
• Do not let routing potential ("the system could open the diff") substitute for evidence actually used.
• If a higher rung requires a layer you did not open, stop climbing.

If that paragraph feels pedantic, good. Pedantry is how types survive contact with narrative pressure. The alternative is "trust me, I looked at the project," which is just "the project says" in first person.

What to demand from any project intelligence product

Whether you are building or buying, the evaluation questions are now concrete.

1. Does every answer name maturity states? If the product returns only prose paragraphs without state labels, it will flatten under executive summarisation even if the buried text is careful.

2. Can it represent deferred and rejected work? If the only first-class objects are tickets, commits and deploys, half the judgment in your organisation is invisible. Intent-layer facts must survive.

3. Does it keep absences visible? "No production release for this SHA" should be as easy to emit as "latest commit message."

4. Does it refuse adjacent-state collapse? Ask the double-answer test in the sales demo. Give it the nine ingredients. If it produces Answer A energy, fail the demo — politely, and with the ladder in hand.

5. Does it show what it did not read? Routing graphs that could open a layer are not the same as having opened it. Cognitive provenance — what the agent actually observed — is part of the answer, not an optional debug panel.

6. Is the join layer separate from the status layer? Joining is necessary. Status typing is necessary. One does not imply the other. Products that boast "we connect Jira, Git, CI and Slack" are advertising the easy half. Ask what they decline to merge.

Engagement World already frames the project-scale container: more persistent than chat, more structured than a folder, less permanent than institutional canon — a place where teams accumulate what they have learned, proposed, rejected, implemented and verified. Compiling a role-shaped room for a project manager means preserving dates, lenses, absences, sources and authority — not dumping every artefact into context. This article's contribution is the delivery-status ladder that must ride inside those rooms when the domain is software: eight rungs, evidence per rung, refusal between them.

The federation, promotion and expiry mechanics of those worlds are real and important — and they are not this piece. Neither is the corporate-knowledge extension beyond software delivery, nor the low-level join mechanics that make multi-source assembly possible. Those are sibling territories. Use them. Do not blur them into this argument as if more doctrine automatically yields more honesty. Honesty here is a ladder and a refusal.

The upgrade that earns trust

We are entering a period where every software organisation will be offered a brain that can see tickets, code, tests, deploys and chat at once. That brain will be sold as "project awareness." Some of it will be real. Much of it will be Answer A in a nicer font.

The organisations that stay sane will not be the ones with the most connectors. They will be the ones whose systems are allowed to say:

Highest honest state: tested. Not deployed. Dependency open. Constraint still binding.

That sentence is shorter than a status novel and truer than a status fiction. It is also rarer than it should be, because it refuses to perform completion theatre.

RAND's interviews with practitioners building AI systems keep returning to a non-glamorous pattern: projects fail when the wrong problem is optimised, when infrastructure and data are missing, when technology is chased instead of outcomes.² Status flattening is a new way to optimise the wrong problem — optimising the appearance of progress across joined sources. Readiness gaps make the temptation stronger: leaders already feel urgency to show AI impact while a minority of organisations report full readiness to integrate it.² Into that pressure, insert a fluent assistant that can turn "tested" into "done," and you have a machine for manufacturing false readiness.

So build the ladder into the prompt, the schema, the UI, and the lint. Teach every project assistant the six questions and the eight states. Reward answers that show their ceiling. Punish "the project says." Keep deferred work visible. Keep deployments from being inferred from commits. Keep acceptance in human hands.

Multi-source fluency is real. It is also insufficient. The product is not the join. The product is the join that still knows what it is not allowed to claim.