Answer Bundle Contract

An answer bundle is the small package a system returns when another screen, app, or staff tool asks for a reusable answer. It is not just the answer text. The text is the visible part, but the bundle also needs enough context for the consuming interface to decide how to show it, whether to trust it, and where to send a reader who needs more detail.

The simplest answer bundle has six parts. First is the current answer: the short text that can be shown to a customer, staff member, or reader without opening the whole discussion. Second is a stable answer ID. External tools need an anchor that does not change just because the wording improves. Third is a revision number or version marker, so cached screens can tell whether they are still holding the current record.

Fourth is freshness. Freshness should not mean only "newest." Some answers are old because they are stable. Others are new because they were corrected yesterday. A useful bundle can expose both `changed_at` and `reviewed_at`: one tells when the answer actually changed, the other tells when someone checked that it was still valid. That distinction matters for menus, policies, repair instructions, staff routines, and public FAQs.

Fifth is visibility. A reusable answer may be public, staff-only, owner-only, or location-specific. Visibility cannot be an afterthought left to the external UI, because direct API access, search results, related links, and cached bundles can all leak context if the boundary is vague. The bundle should say who it is for before any interface decides how to render it.

Sixth is a source trail. The consuming UI may hide the full discussion, but the platform should still preserve where the answer came from: a Hub Post, a Node, a Wiki page, a comment thread, or a previous routine. Source trails make a short answer less brittle. If someone asks why a menu note changed, why a troubleshooting step is still recommended, or why a staff routine differs between locations, the answer can point back to the record instead of becoming folklore.

A bundle should stay small. It should not include the entire feed, every related comment, or a giant explanation by default. A good shape is: primary answer, version, freshness, visibility, source trail, and a few related records. Deeper material can be fetched only when needed.

This shape is useful because it separates knowledge quality from interface taste. One business may show the answer in a warm customer-facing card. Another may show it in a compact staff console. A third may use it inside a search box. If the bundle is clean, each interface can differ without duplicating the underlying record.

The main rule is simple: an answer bundle should be small enough to reuse and rich enough to trust. If it cannot answer who it is for, when it was checked, and where it came from, it is only text. If it can answer those things, it becomes a stable unit in a larger knowledge system.

Answer Bundle Contract

// COMMENTS

ON THIS PAGE