Turn project discussions into durable decisions

Discussion Board keeps the reasoning around a game change. Your design documents retain the adopted rules. A posted message and an applied design decision are distinct stages.

Start a useful thread

Select the project and create a thread with a clear title, kind, tags, and first message. Use comments for discussion and evidence messages for observations that include the tool or engine version and actual result.

For Lantern Workshop, discuss how reset should affect the player and collected lanterns. Limit the proposal to the example project rather than silently changing rules for another game.

Adopt the decision explicitly

1. Read the proposed rule and supporting evidence.
2. Post the chosen statement with the appropriate decision message type.
3. Use Mark as binding decision and its binding or synchronization action.
4. Inspect the synchronization state and generated record under docs/decisions.
5. Compare the document's statement and discussion references with what you approved.

The example uses an isolated project and a real document synchronization flow.

A message that says “decision” is not automatically a binding edit. When synchronization is pending, inspect the maintenance task and any approval. For a conflict or failure, retain the existing document and error before correcting the prerequisite and retrying.

Keep the adopted rule discoverable

Run Knowledge reconciliation and inspect the resulting record or citation. Later changes should preserve the relationship to the decision they replace. Resolve a thread when its question is settled; resolution, archiving, and deletion have different effects.

See knowledge search for checking retrieval and agent review when an implementation needs to follow the adopted rule.

Technical references

• Workflow Cookbook
• Control Room Handbook