“Which three?” Daniel asked.
Sofia did not answer until the product review had started.
The room was smaller than the boardroom and carried more evidence of work: half-erased diagrams, charging cables, coffee rings, and a row of sticky notes that had begun to curl away from the wall. Leila sat at the end of the table. Ravi and Hannah joined on the screen. Marcus stood near the window with his laptop open.
On the main display, the Auralis home page waited beneath a familiar promise.
Intelligence you can trust, govern, and put to work.
Sofia clicked New workspace.
“The three things,” she said, “are governed organizational knowledge, reusable assistants, and controlled actions.”
Leila looked up. “We have all three.”
“We have screens for all three.”
The distinction settled over the table.
Sofia opened the sales deck beside the product. The slide showed an administrator connecting SharePoint, Confluence, and Google Drive to a single workspace. A lock icon sat beside the words Your permissions follow your data. Beneath it, an assistant summarized a policy, compared it with a contract, and created an approval task.
The sequence took twelve seconds.
“This is the story Evan’s team is showing,” Sofia said. “Now I’ll show the product.”
She dragged a policy document into Auralis. A progress indicator appeared.
Processing.
“Direct upload works most of the time,” Hannah said from the screen. “The SharePoint connector is an internal spike. It imports files under one service identity. It does not preserve source permissions.”
Daniel wrote on the whiteboard.
Deck: permissions follow the data.
Product: workspace access follows the upload.
“Can a user see a document in Auralis that they cannot see in SharePoint?” he asked.
“In the spike, yes,” Hannah said. “That is why it is not enabled outside development.”
“But the deck says connected knowledge,” Leila said. “It does not say the connector is generally available.”
“The diagram says permissions follow the data,” Sofia replied.
“That is the intended behavior.”
“It is also the reason an enterprise customer would believe the connection is safe.”
Leila’s expression tightened. “I know why the control matters.”
Daniel put down the marker. The conversation had begun to turn into a trial, and trials made people defend territory rather than examine evidence.
“Let’s separate the questions,” he said. “Is this a useful vision? Yes. Does the current product satisfy it? No. Has anyone deliberately misrepresented the product?”
No one answered.
“Then we are not looking for a culprit. We are identifying where a future-tense statement became a present-tense promise.”
Sofia returned to the demo. The document completed processing after forty-three seconds. She opened the assistant builder, selected Policy Analyst, and changed two instructions. Then she clicked Share with organization.
“This creates a reusable assistant,” she said. “But its configuration is stored as a JSON object owned by the creator. There is no version history, approval workflow, test set, or rollback. If I change the instructions tomorrow, every user gets the change immediately.”
Ravi leaned closer to his camera. “That is a governance backlog, not evidence we do not have assistants.”
“The slide calls them governed assistants.”
“The slide calls the knowledge governed.”
“The website calls the whole platform governed.”
Marcus spoke without looking away from his laptop. “We are arguing grammar.”
“Customers buy grammar,” Daniel said. “Especially when the nouns are data and the adjective is secure.”
Marcus closed the laptop halfway.
Daniel recognized the pattern. Every statement was defensible in isolation. The prototype demonstrated the intended experience. The architecture anticipated stronger controls. The roadmap included the missing work. The sales team needed a coherent story. The website could not carry an engineering footnote beneath every sentence.
Yet the combination created a product more complete in the customer’s mind than in the system.
Sofia opened a conversation with the Policy Analyst.
Compare the travel policy with the executive expense standard. Identify conflicts and create an approval task for the finance director.
The response streamed smoothly. Auralis found three differences, cited both documents, and presented a blue Create task button.
Sofia clicked it.
A green message appeared: Approval task created.
“Where?” Daniel asked.
“Nowhere,” Sofia said. “It is a demo response. The button calls a stub.”
Even Ravi looked surprised.
“The action was built for the conference video,” Sofia continued. “The design is real. The interaction is real. The integration is not.”
“Who knows that?” Daniel asked.
“My team. Product. I assumed sales.”
Leila shook her head. “The slide was created from the launch concept. I did not know the button had been added to the shared demo environment.”
Marcus opened his laptop again. “There is an agent tool interface behind it.”
“There is an interface,” Ravi said. “The authorization model is not finished. We disabled external execution until tool calls carry user identity and policy context.”
Daniel added a third pair to the board.
Deck: controlled actions.
Product: simulated action; control model incomplete.
The word simulated made the room uncomfortable. It sounded like fake, though a simulation could be exactly the right way to test an experience before taking on the risk of execution.
The problem was not that the action was simulated. The problem was that the boundary had disappeared.
“Show me the source slide,” Daniel said.
Leila opened the product strategy folder. There were six versions of the deck, three marked final. The newest contained comments from marketing, sales, product, and Olivia. A diagram had moved between versions. A footnote reading illustrative future experience had disappeared when the layout was simplified. Connected knowledge with workspace controls had become permissions follow your data. Proposed approval action had become controlled actions.
No single edit looked reckless. Each made the story shorter, clearer, and stronger.
Together they crossed the distance from direction to availability.
“This is not just a sales-deck problem,” Daniel said. “It is a product-state problem. We have no shared vocabulary for what is live, limited, simulated, committed, or envisioned.”
Leila turned from the screen. “A deck still needs to describe where we are going. If we only show what exists today, we sell last quarter’s product.”
“Agreed.”
“And early customers understand roadmaps.”
“They understand them when we label them.”
“Labels do not prevent disappointment.”
“No. But they let us decide which disappointment we are accepting.”
Ravi unmuted. “The technical reality is not as far from the vision as this makes it sound. The assistant runtime exists. The tool protocol exists. Retrieval works. We are missing production controls around capabilities we have already demonstrated.”
Hannah looked toward him in the video grid. “Retrieval works on curated documents. We have not tested permission-aware retrieval across a connected corpus, because we do not have permission-aware ingestion.”
“That is integration work.”
“It changes the retrieval index, cache keys, deletion behavior, evaluation data, and incident boundary. Calling it integration work does not make it small.”
“I did not say small.”
“You said controls around capabilities we already have.”
Daniel watched two honest technical descriptions pull in opposite directions. Ravi saw the difficult intelligence already functioning and the missing structure as a path to production. Hannah saw that structure as part of the capability itself. Both views contained planning value. Neither could stand alone.
“How many versions of Auralis are we discussing?” he asked.
Sofia frowned. “One?”
Daniel drew three columns.
Vision. Contract. System.
“The vision is the change we want to create for customers. The contract is what a customer may reasonably depend on in a defined release. The system is what the product can do now, under observed conditions.”
He pointed to the first column.
“Vision can lead reality. It should. It gives us a destination.”
Then the second.
“The contract must be precise enough for sales, product, engineering, security, support, and the customer to interpret the same way.”
Then the third.
“The system does not care what we intended. It has behaviors, limits, failure modes, costs, and evidence.”
Marcus walked to the whiteboard. Under System, he added a fourth word.
Architecture.
“What it can do now is not the full technical reality,” he said. “The architecture determines what it can become without being rebuilt.”
Daniel considered it, then drew a line beneath the word.
“Good. But architecture is an option, not delivered value. It changes the cost and probability of the path. It does not move a capability into the present.”
Marcus nodded once. Not agreement exactly, but acceptance that the distinction belonged on the board.
Leila stood and reread the columns. “So what do we do with the deck? Evan is presenting it to Northstar Legal tomorrow.”
Northstar was Claire Dubois’s company, the strategic design partner Olivia had mentioned. If the pilot succeeded, it could become the evidence Aureline needed for the next financing. If it failed, the company would lose more than a logo.
“We annotate every consequential claim,” Daniel said. “Not on the customer slide. In a claim register behind it. Each claim gets a state, an owner, evidence, conditions, and the customer-safe language.”
Sofia pointed to the simulated approval. “That one is envisioned.”
“The experience is demonstrated,” Ravi said. “The external action is envisioned.”
“Then split the claim. A user can review a proposed action today. Auralis cannot yet execute it in Northstar’s system. Those are different product promises.”
Leila began typing.
They spent the next ninety minutes on eleven claims.
Evidence-backed answers became limited: citations worked for supported documents, but citation correctness had not been measured across Northstar’s corpus.
Reusable assistants became preview: users could configure and share assistants, but administrators could not approve versions or inspect change history.
Organizational knowledge became limited: direct uploads were available; permission-preserving connectors were not.
Controlled actions became two lines: demonstrated for generating an action proposal and vision for policy-authorized execution in external systems.
Enterprise-ready did not survive. It described too many independent obligations to carry one state.
They replaced it with the specific controls Northstar would need to evaluate: tenant isolation, identity, audit history, retention, evidence quality, regional data handling, availability, and support.
At twelve twenty, Evan entered the room holding his phone.
“I have a customer rehearsal in ten minutes,” he said. “Why did half the deck turn yellow?”
Leila rotated her laptop toward him. “Yellow means the claim is limited, in preview, or depends on an unverified assumption.”
“The customer will not see the colors,” Daniel said.
“Then why do I care?”
“Because you need to know which tense to use.”
Evan scanned the claim register. “If I say every qualification on this page, we will sound like we do not believe in our own product.”
“You do not have to recite the register,” Leila said. “You have to make the boundary clear when it matters.”
“Every competitor shows a destination.”
“So will we,” Daniel said. “But we will not let Northstar discover during security review that ‘permissions follow your data’ meant ‘we plan to build that.’”
Evan stopped at the action slide. “Claire loves this workflow.”
“Then show it as a design prototype,” Sofia said. “Ask whether the approval boundary is right. Do not say the task was created in her system.”
“It is a weaker demo.”
“It is a stronger discovery conversation,” Leila said.
Evan looked at her. Product and sales had spent months asking each other for more ambition and more realism, usually in that order.
“What can I say?” he asked.
Leila answered before Daniel could.
“Say: ‘Today, Auralis can find the evidence, draft the recommendation, and prepare the action for human review. We are designing policy-controlled execution with pilot customers. Before we enable it, we need to agree on identity, approval, audit, and failure handling.’ Then ask Claire which actions she would never allow an assistant to take.”
Evan read the sentence silently.
“That might actually be a better conversation,” he said.
“It is also true,” Sofia replied.
He sent the wording to himself and left.
The room relaxed, but Daniel did not. Eleven claims had taken six leaders an hour and a half. The deck was one artifact. The same claims lived in the website, demo scripts, product backlog, architecture diagrams, contracts, onboarding material, and people’s memories.
There would be no single document to correct.
Daniel returned to the board and circled the middle column.
“This is where the nine-month plan starts,” he said. “Not with the feature list. With the contract between the vision and the system.”
Marcus looked at the three columns. “And who owns the truth?”
It was the right question and the dangerous one. If product owned it alone, technical limits might appear too late. If engineering owned it alone, caution could shrink the market proposition. If sales owned it, the promise would follow the opportunity. If everyone owned it, no one would.
“Product owns the customer promise,” Daniel said. “Engineering owns evidence about system behavior and feasibility. Security and legal own the policies no roadmap can waive. Sales owns what it communicates. One person must own each claim, but no function gets to define reality alone.”
Leila closed the old deck and renamed the new one.
Not final.
Northstar — reviewed claims — September 1.
Sofia unplugged the display. Before leaving, she turned to Daniel.
“You asked which three things we do not have,” she said. “That was the wrong question.”
“What is the right one?”
“Which version of each thing have we earned the right to promise?”
After the room emptied, Daniel photographed the whiteboard.
His phone showed a new message from Evan.
Claire moved the meeting up. She wants our technical leads there. Also: they have already sent a security questionnaire.
Attached was a spreadsheet with two hundred and fourteen questions.
The product in the sales deck had just met its first customer.
Ambitious companies must describe a future that does not yet exist. A vision gives customers, investors, and teams a reason to participate before every capability is complete. The leadership failure is not speaking about the future. It is allowing the future tense to disappear as the claim moves through strategy, design, demonstration, sales, and delivery.
Small edits can create a large integrity gap:
No individual step requires deception. The system still produces a misleading result.
| Layer | Purpose | Governing question | Required evidence |
|---|---|---|---|
| Vision | Describe the customer change and strategic destination. | What should become possible? | Customer need, market relevance, and strategic coherence. |
| Product contract | Define what a customer may depend on in a release or pilot. | What exactly are we promising, to whom, and under which conditions? | Agreed behavior, boundaries, ownership, and acceptance criteria. |
| System reality | Describe observed behavior and the credible path forward. | What works now, at what quality, scale, cost, and risk? | Tests, evaluations, operational data, experiments, and architecture analysis. |
Architecture belongs in system reality, but it is not the same as a delivered capability. A sound architecture creates options and reduces the cost of change. It does not by itself satisfy a customer promise.
Teams often argue past one another because one capability contains several claims. “Controlled actions” might mean that the product can:
A successful demo of the first two is not evidence for the remaining four. Split broad language into independently testable claims. This produces better plans, clearer customer conversations, and more useful technical disagreement.
AI can help build and maintain a product-claim register by comparing decks, contracts, websites, release notes, support articles, roadmap items, and test evidence. It can flag inconsistent tense, unsupported adjectives, missing qualifiers, and claims whose evidence has expired. It can also generate customer-safe wording for different product states.
The review cannot be fully automated. A model may miss the commercial meaning of a phrase, infer capability from stale documentation, or treat an architectural intention as proof. Accountable owners must verify source evidence and approve consequential claims.
Humans must decide:
Truth in product communication is not merely factual accuracy. It is alignment between what was said, what the listener could reasonably understand, and what the organization can actually deliver.
Use one row for each consequential customer claim. Split compound claims until each can have one state and one evidence base.
Wrightery
PRODUCT-CLAIM REGISTER
Claim ID:
Customer-facing claim:
Primary owner:
STATE
vision / demonstrated / preview / limited / generally available / deprecated
SCOPE
Target customer or segment:
Supported workflow:
Conditions and exclusions:
Material limitations:
EVIDENCE
Evidence supporting the state:
Environment and data used:
Quality, scale, security, reliability, and cost results:
Evidence date and expiry/review date:
COMMUNICATION
Approved customer-safe wording:
Statements or implications to avoid:
Where this claim appears:
PATH FORWARD
Next state sought:
Work and evidence required:
Decision owner:
Target review date:
The register is not a disclaimer catalogue. Its purpose is to keep vision ambitious, commitments precise, and system reality visible while the product changes.
Wrightery is in private build. Join the waitlist and we'll bring you in as soon as a seat opens — then describe one deliverable you already produce, and watch your AI analysts research it, cross-check it and draft it for your review.
No credit card. We'll email you the moment your seat is ready.
Rather talk it through? Book a 30-minute meeting ↗