> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Public feedback and trust surfaces: idea board, community, help center, sub-processor notices

> Frame your organization's unauthenticated feedback and trust surfaces — the hosted idea board, the peer-to-peer community, the public help-center read, and the sub-processor change subscriptions — and the design invariants that keep unauthenticated access bounded.

# Public feedback and trust surfaces: idea board, community, help center, sub-processor notices

Some of what your end users reach for is deliberately **unauthenticated**: a
signed-out visitor can self-serve help content, ask the community a question,
submit a product idea, or subscribe to sub-processor change notices without an
account. Four Orbit surfaces share that posture, and they share one design
contract that bounds it. This page maps the four surfaces and the invariants
that keep them safe — separate from the incident model, which is
[org-scoped status](/concepts/org-scoped-status-model). Read the model once
and configure each surface with the same mental picture of how anonymous
access is constrained.

## Feedback surfaces, not the status model

The [org-scoped status model](/concepts/org-scoped-status-model) owns the
incident feed: declared incidents, per-channel impact projections, and the
white-label status URL you hand to customers. None of that lives here. The
surfaces on this page are **feedback and trust surfaces**: they take input
from your users (ideas, questions, help feedback), or they publish trust
information (help articles, sub-processor notices) — inbound and outbound
respectively, both unauthenticated. A widget-style "was this affected?"
question and a "how do I do X?" question resolve to different surfaces; this
page is the map that keeps you from conflating them.

## Idea board: hosted, opt-in, tenant-scoped

The idea board is a hosted feature-request surface you enable per
organization. Your end users submit product ideas, upvote the ones they
want, comment for context, and read a public roadmap that exposes each idea's
lifecycle (under review, planned, in progress, shipped).

* **Opt-in per tenant.** The board answers only when your organization has
  flipped the idea-board setting on. Until you do, the endpoint behaves like
  a non-existent route, which is also what keeps your surface list private.
* **Tenant scope by org slug.** Requests carry your organization slug in the
  query string, so the board renders only your organization's ideas; an
  unknown slug and a disabled board return the **identical 404**, which means
  a probe cannot enumerate tenants and cannot discover which tenants enabled
  the board.
* **Write bounds.** Reads up to 120 per minute per IP; votes up to 30 per
  minute per IP (votes are idempotent per voter); idea submissions and
  comments up to 5 per minute per IP. Author email and visitor IP are
  HMAC-hashed before they are stored, never persisted raw, and content
  length is capped at the validation layer.
* **Roadmap is operator-side.** A visitor can create ideas, comments, and
  votes only. The status of an idea moves only when an operator moves it; the
  public roadmap is a read projection of that lifecycle, and its shipped
  column doubles as your public changelog.

The roadmap's shipped column surfaces in the JSON API, and the idea's
detail page reads the same lifecycle projection — one source, two views,
so what you see answers what your users saw.

## Community surface and public help-center read

Two more surfaces serve the same signed-out visitor in adjacent ways:

| Surface                           | What it publishes                                                                                   | What anonymous writes allow                                                                             |
| --------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Community** (opt-in per tenant) | Peer-to-peer questions, answers, votes — crowdsourced self-service that deflects tickets            | Ask a question, answer a question, upvote — same rate budget as the idea board, same hashing posture    |
| **Help center** (public read)     | Published help-center articles, category and section taxonomy, full-text search over public content | "Was this helpful?" feedback and unauthenticated ticket submission — capture appetite without a session |

The public help-center read is the self-serve knowledge base: anyone can
browse and search the articles you marked public, which deflects tickets
before they exist. The community sits alongside it: your users answer each
other, which flips the ticket-you-didn't-get into a question someone answered
(publicly) once. Both resolve tenant scope by org slug, both collapse a
disabled or unknown org to the same 404, and both bound anonymous writes
with the same per-IP rate budgets and the same hashing of identifiers.
Feedback and ticket submissions on the help center are one-way: no GET ever
echoes your feedback rows back.

Where the idea board and community overlap, choose deliberately: capture
product feedback on ideas, deflect support on community, and run the help
center as the content both link into.

## Sub-processor subscription surface

The sub-processor subscription surface is a different audience processing
different trust data: instead of your end users handing you feedback, you
(the customer) register for advance notice before the platform adds or
replaces a sub-processor, as most Data Processing Agreements require.

* **Register** an email address or an HTTPS webhook endpoint; the surface
  records a pending row and returns a signed confirmation token keyed to the
  row.
* **Confirm or unsubscribe** with a signed, single-purpose, expiring action token — the same human-readable links carried in the confirmation email. Tokens are verified in constant time, bound to one action and one
  subscription, and survive long enough for an inbox sweep (30 days).
* **Fail closed.** The registration endpoint authenticates against a
  platform-side signing secret; when that secret is unset, the endpoint
  refuses to accept subscriptions rather than record them unconfirmed. A
  re-subscribe is an idempotent upsert on your canonical endpoint, so a
  repeated signup resets the double-opt-in cleanly.

It is invoice-grade process data anyone in the DPA flow may need: this
surface does not require an account because its audience is your legal and
procurement reviewers, not your operators.

## The public-trust design invariants

Five invariants define the whole family. Together they let you explain to
your users exactly how unauthenticated submission is bounded:

1. **Unauthenticated by design.** The visitor is intentionally anonymous;
   no surface on this page asks for an account, API key, or session. Access
   control is not layered on a logged-in assumption, it is structural.
2. **Tenant-existence hidden on failure.** Unknown org slug and disabled
   feature return the identical 404. Enumeration and feature-discovery both
   fail in the same way, which keeps your surface list private.
3. **IP-keyed rate limits.** Each surface budgets anonymous reads, votes,
   and writes per IP at the validation layer, so a browser sees a bound, not
   a throttle guess.
4. **Hashed identifiers, never raw.** Author email and visitor IP are
   HMAC-hashed before persistence; nothing stores them in reversible form.
5. **Zero outbound comms on idea submission.** Submitting an idea, vote, or
   comment triggers no email, SMS, or other outbound channel; the
   sub-processor surface is the one outbound here, and it sends only the
   confirmation email owed to your registrants (outbound messages stay within
   the platform's existing email path).

Something that LOOKS like an unauthenticated write but needs an internal
credential — such as the sub-processor registration endpoint, which
authenticates at the platform edge — is deliberately not counted under this
family; the invariant is "unauthenticated by design," not "unauthenticated
everywhere."

## Cross-links from the map

* [Org-scoped status model](/concepts/org-scoped-status-model) — the incident
  feed; reserved from this page on purpose.
* [Custom domains and managed SSL](/concepts/custom-domains-and-ssl) —
  decides whether your white-label status URL renders under your host; these
  feedback surfaces resolve under whatever host the slug targets.
* [API request guard pipeline](/concepts/api-request-guard-pipeline) — the
  validation and rate-limiting edge these anonymous requests pass through.

## See also

* [Org-scoped status model](/concepts/org-scoped-status-model)
* [Custom domains and managed SSL](/concepts/custom-domains-and-ssl)
* [API request guard pipeline](/concepts/api-request-guard-pipeline)
* [Platform status guide](/guides/status-page) — the end-user walk-through
  for the incident side of the map