Jose Montes de Oca
14e6854dfa
Several docs referenced paths and deployment internals that only exist in our authoring workspace, not in this repo. Clean them up so external readers get a self-contained view. - skills/README.md, skills/open-prose/state/README.md: drop `related:` frontmatter entries that pointed outside the repo tree; refer to "OpenProse Cloud" by name instead of an internal path. - skills/open-prose/agent-onboarding.md: replace a 25-line maintainer comment (infra paths, deploy mechanic) with a single link to the canonical rendering at https://openprose.ai/llms-full.txt. This file is served verbatim as llms-full.txt, so the comment was publicly visible but only meaningful to hosting maintainers. - rfcs/004-composite-instantiation.md: drop two pointers to an external design doc — the RFC is already self-contained (Summary, Problem, Proposal, Architecture, Changes, Prior Art). - rfcs/001/002/003: normalize author line to match rfcs/004's format (`Dan B. (OpenProse)`). Docs only — no behavior changes.
3.1 KiB
RFC 002: Feedback Loop Syntax
Status: Proposed Date: 2026-04-08 Author: Dan B. (OpenProse)
Problem
Every customer program we've built includes a previous_feedback: or previous_reports: input that allows the program to incorporate human feedback and improve over time. But the mechanism for actually feeding back is entirely manual — someone reads the output, formulates feedback, and passes it as a string to the next run.
The Prose language has no formal construct for:
- Declaring that a program improves with feedback
- Structuring feedback so it's machine-readable
- Accumulating feedback across runs (feedback history)
- Distinguishing between "adjust this run" and "adjust all future runs"
Scenarios
-
Deal Flow Radar: C.C. replies in Slack "weight consumer AI and creator tools higher." This should persist across all future runs, not just the next one.
-
Anomaly Detective: Ops manager says "Site 4's overnight HVAC is intentional — they run a bakery." This is a permanent exception that should never trigger an alert again.
-
Startup Sourcer: Yingjie says "Runpod is already in our pipeline." This is a one-time exclusion for the current pipeline state.
-
Value Reporter: CEO says "show me quarterly numbers, not weekly." This is a format preference for all future runs.
Proposed Solution
Add a feedback: section to the program contract:
feedback:
- type: preference
description: adjustments to how the program runs (persists across all future runs)
examples: ["weight consumer AI higher", "show quarterly not weekly"]
- type: exception
description: permanent rules (specific items to always include/exclude)
examples: ["Site 4 overnight HVAC is intentional", "exclude Runpod"]
- type: correction
description: one-time fixes (for the next run only)
examples: ["Suno's revenue was wrong, it's $80M not $50M"]
And a feedback_history: file in the run directory that accumulates feedback across runs:
# Feedback History
## Preferences (persist)
- 2026-04-07: "weight consumer AI and creator tools higher" (via Slack reply)
- 2026-04-08: "show quarterly numbers, not weekly" (via email)
## Exceptions (persist)
- 2026-04-07: "Site 4 overnight HVAC is intentional — bakery" (via Slack)
## Corrections (one-time, applied)
- 2026-04-07: "Suno revenue should be $80M" (applied in run radar-20260408-001)
Design Considerations
- Feedback should be storable alongside the program (in the customer repo), not in the runtime
- The VM should automatically load
feedback_history.mdwhen it seesprevious_feedback:in the contract - The Slack reply box in delivery composites should route replies to a feedback ingestion endpoint
- Feedback types help the model decide whether to apply the feedback once or permanently
Impact
prose.md— document feedback section in contractsstate/filesystem.md— define feedback_history.md location and format- Delivery composites — feedback routing from Slack/email replies
- All customer programs with
previous_feedback:inputs benefit automatically