Plan with Initiatives and compare competitors

• The Validation Tree connects customer or experiment Feedback through Evidence and Problems to an Initiative. Open details in place, and follow completed Changes to their impacted Capabilities.
• Goal directions can start from the title, capabilities and workspace strategy before Problems are linked. Suggestions need confirmation. Intent and custom goal drafts stay editable, and phase changes persist in the board and workspace.
• Archive an Initiative without changing its lifecycle phase or losing Problems, evidence and Decision history. Restore it later, or use Include archived within the chosen Open, Closed or All view. Agent searches include archived records by default.
• Forward actions and relationship pickers remain accessible across Brief and Technical tabs.

Linked Changes can also be checked against a Problem's active evidence, with an explanation for each chunk. Adopt the proof note into the closure dialog, or verify open Problems in an Initiative's closure checklist. Fully verified Problems are selected and proof notes enter the conclusion. The user still confirms the closure.

The Feedback lifecycle safeguards were verified in DEV. Deleting Feedback that supplies a Problem's last active evidence closes that Problem as obsolete while retaining its history. Another active source keeps it open. Deleted Feedback retains its prior lifecycle state, and customer close, duplicate and delete events are prevented from sending resolved emails.

Analysis shows phases, elapsed time and discovered pages. It can resume after a refresh or be cancelled and restarted. The report handles structured proof points and differentiators, and its database setup was applied to staging.

• Website scans preserve dated snapshots. Their pitch separates the vendor's description from Our read and Against us. The brief includes source citations, product-model descriptions and waitlist recognition, with a full-page reading view.
• Literal value proposition quotes are checked against website text. Unverified claims remain visible. Dead domains, temporary failures and bot protection have distinct scan outcomes, while stalled scans become eligible for recovery after 15 minutes.
• The scan card shows live milestones and an expandable step history. This progress update was applied to staging.
• Actual assessment dates drive the Map and its comparison paths. Contours and 3D relief use the full selected snapshot, so search does not change the terrain or measured positions.
• Camera state survives theme, filter and elevation changes. Marker and plate customization is retained, and dense maps can omit labels while leaving every marker inspectable. Clearing a comparison date stays cleared across view changes and reloads.

• Campaign tools enroll members, log touchpoints and update stages or next actions with contacts:write. Configured stages are discoverable, full history can be paged, and duplicate enrollment is reported. Stage changes derive status when omitted, while next-action edits preserve exclusions.
• campaign_interaction_delete removes automation-created touchpoints only. Human-created touchpoints remain protected from MCP deletion. Authorized members can remove a mistaken timeline touchpoint in the app after confirmation. The Campaign database contracts were verified on staging and require coordinated app/MCP deployment.
• Competitor tools search assessments and risks, inspect profiles and update competitor records. Read and write tools are each disabled by default. Writes need competitors:write, while rubric changes need an admin and a separate switch. The database access and relationship corrections were verified on staging and production.
• initiative_create and initiative_update apply changes directly with initiatives:write and an admin or member role. Initiative context and write tools are disabled by default, and the companion contracts were applied to DEV. Creation is not idempotent and accepts up to 50 linked Problems. Updates accept up to 50 additions and 50 removals. They do not close Initiatives. Separate verification proposals require a default-off feature and proposal_requests:create, which the app consent flow does not grant.