Feedback, Roadmap, and Customer Commitments

Draft 0.1 — 2 August 2026
Feedback is an input to product judgment, not an automatic vote. A roadmap is a planning artifact, not a binding delivery promise unless a separate authorized agreement says otherwise.

Objective

ANUKA products should make improvement participation real without turning every comment into a ticket, every vote into a mandate, or every roadmap card into a legal promise.

The protocol separates:

signal;
evidence;
request;
opportunity;
experiment;
roadmap intent;
funded commitment;
contractual commitment;
delivered outcome.

Feedback channels

Products may collect feedback through:

in-product forms;
browser extension;
public Backstage;
support conversations;
interviews;
surveys;
issue trackers;
community forums;
sales and customer-success records;
contributor proposals;
agent-assisted analysis;
operational telemetry.

Every channel declares its audience, privacy level, retention, and whether submissions may become public.

Feedback object

A feedback record contains:

feedback ID;
product;
submitter or pseudonymous reference;
source channel;
audience;
content;
category;
affected journey;
severity or importance as stated by submitter;
evidence attachments;
consent for publication;
created date;
status;
links to duplicates, opportunities, experiments, or decisions.

The record distinguishes the submitter’s statement from product-team interpretation.

Feedback audiences

private to product team;
visible to organization members;
visible to selected collaborators;
community-visible;
public with attribution;
public without direct attribution where policy permits.

The audience is selected before submission and can be changed only through an authorized process.

Sensitive feedback

Reports involving security, privacy, abuse, discrimination, harassment, payment disputes, personal data, or legal claims must route to appropriate controlled workflows.

They must not be automatically published or summarized into public AI outputs.

Feedback statuses

received → triaged → investigating → linked → decided → closed
                    ↘ needs_information
                    ↘ restricted_case
                    ↘ duplicate

Closed does not necessarily mean implemented.

Triage

Triage records:

product area;
urgency;
potential harm;
affected users;
reproducibility;
available evidence;
security/privacy/legal routing;
duplicate group;
accountable owner;
next action.

Triage must not silently change the original feedback text.

Signal groups

Related feedback may form a Signal Group.

A Signal Group contains:

normalized problem statement;
linked feedback records;
source diversity;
affected cohorts;
frequency estimate;
severity estimate;
current evidence strength;
known bias or sampling limitations;
owner;
decision status.

Volume is informative but does not alone determine priority.

Signal quality

Signals should be evaluated across:

frequency;
severity;
strategic alignment;
user diversity;
revenue or cost impact;
accessibility impact;
security and privacy impact;
legal obligation;
evidence quality;
reversibility;
opportunity cost;
network reuse.

A loud customer is not automatically a representative customer.

Requests versus problems

Products should preserve the user’s requested solution while also identifying the underlying problem.

Example:

request: “Add CSV export.”
possible problem: “I need to reconcile transactions in my accounting workflow.”

The decision record may choose a different solution while acknowledging the request.

Roadmap object types

Problem to investigate

A validated or emerging user problem without a committed solution.

Discovery initiative

Research, prototype, or experiment intended to reduce uncertainty.

Delivery initiative

A planned product change with scope and owner.

Reliability or maintenance initiative

Work required for security, accessibility, reliability, compatibility, or technical health.

Protocol adoption

Migration or implementation of a shared ANUKA contract.

Customer commitment

A separately authorized promise with defined terms.

Roadmap states

considering → discovery → planned → in_progress → released → measured
                    ↘ not_planned
                    ↘ paused
                    ↘ superseded

Public roadmap labels must explain uncertainty.

Commitment levels

C0 — Acknowledged

The product confirms receipt or awareness.

No investigation or delivery promise.

C1 — Investigating

The product commits to evaluating the problem.

C2 — Planning intent

The product currently intends to address the problem, subject to review and change.

C3 — Funded delivery commitment

Budget, owner, scope, and acceptance conditions are approved.

C4 — Contractual commitment

A separate authorized contract or order defines delivery obligations, remedies, and parties.

Only C3 and C4 should be described as commitments, and C4 must not be inferred from a roadmap label.

Roadmap decision record

Every material roadmap decision includes:

decision ID;
problem and evidence;
options considered;
strategic context;
affected users;
accessibility, security, privacy, and operational implications;
estimated cost and dependencies;
funding status;
authority;
decision;
commitment level;
review date;
public explanation;
appeal or resubmission path where applicable.

Prioritization

A product may use structured methods, but no formula should replace judgment.

A prioritization profile may include:

user impact;
urgency;
evidence confidence;
reach;
strategic fit;
revenue or cost;
risk reduction;
accessibility benefit;
network reuse;
effort;
reversibility;
dependency readiness.

