Define the public claims, site structure, and simulated demo story #3

New Issue

2026-10-08T17:28:10-04:00

anodyine commented

2026-10-08 17:28:10 -04:00

Problem

The public site needs approved claims and a coherent visitor path before implementation. RelayView #277 and the superseded #278 hold the original product and marketing requirements.

Scope

Review the current RelayView authoritative product and architecture documents. Draft page sections, calls to action, and a short task-to-review demo script. Mark each product claim as verified current behavior, selected direction, planned artifact/capability, or commercial intent. Specify the simulation label and which screenshots or fixtures may be public. Record that this site is a separate repository with no product implementation source.

The brief must identify the primary audience and the concrete problem of supervising agent work across specialized roles, handoffs, checks, and human acceptance. Preserve “See every handoff.” Define the visitor path through hero, problem, workflow, Community, trust/portability, Teams, integrations, proof, and calls to action. Provide approved copy or specific constraints for each section so #4 does not have to invent product positioning. Where proof or integration evidence is absent, specify a truthful planned or omitted state.

Distinguish a complete, free, proprietary Community product for one human operator, including workplace and commercial-project use, from additive Teams capabilities for multiple people and organizations. Explain that the orchestration engine, prompts, context construction, handoff/correction strategies, routing/ranking, and evaluation-derived mechanisms remain proprietary. Do not call Community open source, open core, a trial, or a limited demonstration.

Describe open trust modules and interoperability contracts as selected direction until exact artifacts ship. Intended trust families are sandbox/process/filesystem confinement; credential custody and bounded authenticated operations; command/network-egress enforcement; and independent audit and artifact-integrity verification. A shipped claim needs links to the exact corresponding source, license, dependencies/toolchain, build instructions, tests and conformance fixtures, policy/interface definitions, artifact-correspondence evidence, compatibility/update rules, operator substitution, supported platforms, and assurance limits. Stable workflow-data/export contracts likewise need versioned specifications and conformance evidence before availability claims.

Define separate Community-adoption and Teams-contact journeys, including the owner, destination, and honest pre-release or unavailable state of each call to action. Do not imply that an unavailable download, Teams service, or public trust repository exists. Exclude unsupported pricing, certifications, uptime, customers, integrations, trademark registration, and security assurances.

Acceptance Criteria

Copy leads with “See every handoff” and describes Community, Teams, and open trust boundaries accurately.
The brief identifies the primary audience, concrete problem, section sequence, claim status and source for each substantive claim, and the distinct Community and Teams journeys and CTA states.
The demo script shows customer-visible stages, handoffs, checks, and a human review point, with planned behavior labeled clearly.
Every simulated state is visibly identified as simulated; no model call or product backend is required.
Community is not presented as a trial, limited product, open-source release, or open core. Proprietary mechanisms are not implied to be public.
Planned trust and portability artifacts are labeled planned; claims of shipped artifacts link to the exact publication and assurance evidence above.
A private publication review records which implementation details must stay out of public copy, fixtures, images, and source; the public brief contains only approved claims.
A private disclosure review classifies each customer-visible detail by earliest approved reveal point: pre-release teaser or product release.
The owner approves the exact pre-release copy and demo scope before implementation.
Unsupported price, certification, uptime, customer, integration, and trademark claims are excluded.
Documentation disposition is recorded.

Ablation decision

not_required: site copy and scripted demonstration only.

