FeedbackFlow System Design#

Feedback is essential to keep the balance of dynamic systems long term.

Hence, Feedback is essential for any life, which is a dynamic balance.

Hence, when the Feedback Flow ends, life dies.

—LLoL

This page documents the design, rationale, and open questions of the email-based FeedbackFlow (FF) system used on Balospe.com. For a beginner-friendly introduction, see the FF overview.

The challenge of scalable feedback#

Integrating feedback where it matters most is where datageddon nightmares begin — myriads of questions about how to sort the impact of ideas for further action.

Wikipedia has demonstrated the importance and power of quickly integrating feedback where it matters most across complex websites. Limits of growth are often defined by the (in)ability of systems to integrate diverse feedback appropriately.

Some aspects of a complex world are simply complicated to explain and need the combined effort of writers AND readers to establish working Knowledge Pipeline Refineries (KPRs) — feedback loops where content is continuously refined by those who produce it and those who consume it. FeedbackFlow is designed to help build such KPRs across Balospe.com.

There exists currently no system, AI included, that can handle such intense feedback flows without losing some valuable insights to random circumstances that should not matter. Improving feedback flows is therefore essential for the ResearchCity vision presented here.

The POST-based FF vision#

To facilitate information integration at such a large scale, LLoL has been developing FeedbackFlows for the Evolvix POST System in order to aid the efficient self-stabilizing of diverse innovation-driven projects.

POST stands for the POST System.

To reduce idiosyncrasy in projects, the POST system uses all letters of the alphabet to classify recurrent tasks in projects by defining efficient “double-caps names” like FeedbackFlow. Such a reduction in avoidable and useless complexity is essential if ResearchCity is to win in the war against general confusion about data in our current global datageddon.

For the ReviewedRelease RRv1 description of the Evolvix POST system see the last section of the supporting information in Loewe et al. 2017 (Annals of the New York Academy of Sciences).

This is still the best public introduction to the Evolvix POST System, except it is now somewhat out of date from missing essential updates to key features to be included in the upcoming POST release RRv2. Examples include a rather confusing naming bug and the lack of a proper description of the Jubilee System, without which any vision of true long-term backwards compatibility and lasting long-term self-stabilizing are essentially reduced to castles in the sky.

Email-based FF as implemented for Balospe.com#

FeedbackFlow for Balospe.com is a lightweight way to route reader feedback to where it belongs, so that improvements can be aggregated efficiently. Here is how it works:

Readers who wish to comment already know what they want to comment on. Often they already have the webpage right in front of them. If there is an easy way to include that web-location along with the comment, it becomes much easier to aggregate feedback for particular pages automatically. Once all the feedback for a given page is collected, it becomes much more efficient to update and refine it accordingly.

There is of course no shortage of complex, database-driven solutions for this problem. The challenge is to do it with the least amount of technical overhead upfront, in order to allow such a system to grow organically along with a project from the start.

Hence, the following email-based solution is implemented here in order to collect more experiences with how to best organize FF in real-world systems.

How it works#

It requires:

A web domain like balospe.com for hosting pages that would benefit from FeedbackFlow.
A basic email address that serves as the inbox for all FeedbackFlow, such as FF@balospe.com.
An easy way to include a general FF intro at the bottom of every webpage or FF unit.
An easy way to configure a specific FF mailto link for every FF unit.
Specifically configured email addresses for every FF unit, using the + syntax for email addresses and other useful defaults:
- mailto:FF+<page-slug>@balospe.com
- For example, this link ( mailto:FF+path_to_FF_unit@balospe.com ) pre-configures the other mailto details in potentially useful ways as follows:
  - CC to FF+CompleteFeedbackFlow@balospe.com to collect all FF emails in one stream for team review and system integration.
  - Subject default defined in ways useful for broader POST System AIMS processing, such as FF k2 s2 AIMS for [path_to_FF_unit] Replace_by_OneLineSummary_of_proposed_FF_improvement, where k2 and s2 are the default AIMS classifications (see below).
  - A useful body for helping to focus FF on life-trifectas that matter most, such as “To make this page more gentle kind reasonable for beginners, producers, andOr experts with a background in xyz, please consider improving this:”
  - The sender is informed on the FF guide that submissions are treated as public domain under the Jonah License unless they request otherwise.

AIMS priority classification#

Every FF email subject contains two codes that help sort feedback by importance and urgency:

k (Impact Kicks) — how important the feedback is (k0..k9)
s (Speedup Seasoning) — how urgently it should be addressed (s0..s9)

The default is k2 s2, which signals medium-low priority and a mid-term timescale. This default is deliberate: untuned submissions do not crowd out thoughtful, urgent contributions.

Before adjusting them, please realize that what matters most may not be urgent, and what feels urgent may not matter most. If you want to help pre-sort FFs, tune either to what you believe to the best of your ability to tell is the impact and urgency of your submission. Let Reality be your guide.

Quick guide for casual users:

Most contributors can leave k2 s2 unchanged. If you want to adjust:

More important or urgent? Change k2 to k3 and s2 to s3.
Less important or less urgent? Change k2 to k1 and s2 to s1.

That’s all most people need to know.

For advanced contributors:

The full 10-level scales (k0..k9, s0..s9) are defined in the Iron Rod System, which is designed to disentangle importance and urgency of tasks in causal networks from smallest to world-saving. The scales are part of the broader AIMS framework that underpins ResearchCity’s task management.

Anyone is free to classify or misclassify tasks — yet all others remain free to point out such AIMS errors. The system is tuned to reward reliable AIMS data for serving common interests, so it is in everyone’s best interest to avoid provably careless classification errors.

The rather slow default timescale (s2 = MidTermFocus) implies that FF from those who don’t adjust the defaults will not crowd out thoughtful submissions that are more urgent and more important.

