VPP protocol seeks feedback for better chat AI

Prompting
, , , ,
1

I’m sharing VPP, a minimal protocol for recursive chat environments, more akin to traditional ML lifecycles. Its a formalization on a prompting system I’ve been using personally, utilizing second-order cybernetic principles to treat a chat as a recursive environment: general prompting <g>, rough context questioning <q>, output <o>, second-order clarification <c>, with the goal of a desired final output <o_f>. Works in ChatGPT and via API. Looking for testing stories, failure cases, and critiques of the spec.

Header Snippet (copy-ready)

Viable-Prompt Protocol: User sends !<tag> on line 1 (g,q,o,c,o_f,e,e_o) with optional --correct|--incorrect, --minor|--major, and --<tag> (valid with !<o> --correct and !<e>).
I mirror the tag, prepended to my output: <tag>. !<x>→<x>, except !<e> --<tag>→<tag> and !<e_o>→<o>. Non-negotiable: ALWAYS prepend the tag line to EVERY reply.

 

Only the first line is parsed; later bangs are ignored as content.
<g> is concept-only (snippets ok; no full files).
<o> is a realized draft with Assumptions, Citations, Tests when relevant.

 

Loop is flexible: g→q→o→c→…→o_f (any order/length).
After 3 cycles I propose !<e> --<tag> or !<e_o>.

 

Non-negotiable: ALWAYS append the compliance footer line to EVERY reply:
[Version=v1.4 | Tag=<x_n> | Sources=<none|web> | Assumptions=<n> | Cycle=<i>/3 | Locus=<name?>]
Do not add any text outside the tagged content and the footer.

 

Full spec: https://cdn.jsdelivr.net/gh/cbassuarez/viable-prompt-protocol@main/spec/latest/spec.md

Testing instructions

  1. Paste the **Header Snippet** into Custom Instructions (or system).

  2. Send exactly !<q> on **line 1** (no extra text on that line).

  3. You should get a block of questions and the compliance footer line.

vpp_example

Links: please check out the repo at /cbassuarez/viable-prompt-protocol

Here’s the feedback I need

  • Cases where !<tag> includes preface/CTAs instead of questions only.
  • Footer omissions or malformed footer lines. (esp. this)
  • Modifier conflicts (e.g., --correct + --incorrect) that don’t yield a <tag> failure line.
  • Pipeline strictness: acceptance of only --<tag> (rejects bare --tag).
  • Browse/cite behavior when external facts are required (abstain vs. hallucinate).
  • Multi-cycle behavior: surfacing !<e> --tag after 3 unresolved cycles.

license and stuff

  • Code: MIT • Docs & examples: CC BY 4.0
  • PRs welcome for: fixtures (good/bad transcripts), editor snippets, and adoption notes.