The exact weights and limitations should be visible to decision makers.

Votes and reactions

Votes are preference signals, not identity, payment, authority, or consent.

Controls may include:

one vote per eligible account;
organization-weighted views separated from individual views;
fraud and duplicate detection;
declared cohort filters;
visibility of sample size;
no implication that the top-voted item will ship.

Token ownership must not determine access to basic feedback rights.

Customer-specific commitments

Enterprise or strategic commitments require:

authorized parties;
scope;
dependencies;
timeline;
acceptance;
change control;
pricing;
support;
remedies;
data and security terms;
productization or exclusivity rules;
roadmap disclosure policy.

Sales notes or chat messages must not silently create product obligations.

Accessibility feedback

Accessibility reports receive:

direct acknowledgement;
barrier classification;
affected assistive technology or interaction;
severity;
workaround where safe;
remediation owner;
target state;
testing with affected users where practical.

Accessibility requests should not compete solely on vote count.

Security reports

Potential vulnerabilities route to the vulnerability disclosure process.

Public roadmap systems must not expose exploit details before remediation and coordinated disclosure.

AI-assisted feedback analysis

Agents may:

classify themes;
suggest duplicate groups;
summarize selected feedback;
extract candidate problems;
identify missing evidence;
draft response options.

Agents must not:

publish private feedback without permission;
infer sensitive traits without approved purpose;
convert sentiment into a universal user score;
silently delete minority reports;
make final high-impact roadmap decisions;
invent supporting quotes or evidence.

Human owners review material summaries.

Feedback provenance

Summaries should retain links to source records and indicate:

number of records;
date range;
channels;
cohort limitations;
language coverage;
excluded sensitive cases;
whether the summary was AI-assisted;
reviewer.

Response expectations

Products should publish realistic expectations such as:

security reports: immediate controlled intake;
payment or access failures: support severity process;
accessibility barriers: acknowledgement and triage target;
ordinary feedback: acknowledgement without guaranteed individual response;
roadmap proposals: periodic review cadence.

Do not promise individual responses when the product cannot sustain them.

Public decision explanations

A good explanation states:

what was heard;
what evidence mattered;
what decision was made;
what was not decided;
important constraints;
current commitment level;
how the decision may be revisited.

A “not planned” decision can be respectful and useful when it is honest.

Feedback closure

Closure reasons include:

delivered;
experiment completed;
solved differently;
duplicate;
unsupported use case;
insufficient evidence;
not aligned;
unacceptable risk;
legal or policy restriction;
product deprecated;
submitter withdrew;
superseded.

Closure does not erase the historical record.

Communication of changes

When roadmap intent changes, affected sponsors or contracted customers receive communication according to their terms.

Public roadmap changes should include:

changed state;
reason;
impact;
replacement plan if any;
refund or contract process where applicable;
review date.

Feedback portability

Participants should be able to export feedback they submitted, subject to third-party privacy and legal restrictions.

Products exiting ANUKA should preserve or transfer feedback according to declared policy rather than abandoning it in an inaccessible system.

Abuse and manipulation

Controls include:

spam filtering;
rate limiting;
coordinated-vote detection;
disclosure of paid or affiliated advocacy where relevant;
protection against retaliation;
moderation and appeal;
separation of security reports from public debate;
no purchase of hidden priority.

Commercial influence must be explicit.

Metrics

Useful measures include:

acknowledgement time;
triage time;
unresolved high-severity signals;
percentage linked to decisions;
accessibility resolution time;
roadmap decision age;
sponsor refund rate;
reopened issues;
feedback source diversity;
percentage of public commitments with current status.

Avoid optimizing for total feedback volume alone.

Anti-patterns

calling votes democracy;
promising every requested feature;
using a roadmap as a sales contract;
deleting rejected feedback;
publishing private feedback by default;
prioritizing accessibility only by popularity;
hiding sponsored influence;
using AI summaries without source links;
changing commitment levels silently;
rewarding teams for closing feedback records rather than resolving problems.

MVP acceptance criteria

feedback objects have audience and publication consent;
sensitive cases route to controlled workflows;
signal groups preserve source links;
roadmap states and commitment levels are distinct;
every material decision has an owner and explanation;
votes are labeled as signals;
sponsored features link to campaign terms;
accessibility and security feedback have dedicated routes;
AI summaries disclose provenance and review;
public commitments show current status;
feedback export and exit behavior are defined.

Verification record

Protocol review date: 2 August 2026
Public roadmap as contract: Prohibited unless separately authorized
Paid influence disclosure: Required
Human roadmap authority: Required