Feedbacks Lab
Abstract
A computer-implemented system is described in which the unit of feedback is a specific desired change to an identified product, service or organizational activity. For each change, the system receives individual support signals, separately verifies human uniqueness and the participant's relationship to the object, normalizes wording, groups compatible requests and calculates several demand measures. Economic intentions, including willingness to pay an additional amount, are bound to a specific change version, pricing conditions and an expiry date. This disclosure provides record structures, processing steps, a reproducible calculation example, rules against fraudulent participation, examples and implementation variants.
1 Purpose of disclosure and scope
This text is intended for public disclosure of a technical solution and its variants. The Russian and English versions bearing identifier FL-DEF-2026-10-07-R1 disclose the same technical model. The preparation date does not substitute for the actual date on which the text becomes publicly accessible. The description is not a report of completed trials and does not claim established novelty over all existing systems.
The system can operate through a website, application and application programming interfaces for products, services, plans, companies, institutions, community organizations and individuals' public activities. It provides the recipient with a ranked list of changes requested by participating users and separately identifies changes for which they are willing to pay more. Absence of an additional payment does not exclude a request from demand.
2 Core entities and their technical relationships
The feedback object receives an object_id and a qualifying context: model, version, plan, region, language or service channel. The request recipient has a recipient_id. The object and recipient are distinct, for example a product manufacturer and the retailer responsible for delivery.
A change receives a change_id. Each material modification of its content creates a change_version_id. A user has an internal person_id intended to account for one human and may use multiple sign-in methods. Until human uniqueness is established, the system retains a provisional identifier and reports the corresponding signals separately.
Signal links person_id, object_id, change_version_id and context_key. Evidence stores proof of uniqueness or a relationship to the object. EconomicIntent binds a payment intention to a particular Signal and change_version_id. ClusterMembership links original formulations to a canonical change version. AggregateSnapshot stores a result for a specified period and rule version.
3 Structured change request
Required card fields are the object, an action and the desired outcome. Optional fields include the current situation, change category, context, constraints, deadlines, numerical conditions, acceptance criterion, alternatives, importance and frequency of need. The original text is retained alongside the normalized record.
Example: “Add cancellation of a paid order in the application within ten minutes, provided preparation has not started, with a full refund.” The card stores the action “add cancellation,” the window “10 minutes,” the condition “preparation has not started” and the outcome “full refund.” These conditions participate in request comparison and are not removed when shortening the title.
Free text is accepted only as an input method for populating the structure. A message without a specific change triggers a clarification question and remains a draft. Several independent actions are split into separate cards. The user sees and confirms the resulting formulation before the signal enters aggregates. AI may not independently add deadlines, prices or conditions that the user did not specify.
4 Processing sequence
The system identifies the object and context, determines the participant segment, offers relevant existing changes, structures a new change if needed, checks completeness and stores the user-confirmed version. It then links evidence, receives an economic intention and checks participation eligibility.
The next steps are semantic duplicate search, condition compatibility checks, cluster assignment or creation, removal of repeated participation, weight calculation and aggregate recalculation. The recipient sees the measures and change conditions. Its response and subsequent verification of implementation generate new events in the same system.
A request can be supported through different interfaces, but all interfaces use one server-side registry of participants and signals. Retransmission of an event with the same event_id does not create an additional vote. Updating a record preserves its history rather than adding new support to the old support.
5 Separate verification of a human and use of the object
Authentication establishes access to an account and does not by itself prove human uniqueness. Uniqueness checks may use independent confirmation by a trusted provider, linked sign-in methods, verified contacts and additional checks following anomalies. The system stores the method, source, time, result, scope and validity period of each item of evidence.
Use of the object is verified separately through an order token, subscription verification, a licence, a service-issued one-time code, attendance information or a verified document. Evidence applies only to the specified object, period and role. Buying one product does not establish use of an entire product range. A photograph or screenshot is not automatically equivalent to a verified purchase.
One token or document cannot generate multiple independent purchases without verification. Shared family use can involve distinct real users with distinct roles; user counts and transaction counts are stored separately. Reuse of evidence is detected through a source identifier or a protected fingerprint.
Current users, former users and prospective buyers form separate segments. For a public service or public activity, participation, attendance or another relevant relationship may be verified instead of a purchase. If the recipient controls the evidence source, this is disclosed, and independent verification routes may be used in parallel.
6 Normalization and semantic grouping
The processing module identifies the language, extracts the object, action, outcome and conditions, creates a canonical record and searches for candidates among requests with compatible objects and contexts. A language model, semantic vectors, rules, dictionaries, manual processing or combinations may be used. Changes in different languages can enter one cluster if their meaning and conditions match.
Before merging, the system separately compares negation, numbers, units, deadlines, plans, regions, user categories and constraints. Vector similarity is used to retrieve candidates and does not replace condition checks. “Cancellation only before preparation starts” is not merged with “cancellation at any time.”
One reproducible mode proposes a merge when similarity is at least 0.90 and required fields do not conflict; values from 0.75 up to 0.90 are sent for manual review. This is an example configuration, not a universal threshold. Exact duplicates may be merged automatically. An uncertain case remains separate until resolved.
“Download all lessons” and “download one lesson” belong to one family but occupy different clusters. Opposing requirements are also separated. A merge preserves original identifiers and signals and is reversible. Splitting an incorrectly merged cluster restores prior relationships and triggers recalculation.
After a merge, a shared participant is counted once. Conflicting additional-payment responses require clarification; the system does not automatically select the highest amount. A materially changed requirement receives a new version, and previous support is not transferred without confirmation. Original text, model version and merge decisions are retained in the log.
7 Signal trust and protection against manipulation
A weight is assigned to an individual signal within its context. It considers human uniqueness, the verified relationship to the object, evidence verifiability, freshness and manipulation review results. It does not assess a person's worth and is not automatically transferred across objects.
One implementation uses scores I, U and E between 0 and 1: I represents evidence of uniqueness, U the relationship to the object and E evidence verifiability. The base weight is 0.35 × I + 0.45 × U + 0.20 × E. The final result equals the base weight multiplied by freshness factor A and admissibility factor M, each between 0 and 1. The result is bounded between 0 and 1. With I = 0.8, U = 1.0, E = 0.9, A = 1.0 and M = 0.9, the final weight is 0.819.
These numbers disclose a specific implementation example and are not calibration results. Other weights and a categorical model are possible. The amount of promised additional payment, praise for the recipient and payment for the platform itself do not increase trust. The weight is not treated as a probability that an opinion is true or that a purchase will occur.
A fully deterministic initial mode can assign I = 1 when an independent source confirms uniqueness, I = 0.4 for a verified contact alone and I = 0 without verification; U = 1 for a verified transaction or relevant participation, U = 0.5 for manually checked indirect evidence and U = 0 for a declaration alone; E = 1 for verifiable source confirmation, E = 0.5 for documented manual review and E = 0 otherwise. A = 1 for current evidence and A = 0 after its specified expiry; M = 1 for an eligible signal and M = 0 for other states. These rules make calculation reproducible without a trained model; intermediate fractional scores may be used in an extended implementation.
Checks detect duplicate accounts and evidence, automated mass submissions, unusual action frequency and coordinated fictitious signals. A shared IP address, common invitation channel or simultaneous participation increase does not by itself prove abuse. Genuine collective support is retained following verification.
Signal states include provisional, eligible, under review, excluded, withdrawn and expired. For a disputed campaign, the report presents verified and disputed portions separately and shows ranking sensitivity to excluding the disputed group. A decision has a reason, date and review route; the recipient cannot secretly exclude inconvenient signals.
8 Economic intention for a specific change
The economic record contains intention type, change_version_id, an amount or range, currency, payment period, baseline price, maximum final price, implementation conditions and valid_until. Types include support without additional payment, a one-time additional payment, a recurring additional payment, purchase after implementation, a plan upgrade and subscription retention conditional on implementation.
Zero additional payment, unwillingness to pay, uncertainty and a missing response are distinct values. One-time, monthly and annual amounts are not added without conversion to a comparable horizon. A percentage price increase is converted to money only when the baseline price is known. Different currencies remain separate; conversion records the exchange rate, source and date.
The question specifies the maximum additional amount for the described improvement while the stated conditions remain unchanged. An answer does not constitute acceptance of any price increase. A change to the function, price or offering composition requires fresh confirmation. An expired intention is not counted as current without renewal.
The system distinguishes a declaration, reconfirmation of a precise offer, a conditional waiting list, a separately established financial commitment and an actual purchase. A deposit, payment authorization and completed purchase have different statuses. When no payment module exists, only intentions are collected.
A user may treat payments for several changes as alternatives. To evaluate a bundle, the system asks about joint willingness to pay and the budget constraint. Individual promises are not automatically summed as independent commitments. Support for public and free services may have no economic record.
9 Aggregation and ranking
The aggregator first selects the period, object, context, segment and rule version. It retains one current eligible signal per person for a canonical change in a given context. Provisional and disputed records are reported separately. Human count N and weight sum D are distinct measures.
For a comparable currency and period, declared potential P is the sum of current additional-payment amounts. Weighted potential Pw is the sum of each additional amount multiplied by its signal weight. Both describe the participating group and are not guaranteed revenue. Median, ranges and respondent counts are also calculated. The proportion willing to pay is accompanied by its denominator and the missing-response rate.
For an additional-payment range, lower and upper amounts are aggregated separately; the midpoint is not treated as a price stated by the participant. One composite ranking variant uses the lower bound of Pw and records that choice in the report. Cluster importance is the mean of explicit scores from 1 to 5 across eligible signals; without responses, that component is unavailable.
Ranking modes may use N, D, P, Pw, importance, urgency or retention. One composite example uses 50 percent normalized D, 30 percent normalized Pw and 20 percent normalized importance. Each component is divided by its maximum across comparable clusters. If a component is unavailable, its share is redistributed proportionally among the remaining components; if all are unavailable, no composite rank is calculated.
The report retains components, rules, date and limitations. Implementation costs supplied by the company form a separate analytical layer and do not change supporter counts. Safety and accessibility requirements may have a separate review queue. A voluntary sample is not equated with all customers or the population.
10 Reproducible server processing algorithm
In a minimal implementation, the server uses a relational database, transactions, an event queue and a candidate search module. A uniqueness constraint for active aggregation covers person_id, canonical_change_version_id and context_key. A material version change prevents unconfirmed transfer of support. The textual algorithm below specifies the sequence without restricting the programming language.
receive(event_id, submission)
if event_id already processed: return saved_result
validate_object_and_context(submission)
draft = normalize_to_structured_change(submission)
if required_fields_missing(draft): return clarification
if user_has_not_confirmed(draft): return confirmation_request
evidence = verify_person_and_object_relation(submission)
candidates = find_semantic_candidates(draft)
cluster = resolve_compatible_match_or_create(draft, candidates)
intent = validate_currency_period_conditions_and_expiry(submission)
begin transaction
upsert_one_signal(person_id, cluster.version_id, context_key)
attach_evidence_and_version_bound_intent()
record_status_weight_policy_and_event_id()
enqueue_recalculation(cluster.id)
commit
return saved_resultDuring a merge, affected records are locked, a new membership mapping is created, duplicate counting is removed from aggregation and a recalculation event is recorded. A snapshot is published only after calculation over a consistent dataset. Re-running the recalculation handler must produce the same result for the same data and rule versions.
11 Verification of change implementation
The recipient responds in structured form: under consideration, clarification required, planned, implemented in a specified version or rejected with a reason. The response applies to a specific change. Users confirm whether the desired outcome was achieved; partial implementation remains a separate status.
After implementation, economic intentions are reconfirmed against actual conditions. When data and participant consent are available, promised additional payments are compared with actual purchases or upgrades. Missing purchase data does not establish refusal. A conversion forecast may be provided by a separate module after calibration and does not replace original declarations.
12 Architecture and data protection
System components are the object registry, authentication, evidence service, structuring, semantic search, moderation, trust assessment, manipulation checks, aggregator, recipient dashboard and event log. They can be hosted in one application or separate services. Manual processing uses the same fields and states as automated processing.
Evidence and personal information have separate access permissions. The recipient receives aggregates and permitted de-identified examples. A verification source may return only use status, category and period rather than a full receipt or account details. Public small-group reporting uses a disclosure threshold, such as ten participants, together with a check for the risk of singling out a person.
Where possible, AI receives de-identified text without original evidence documents. Instructions inside user text are treated as data and cannot change service rules or trigger external actions. Model output is schema-validated. Backups, logging and event restoration preserve aggregate integrity and reproducibility.
13 Examples and checks
Change A is supported by 1,000 people, of whom 100 declare an additional payment of 1 US dollar per month. Change B is supported by 300 people, of whom 180 declare 5 US dollars per month. Under compatible conditions, declared potential is 100 and 900 US dollars per month respectively. Prevalence ranking places A higher; economic ranking places B higher. These figures are an illustration, not a study result.
After merging cards with 60 and 50 participants, including 20 shared participants, the unique supporter count is 90 rather than 110. Shared participants' economic intentions are checked for compatibility. If the merge was incorrect, a split restores the membership of original signals.
“Translate the entire course” and “retain the original language and add tooltips” are not merged into one option. Checks also cover negation, different deadlines, equivalent wording across languages, repeated event_id, withdrawn support, a reused receipt, intention expiry and restoration from the log.
14 Implementation variants and disclosed combination
The disclosure covers the sequential relationship between a structured change, user confirmation of meaning, independent evidence of uniqueness and use, contextual trust, compatible request grouping, deduplication of participation, economic intention bound to a particular version, separate demand measures and post-implementation verification.
Variants include trust categories instead of numeric weights, processing without AI, multiple languages, sector-specific registries, internal organizational deployments, different evidence methods and economic records without money collection. Changes may have alternatives and dependencies; mutually exclusive options and bundles require separate confirmation of joint support.
This publication discloses a reproducible model. Private operational data, keys, actual training datasets and additional optimizations are not necessary parts of the described example and are not provided here. The example configurations are not presented as the only implementation method.
15 Author materials and separation of revisions
The author's earlier application RU2021113998A, “Method of increasing the efficiency of the advertising evaluation and correction system using feedback,” was filed on 18 May 2021 and published on 18 November 2022. It contains verification, purchase plans, exclusion of unreliable ratings and collection of improvement ideas. The A designation indicates an application publication and does not establish patent grant. Public copy: https://patents.google.com/patent/RU2021113998A/en
The program “Feedback: diagnosis, rating, correction” was registered on 27 May 2021 under No. 2021618497; application No. 2021617263 was received on 13 May 2021. Its abstract concerns verified assessment of advertising, goods and services. Program registration and the invention application concern different subject matter.
This revision separately discloses the structured desired change as a demand unit, contextual trust, condition-preserving semantic grouping and willingness to pay more for a specific change. These elements do not automatically acquire a 2021 date. The Russian and English versions should be distributed with the same identifier; subsequent textual changes receive a new revision.