Assessment#

Advantages:

Only a simple static website using reST suffices to allow thoughtful citizens to contribute in meaningful ways.
Minimal up-front cost for setting this up allows starting immediately.
There is no limit to the complexity this system can grow into if needed.
Scalability of post-processing: start with manual sorting in a simple email client for occasional feedback, then add automated sorting solutions to pre-process feedback as volume grows.

Disadvantages:

There is no limit to the avoidable complexity this system can accumulate unless maintained in a thoughtful and controlled way.

Overall assessment:

The pros and cons of this system are the same: it is incredibly flexible and powerful for serving an extremely broad set of FF use cases. However, this extreme flexibility requires that its users bring to its use the self-control required to keep data organized, a task elsewhere enforced by database designs.

The 64-character slug limit#

RFC 5321 limits email local parts (before @) to 64 characters. With FF+ taking 3 characters, the page slug in FF+<slug>@balospe.com can be at most 61 characters.

For most pages this is not a problem — slugs like ff-system (9 chars) or action-jobs (11 chars) fit easily. However, llog files with long dated filenames produce full path-based slugs of 72 to 101 characters — well beyond the limit.

Current workaround: When the full slug exceeds 61 characters, it is abbreviated to the first 50 characters plus a 10-character MD5 hash suffix (slug[:50] + "_" + md5(full_slug)[:10]), producing exactly 61 characters. The abbreviation is deterministic (same page always gets the same short slug) and collision-resistant (10 hex chars = ~1 trillion possibilities). All abbreviated slugs are tracked in a registry. The full source path is always included in the email body regardless of slug length, so feedback can always be traced to its page.

This is a workaround. A proper solution (programmatic slug generation during the build) is deferred until the tooling supports it.

Open questions#

Whether it is possible to provide useful POST System standards, e.g. as the AIMS scales do for importance and urgency, such that enough useful FF productivity can be achieved remains to be seen. If not designed with enough care or if too complex to use, error rates due to misclassifications can make it practically unusable. If complexity of using this is too high it will severely limit the FF from those parts of the audience which struggle with more complex information layouts. How such a system might compare in real-world use to other systems that have higher up-front IT costs for setting them up is currently impossible to tell without trying it out.

Given LLoL’s prior experience with a similar scalability problem (in the context of the evolution@home project that he created), it may take a few years of experience of using this to learn of its strengths and weaknesses, and then a bit longer to finalize a peer-reviewed publication to report all insights (such as this 2007 paper did for evolution@home: see doi:10.1002/spe.806). Needless to say, these timelines can be much accelerated if sufficient buy-in for ResearchCity will enable the use of big-tech efficiencies of scale.

Scaling roadmap#

The FF system is designed to grow in stages. Each stage is triggered by volume, not planned in advance — there is no reason to build stage 3 infrastructure while stage 1 is sufficient.

Stage 1: Volleyball triage (current)

Volume: up to ~50 emails per week.

The email-based system with challenge-response (PUBLICIZE / PRIVATIZE) handles spam filtering, legal consent, and basic prioritization. LLoL monitors two Gmail labels (ff-public and ff-private) and processes feedback as capacity allows. Auto-labeling by site section (parsed from the +slug in the email address) provides filtered views at zero extra cost.

Stage 2: Weekly digest

Volume: ~50–200 emails per week.

An automated weekly summary counts new public submissions per site section and highlights those with external links. This lets LLoL scan volume and prioritize without opening every thread.

Stage 3: Delegated triage

Volume: ~200–1000 emails per week.

When the first volunteers join, Google Workspace’s inbox delegation feature allows them to read and triage ff-public threads. They add sub-labels, flag duplicates, and escalate high-quality submissions. LLoL only reads what is escalated. No new infrastructure — just Gmail delegation.

Stage 4: Public issue tracker

Volume: ~1000+ emails per week.

At this volume, email stops working for deduplication, threading, and community input. Confirmed public submissions are auto-posted to a public issue tracker (e.g., self-hosted GitLab or Forgejo). Volunteers triage in the tracker. Community voting and reactions enable prioritization. The FF Archive activates as a curated public record.

Stage 5: ResearchCity-scale

Volume: 10,000+ submissions per week.

Custom infrastructure: a dedicated FF processing pipeline with AI-assisted deduplication and summarization, distributed review teams per section, public dashboards, and integration with the full POST System AIMS framework. This is the long-term vision — but it is step 5, not step 1.

Each transition preserves everything from the previous stage. Emails are never lost. Labels carry forward. The AIMS classifications (k0..k9, s0..s9) work identically whether the backend is a Gmail inbox or a ResearchCity cluster.

Anticipated use and plea for patience#

Note that Balospe.com is currently set up by one person, LLoL, on a shoestring budget. Hence the plea for patience with processing feedback.

Given the magnitude and global scope of the discoveries reported, it is unlikely that LLoL will be able to respond quickly to most of the feedback anticipated once the discoveries are actually understood.

The vision driving this website is to set up an efficient big-tech organization that will be able to leverage efficiency of scale in sorting complex FF while minimizing the arbitrary loss of ideas due to oversimplifying, overcomplicating, or overreaching in how feedback is written, classified, forwarded, and processed.

Therefore, please, let everyone provide all the feedback everyone wants to provide! Please remember to be gentle kind reasonable in order to serve Reality by improving the various webpages on this site in Reality.

LLoL will do what he can to incorporate feedback while working alone.

As the buy-in of people worldwide increases, he will look forward to employing a coalition of the willing to help with that work. Ultimately, ResearchCity is an extension of the vision to provide efficient feedback for all decision-makers on Earth to gentle kind reasonably encourage life-giving decision-making worldwide for everyone.

The vision of saving life on Earth deserves no less.