## Problem The public site needs approved claims and a coherent visitor path before implementation. RelayView [#277](https://tea.kyle-merritt.com/anodyine/relayview/issues/277) and the superseded [#278](https://tea.kyle-merritt.com/anodyine/relayview/issues/278) hold the original product and marketing requirements. ## Scope Review the current RelayView authoritative product and architecture documents. Draft page sections, calls to action, and a short task-to-review demo script. Mark each product claim as verified current behavior, selected direction, planned artifact/capability, or commercial intent. Specify the simulation label and which screenshots or fixtures may be public. Record that this site is a separate repository with no product implementation source. The brief must identify the primary audience and the concrete problem of supervising agent work across specialized roles, handoffs, checks, and human acceptance. Preserve **“See every handoff.”** Define the visitor path through hero, problem, workflow, Community, trust/portability, Teams, integrations, proof, and calls to action. Provide approved copy or specific constraints for each section so #4 does not have to invent product positioning. Where proof or integration evidence is absent, specify a truthful planned or omitted state. Distinguish a complete, free, proprietary Community product for one human operator, including workplace and commercial-project use, from additive Teams capabilities for multiple people and organizations. Explain that the orchestration engine, prompts, context construction, handoff/correction strategies, routing/ranking, and evaluation-derived mechanisms remain proprietary. Do not call Community open source, open core, a trial, or a limited demonstration. Describe open trust modules and interoperability contracts as selected direction until exact artifacts ship. Intended trust families are sandbox/process/filesystem confinement; credential custody and bounded authenticated operations; command/network-egress enforcement; and independent audit and artifact-integrity verification. A shipped claim needs links to the exact corresponding source, license, dependencies/toolchain, build instructions, tests and conformance fixtures, policy/interface definitions, artifact-correspondence evidence, compatibility/update rules, operator substitution, supported platforms, and assurance limits. Stable workflow-data/export contracts likewise need versioned specifications and conformance evidence before availability claims. Define separate Community-adoption and Teams-contact journeys, including the owner, destination, and honest pre-release or unavailable state of each call to action. Do not imply that an unavailable download, Teams service, or public trust repository exists. Exclude unsupported pricing, certifications, uptime, customers, integrations, trademark registration, and security assurances. ## Acceptance Criteria - Copy leads with “See every handoff” and describes Community, Teams, and open trust boundaries accurately. - The brief identifies the primary audience, concrete problem, section sequence, claim status and source for each substantive claim, and the distinct Community and Teams journeys and CTA states. - The demo script shows customer-visible stages, handoffs, checks, and a human review point, with planned behavior labeled clearly. - Every simulated state is visibly identified as simulated; no model call or product backend is required. - Community is not presented as a trial, limited product, open-source release, or open core. Proprietary mechanisms are not implied to be public. - Planned trust and portability artifacts are labeled planned; claims of shipped artifacts link to the exact publication and assurance evidence above. - A private publication review records which implementation details must stay out of public copy, fixtures, images, and source; the public brief contains only approved claims. - A private disclosure review classifies each customer-visible detail by earliest approved reveal point: pre-release teaser or product release. - The owner approves the exact pre-release copy and demo scope before implementation. - Unsupported price, certification, uptime, customer, integration, and trademark claims are excluded. - Documentation disposition is recorded. ## Ablation decision `not_required`: site copy and scripted demonstration only.

anodyine added the status/ready-for-agent type/docs area/docs labels 2026-10-08 17:28:10 -04:00

anodyine referenced this issue

2026-10-08 17:29:51 -04:00

Epic: Launch the public RelayView site and simulated workflow demo #2

anodyine added a new dependency 2026-10-08 17:30:16 -04:00

#2 Epic: Launch the public RelayView site and simulated workflow demo

anodyine added a new dependency 2026-10-08 17:31:15 -04:00

#4 Build the accessible RelayView marketing page

anodyine added a new dependency 2026-10-08 17:31:34 -04:00

#5 Build the scripted interactive RelayView workflow demo

anodyine added status/in-progress and removed status/ready-for-agent labels 2026-10-14 20:36:51 -04:00

anodyine added reference ISSUE-3

2026-10-14 20:36:53 -04:00

anodyine commented

2026-10-14 20:39:07 -04:00

Draft brief in PR: #7 . Private publication and disclosure review: anodyine/relayview#277 (comment) . Documentation disposition: updated. Exact pre-release copy and demo scope await owner approval before issues #4/#5 implement them.

Draft brief in PR: https://tea.kyle-merritt.com/anodyine/relayview-site/pulls/7 . Private publication and disclosure review: https://tea.kyle-merritt.com/anodyine/relayview/issues/277#issuecomment-42305 . Documentation disposition: updated. Exact pre-release copy and demo scope await owner approval before issues #4/#5 implement them.

anodyine added status/review and removed status/in-progress labels 2026-10-14 20:39:12 -04:00

anodyine commented

2026-10-14 21:25:43 -04:00

PR #7 now starts the proposed visitor/demo journey with a goal conversation, human-reviewed issue draft, planned issue publication, and selection for implementation planning. The brief distinguishes current planner-led Chat and existing-issue linkage from unshipped issue creation (#353), and labels the simulated publication step. Private disclosure addendum: anodyine/relayview#277 (comment) . Focused claim/link and diff checks passed on commit 1ef8d60; exact teaser copy and eight-stage demo still await owner approval.

PR #7 now starts the proposed visitor/demo journey with a goal conversation, human-reviewed issue draft, planned issue publication, and selection for implementation planning. The brief distinguishes current planner-led Chat and existing-issue linkage from unshipped issue creation (#353), and labels the simulated publication step. Private disclosure addendum: https://tea.kyle-merritt.com/anodyine/relayview/issues/277#issuecomment-42368 . Focused claim/link and diff checks passed on commit 1ef8d60; exact teaser copy and eight-stage demo still await owner approval.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Blocks

#2 Epic: Launch the public RelayView site and simulated workflow demo

anodyine/relayview-site

#4 Build the accessible RelayView marketing page

anodyine/relayview-site

#5 Build the scripted interactive RelayView workflow demo

anodyine/relayview-site

Reference: anodyine/relayview-site#3