Glossary: the words behind an AI product brain

Short, plain definitions of the words product teams use when they talk about keeping product knowledge for people and AI tools. Each one starts with the definition, then says how Rivora Connect uses it.

AI product brain

An AI product brain is a shared memory of how your product works: the decisions, rules, code knowledge and clarifications behind it, which people and AI tools draw on when they design and build each feature. Rivora Connect is an AI product brain for product teams on established software. Your team designs each feature in its workflow and checks every part, and every answer adds to its memory. Also called a product brain.

Product memory

Product memory is what a team has confirmed about its product, kept so the next feature can use it: decisions, business rules, clarifications and what the code really does. Documents hold what someone wrote once. Product memory grows with every feature, and each item says where it came from. In Rivora, memory comes from what people say and confirm. See knowledge leaving with experts.

Shared product memory

Shared product memory is product memory that belongs to the whole team. A chat remembers one person's conversation. Shared product memory holds what the whole team confirmed, so people and the AI tools they connect start from the same answers. See Rivora in Claude and ChatGPT.

Governed memory

Governed memory is product memory with rules about how it changes. In Rivora, each decision records where it applies, where it came from and who confirmed it. Nothing is learned silently: memory comes from what people say and confirm. A decision or rule changes only when a person replaces it or stops it.

Decision log

A decision log is a record of product decisions: what was decided, why, when, by whom, and what it applies to. Most teams keep one by hand, after the meeting. In Rivora, decisions are kept as part of designing each feature, with their scope and who confirmed them. Try the free decision log template, or read how to keep decisions made in Slack.

Business rule

A business rule is a constraint the product must follow, such as a regulation, a contract term or a policy for one client or market. In Rivora, business rules apply to every feature in the product, and a rule can be limited to one client area.

Clarification

A clarification is an answer to a question that came up while a feature was designed: what should happen in a case the request didn't cover. In Rivora, an answered question can be kept as a clarification, a decision or a rule, so the next feature doesn't ask it again.

Feature readiness

Feature readiness is how sure a team can be that a feature is ready to build: the intent is clear, the rules and edge cases are answered, the impact on the current product is known, and the open questions are few and named. Check a feature with the free feature readiness check.

Context engineering

Context engineering is the work of giving an AI tool the right information before it starts, so it doesn't have to guess. For product teams, the hardest context to engineer is the part that was never written down: past decisions, client-specific rules and which code is still used. Rivora gets that context from the people who know while each feature is designed.

Product context for AI coding agents

Product context for AI coding agents is the approved plan for a feature, plus the decisions and business rules behind it, given to a coding agent before it builds. In Rivora, approved work goes to coding agents such as Claude Code, Cursor and Codex, with the decisions and rules attached. See product context for AI coding agents.

Expert queue

The expert queue is the line of people waiting on the few who know how an established product really works. See why every feature waits on the same few experts.

Feature's solution

A feature's solution is the complete design for one feature, in up to nine parts: Executive Summary, Feature Intent, Product Impact, System Impact, Frontend and UX, Backend and Platform, Data and Memory, Implementation Handoff and Delivery Backlog. In Rivora, your team checks every part: a person approves each part, sends it back with a comment, or edits it.

Handoff

A handoff is a feature's approved plan: the approved version of its solution, frozen so engineers and coding agents build from exactly what the team approved. In Rivora, the handoff carries the approved parts, the business rules and the sources each part used.

Established software

Established software is a product that has been live for years: it carries old decisions and old code, is set up differently for different clients, follows strict rules, or depends on a few people who know how it all works. Rivora is built for product teams on established software. See who it's for.