Why Nopal
Your team's most expensive loss is not time. It is reasoning.
Every organization has a record of what it decided. Almost none have a record of why. This page is the long version of what Nopal does about that, who it is for, and what it deliberately refuses to do.
The cost
Reasoning has a half life of about six weeks.
A decision gets made on a Thursday. The thinking behind it is vivid to everyone in the room: the two options that nearly won, the customer call that killed the third, the reservation one engineer raised that turned out to be the important one.
Six weeks later the shape survives and the substance is gone. Six months later a new hire asks why, and the honest answer is that nobody is quite sure anymore. So the team does one of three things, all expensive: they reopen a settled question, they defend a choice they can no longer justify, or they repeat a mistake whose reasoning was never written down.
This is not a discipline problem. People document conclusions because conclusions are easy to write. Reasoning is structured, and prose flattens structure into paragraphs nobody can query later.
The same decision, twice
One of these survives contact with next year.
How it exists today
#product · 14 Feb
ok we're going with tiered pricing, shipping Monday
3 replies
Six months later this is the entire record. The reasoning was real; nobody wrote it down.
The same decision in Nopal
- Came from
- Should we move to usage-based pricing?
- Rejected
- Flat-rate for everyone · Pure usage-based
- Rests on
- 1 claim, backed by Q3 interview synthesis
- Argued against by
- Tiers add friction at the top of the funnel
The same five minutes of typing. A year from now it still answers the question.
Why your tools do not catch it
Four good tools, none of them built for this.
Nothing here is a criticism of the software your team already runs. Each of these does its job well; none of their jobs is holding reasoning.
- Chat
- Optimized for recency. Reasoning arrives interleaved with everything else and scrolls out of reach within a day. Search returns the sentence, never the structure around it.
- Docs and wikis
- Optimized for the finished statement. They hold the conclusion beautifully and lose the alternatives, the objections, and the evidence. They also rot silently: nothing tells you a page now contradicts a decision made last month.
- Ticket and project trackers
- Optimized for work that closes. Once a ticket ships it is archived, and the reasoning inside it is archived with it, filed under a number nobody will guess.
- AI assistants
- Optimized for a plausible answer now. They can summarize what your team wrote; they cannot tell you what your team actually concluded, or which of two contradictory notes is still true.
What it is
A knowledge graph with four kinds of node, and opinions about each.
Nopal is a reasoning operating system: a workspace where the unit is not a page or a message but an artifact, and where artifacts are connected by relations that mean something specific.
You write a Decision, and the Decision holds the options you rejected. You write a Claim, and the Claim carries its evidence, including the evidence against it. You mark something as Knowledge when the team has settled it. You open a Discussion when it is not settled yet.
Then you connect them, and the connections are typed. One artifact supports another. One contradicts another. One led to another. The graph is not decoration; it is what makes the reasoning queryable six months later.
- Decision
- The call, the options considered, the rationale, and the conditions that would reopen it. Decisions are the spine of the graph; most other artifacts exist because a decision needed them or came out of one.
- Claim
- A position with a stance toward its evidence. Evidence can support a claim or contradict it, and both are kept, because a claim with no visible counter-evidence is a claim nobody has tested.
- Knowledge
- Settled ground. The thing your team no longer argues about, written once so the next person can build on it instead of rediscovering it.
- Discussion
- The open question, in one place. Not a thread to keep up with; a container that eventually resolves into a Decision, a Claim, or Knowledge.
The reasoning chain
The answer sits up top. Everything under it is why.
This is the actual shape of a decision in Nopal, lane by lane, with the questions the product asks you as you build it.
The decision
Adopt tiered pricing over flat-rate
rests on
Origin
What led to this decision?
led to
discussion
Should we move to usage-based pricing?
Options considered
What else was on the table?
Supporting claims
What claims support it?
supports
claim
Teams under ten seats churn on flat-rate
Evidence
What evidence backs those up?
supports
knowledge
Q3 enterprise interview synthesis
Opposing views
What pushes against it? Recording opposition is healthy.
contradicts
claim
Tiers add friction at the top of the funnel
Related
Anything else worth connecting? Sorting into lanes is optional.
Empty lanes stay visible, so the shape of good reasoning does too.
The mechanism
Disagreement is kept, not resolved away.
Most knowledge tools treat a contradiction as an editing error: someone should reconcile the two pages and delete one. Nopal treats it as information.
When one artifact contradicts another, that tension is recorded as a relation and stays visible on both. When someone contests an artifact, their perspective does not vanish into a comment thread; it becomes a Claim of its own, linked to what it disputes.
The result is a graph you can trust precisely because it does not pretend to agree with itself. You can see where your team is aligned, where it is not, and which unresolved tension is sitting underneath a decision you are about to make.
Why it improves
Pads from pads.
Nopal is named for the prickly pear cactus, which grows by putting out new pads from the pads already there. It is not a decorative metaphor; it is the product's central claim.
Because every artifact cites what it stands on, each answer makes the next one cheaper. The first time your team reasons about pricing, it costs a week. The second time, the evidence is already there and the rejected options are already written down. By the fifth time, the expensive part is just the new information.
This is the opposite of how a wiki ages. A wiki gets heavier: more pages, more contradictions, more archaeology per question. A reasoning graph gets lighter, because the structure that made the last answer findable is the structure that makes the next one fast.
The shape of the product
A module-agnostic core, with frameworks on top.
The core is the graph: artifacts, relations, topics, search, and the people who tend them. It knows nothing about your industry, and that is deliberate.
Modules are frameworks that sit on top of that core for teams that need a specific discipline. Projects gives a body of work its own charter, timeline, and decision history. Insights turns scattered signals into evidence you can actually weigh, with a readiness view that shows which dimensions of a bet are backed and which are guesswork.
Modules are licensed separately and add per user. The core never learns their vocabulary, so nothing you write inside a module is trapped there.
The limits, stated up front
What Nopal deliberately is not.
Being clear about the edges is faster than letting you discover them in week three.
- It does not decide for you
- Nopal will show you thin evidence, unresolved contradictions, and decisions that have gone stale. It will not resolve them. Judgment stays with the person accountable for it.
- It is not a chat replacement
- Keep talking wherever you talk. Nopal is where the conclusion and its reasoning land afterward, which takes a couple of minutes, not a culture change.
- It is not an AI that reads your company
- AI features are off by default in every workspace and require someone to turn them on. Deterministic features (search, similarity, propagation) run without a model and without sending anything to one.
- It is not a document store
- You can attach documents, but Nopal is not trying to be where your files live. It is trying to be where your reasoning lives.
Fit
Who this is actually for.
Nopal earns its keep where decisions are expensive, contested, and revisited: product and engineering teams, research groups, strategy and operations functions, anyone who has been asked to justify a choice made a year ago.
It is a poor fit for work that is purely executional, where the decisions are small and the reasoning genuinely does not need to outlive the task. If your team never asks why, you do not need this.
The honest test: think of the last decision your team reversed. If reconstructing the original reasoning took more than an hour, Nopal pays for itself on that one incident.
Bring one decision.
The trial is fourteen days and needs no card. Do not migrate anything. Take one decision your team has already made, write it down properly, and connect the two or three things it rests on. That is the whole evaluation.