Open Arsenal

See the stars

Resolva Specification

Home / Resolva / Resolva Specification

Resolva

Collective Intelligence for Real Change.

Purpose

Resolva is an open-source AI platform for transforming complaints, frustrations, problems, and unmet needs into structured solutions and alternative system designs.

Resolva combines artificial intelligence, collective intelligence, community collaboration, and open-source development to create a continuous problem-solving process.

The platform is designed around the principle that complaints are valuable signals. A complaint identifies something that is not working, while Resolva provides the tools to understand why it is not working and explore what could work better.

Core Principles

  • Transform complaints into actionable problem statements.
  • Use AI to identify patterns, root causes, and possible solutions.
  • Provide multiple solutions rather than assuming there is only one correct answer.
  • Allow communities to evaluate, refine, and prioritize proposed solutions.
  • Enable developers to turn accepted solutions into implementations.
  • Support alternative versions, forks, and experimental designs.
  • Preserve transparency throughout the problem-solving process.
  • Protect users submitting sensitive or potentially identifying information.
  • Support local-first and self-hosted deployments where practical.
  • Avoid unnecessary vendor lock-in.
  • Maintain an open-source foundation under the AGPL-3.0+ license.
  • Preserve required attribution to Roxanne Ardary and roxanneardary.com.

Core Modules

Complaint Intake Module

The Complaint Intake Module provides the primary interface for submitting problems, frustrations, concerns, bugs, and requests for change.

The module should support:

  • Free-form complaint submission.
  • Structured complaint forms.
  • Feature and system identification.
  • Severity classification.
  • Expected versus actual behavior.
  • Supporting descriptions.
  • Screenshots and evidence.
  • Optional technical information.
  • Anonymous or pseudonymous submissions where configured.
  • Duplicate detection.
  • Complaint status tracking.

The module should allow users to describe problems naturally without requiring technical knowledge.

Complaint Interpretation Module

The Complaint Interpretation Module uses AI to convert unstructured complaints into structured problem descriptions.

The module should identify:

  • Primary problem.
  • Affected feature or system.
  • User intent.
  • Expected outcome.
  • Observed outcome.
  • Potential contributing factors.
  • Problem category.
  • Severity.
  • User impact.
  • Possible ambiguities requiring clarification.

The system should preserve the original complaint alongside the AI interpretation.

Root Cause Analysis Module

The Root Cause Analysis Module analyzes reported problems beyond their immediate symptoms.

The module should identify potential:

  • Technical causes.
  • Design causes.
  • Workflow problems.
  • Usability problems.
  • Policy limitations.
  • Architectural limitations.
  • Process failures.
  • Communication failures.
  • Accessibility barriers.
  • Security or privacy concerns.

AI-generated root cause assessments should be presented as possibilities rather than established facts unless verified by evidence.

Complaint Clustering Module

The Complaint Clustering Module groups related complaints into larger problem areas.

The module should:

  • Detect duplicate complaints.
  • Identify semantic similarities.
  • Create problem clusters.
  • Track cluster growth.
  • Identify recurring problems.
  • Identify affected features.
  • Measure complaint frequency.
  • Detect emerging problem patterns.

Clusters should provide a consolidated view without preventing individual users from retaining their original reports.

Problem Prioritization Module

The Problem Prioritization Module helps communities and project maintainers determine which problems should receive attention first.

Prioritization may consider:

  • Number of affected users.
  • Severity.
  • Frequency.
  • Safety implications.
  • Accessibility impact.
  • Privacy implications.
  • Security implications.
  • Development difficulty.
  • Community voting.
  • Reported business or operational impact.
  • Time unresolved.

Prioritization should remain configurable so different projects can use different criteria.

Solution Generation Module

The Solution Generation Module uses AI to generate multiple potential responses to a problem.

Solutions may include:

  • Minimal fixes.
  • Configuration changes.
  • Interface redesigns.
  • Workflow changes.
  • Architectural changes.
  • Alternative features.
  • Replacement systems.
  • New implementation strategies.

Each proposed solution should explain:

  • What changes.
  • What problem it addresses.
  • Expected benefits.
  • Potential disadvantages.
  • Estimated complexity.
  • Potential dependencies.
  • Possible unintended consequences.

The system should avoid presenting a single AI-generated solution as the definitive answer.

Alternative Version Module

The Alternative Version Module allows users and communities to explore different versions of a system based on proposed solutions.

An alternative version may represent:

  • A different user interface.
  • A different workflow.
  • A different feature configuration.
  • A different business model.
  • A different technical architecture.
  • A different moderation model.
  • A different privacy model.
  • A substantially different product direction.

Alternative versions should remain connected to the original problem and clearly document the changes being proposed.

AI Prototype Module

The AI Prototype Module converts solution proposals into preliminary implementation concepts.

The module may generate:

  • Wireframes.
  • Interface concepts.
  • User flows.
  • Feature specifications.
  • API concepts.
  • Data models.
  • Database changes.
  • Technical implementation plans.
  • Testing requirements.

Generated prototypes should be treated as proposals requiring human review.

Fork Planning Module

The Fork Planning Module helps developers create structured plans for alternative versions or forks.

The module should support:

  • Fork objectives.
  • Feature differences.
  • Architecture differences.
  • Configuration changes.
  • Migration requirements.
  • Compatibility considerations.
  • Implementation milestones.
  • Documentation requirements.

The module should distinguish between conceptual alternatives and actual software forks.

Community Voting Module

The Community Voting Module allows participants to evaluate problems and proposed solutions.

Voting may support:

  • Support.
  • Opposition.
  • Needs revision.
  • Priority ranking.
  • Solution comparison.

Projects should be able to configure voting rules, eligibility, weighting, and expiration periods.

Structured Discussion Module

The Structured Discussion Module provides focused collaboration around complaints, problem clusters, and proposed solutions.

Discussions should support:

  • Comments.
  • Replies.
  • Evidence.
  • Technical arguments.
  • Proposed modifications.
  • Questions.
  • Consensus indicators.
  • Moderation actions.

Discussions should remain associated with the problem or proposal that generated them.

Developer Implementation Module

The Developer Implementation Module connects accepted proposals with actual development work.

The module should support:

  • Developer assignment.
  • Implementation proposals.
  • Development status.
  • Pull request references.
  • Testing status.
  • Review status.
  • Release status.
  • Completion verification.

Implementations should remain traceable to the original complaint and proposed solution.

Satisfaction Measurement Module

The Satisfaction Measurement Module evaluates whether implemented solutions actually improve the reported problem.

The module should support:

  • Before-and-after satisfaction measurements.
  • User feedback.
  • Resolution ratings.
  • Regression reporting.
  • Follow-up complaints.
  • Resolution effectiveness metrics.

A problem should not automatically be considered solved merely because a code change has been implemented.

Reputation Module

The Reputation Module measures the quality and usefulness of community participation.

Reputation may be influenced by:

  • Accurate problem reports.
  • Useful evidence.
  • Successful solutions.
  • Helpful technical contributions.
  • Constructive discussions.
  • Validated implementations.
  • Community evaluations.

Reputation should not become a substitute for evidence or expertise.

Bounty Module

The Bounty Module allows communities or organizations to attach financial or non-financial rewards to unresolved problems.

The module may support:

  • Problem bounties.
  • Feature bounties.
  • Solution bounties.
  • Implementation rewards.
  • Community-funded rewards.
  • Completion verification.

Financial functionality should remain optional.

Transparency Module

The Transparency Module provides public visibility into problems and their resolution status.

It should support:

  • Public problem dashboards.
  • Open problem counts.
  • Resolution statistics.
  • Problem histories.
  • Proposal histories.
  • Implementation histories.
  • Community participation metrics.

Projects should be able to determine which information is public and which information must remain private.

Dissatisfaction Analysis Module

The Dissatisfaction Analysis Module provides aggregated analysis of user frustration.

It may identify:

  • Most problematic features.
  • Increasing complaint categories.
  • Persistent problems.
  • High-impact problems.
  • Unresolved problem clusters.
  • Satisfaction changes over time.

The module should use aggregated information where appropriate to protect individual users.

Solution Library Module

The Solution Library Module stores resolved problems, successful solutions, implementation patterns, and reusable approaches.

Solutions should be searchable by:

  • Problem type.
  • Feature.
  • Technology.
  • Industry.
  • Solution category.
  • Implementation method.
  • Outcome.

The library should allow developers to learn from previously solved problems without requiring them to repeat the same analysis.

Ethical Impact Module

The Ethical Impact Module analyzes proposed solutions for potential risks.

It may evaluate:

  • Privacy.
  • Security.
  • Accessibility.
  • Manipulation.
  • Surveillance.
  • Discrimination.
  • Exclusion.
  • Addiction-oriented design.
  • Unintended social effects.

AI assessments should be advisory and subject to human review.

Privacy and Secure Reporting Module

The Privacy and Secure Reporting Module provides protections for sensitive complaints.

Depending on deployment configuration, it may support:

  • Anonymous submissions.
  • Pseudonymous accounts.
  • Encrypted complaint storage.
  • Access controls.
  • Evidence protection.
  • Sensitive complaint classification.
  • Restricted review workflows.

Privacy-sensitive information should not be exposed through public dashboards or AI-generated summaries without appropriate authorization.

Civic Systems Module

The Civic Systems Module adapts Resolva for public services and community infrastructure.

It may support complaints and proposed improvements involving:

  • Government websites.
  • Public services.
  • Municipal systems.
  • Community infrastructure.
  • Public information systems.
  • Accessibility services.

The module should provide stronger transparency and accountability controls where appropriate.

AI Governance Module

The AI Governance Module manages how artificial intelligence is used throughout Resolva.

It should support:

  • Model selection.
  • Model configuration.
  • Prompt management.
  • AI output review.
  • Human approval.
  • AI confidence indicators.
  • Model activity logging.
  • Provider independence.
  • Local model support.

AI should assist decision-making rather than silently make consequential decisions on behalf of users or communities.

Provenance Module

The Provenance Module maintains relationships between complaints, analyses, solutions, votes, implementations, and outcomes.

The system should allow users to trace:

Complaint → Analysis → Root Cause → Solution → Proposal → Implementation → Outcome

This creates an auditable history of how problems became changes.

Optional Plugin Modules

Local AI Plugin

Provides integration with locally hosted AI models.

Potential integrations may include local inference servers and self-hosted model runtimes.

External AI Provider Plugin

Provides optional integration with external AI providers.

The core platform should not require a single commercial AI provider.

Vector Search Plugin

Provides semantic search and vector-based similarity capabilities for complaint clustering and solution discovery.

Git Integration Plugin

Connects Resolva proposals and implementation records with Git repositories and development workflows.

Codeberg Integration Plugin

Provides optional integration with Codeberg repositories, issues, pull requests, and project activity.

GitHub Integration Plugin

Provides optional integration with GitHub repositories and development workflows.

GitLab Integration Plugin

Provides optional integration with GitLab repositories and development workflows.

Notification Plugin

Provides optional email, web, mobile, or other notification systems.

Authentication Plugin

Provides optional integrations with external identity providers and authentication systems.

Payment Plugin

Provides optional support for bounties, donations, contributor rewards, and other financial transactions.

Visualization Plugin

Provides dashboards, charts, problem maps, dissatisfaction heat maps, and solution analytics.

Moderation Plugin

Provides configurable automated and human moderation capabilities.

Evidence Storage Plugin

Provides optional external or distributed storage for screenshots, documents, logs, and other supporting evidence.

Analytics Plugin

Provides advanced analytics for complaint trends, resolution rates, participation, and satisfaction.

Federation Plugin

Allows independent Resolva instances to exchange selected complaints, solutions, proposals, or knowledge while maintaining local control.

Civic Integration Plugin

Provides optional integrations with municipal, government, or public-service systems.

Accessibility Plugin

Provides enhanced accessibility analysis and testing capabilities for proposed solutions and interfaces.

Plugin Architecture

Plugins should be optional and modular.

The core system should remain functional without any specific third-party provider or plugin.

Plugins should:

  • Have defined interfaces.
  • Be independently enabled or disabled.
  • Avoid unnecessary coupling to the core.
  • Document external dependencies.
  • Respect user privacy settings.
  • Respect project governance settings.
  • Avoid introducing vendor lock-in.
  • Maintain compatibility with the core platform.

Human Oversight

Resolva should maintain human oversight throughout consequential decision-making processes.

AI-generated:

  • Interpretations.
  • Root cause analyses.
  • Solutions.
  • Prototypes.
  • Ethical assessments.
  • Prioritization recommendations.

should be clearly identified as AI-generated or AI-assisted where appropriate.

Users and authorized project maintainers should be able to review, modify, reject, or replace AI-generated results.

Specification Branding License (SBL)

Standard

Optional

License & Notice Requirements

Resolva is released under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).
By contributing to this project, you agree that your contributions will also be released under this license.

Please note the following:

  • All contributions must comply with the AGPL-3.0+ terms.
  • Under Section 7 of the license, all redistributions, forks, and derivative works must preserve attribution to:
    Roxanne Ardary and roxanneardary.com.
  • Resolva specifications are free to use with attribution. A Specification Branding License can be negotiated upon request.
  • The project’s notice.md file tracks attribution requirements and contributor acknowledgments.
    Any update that adds new contributors or modifies attribution should also update notice.md.
  • When submitting a pull request, ensure that any new files maintain the attribution headers where applicable.
  • Network-deployed versions of this software must also remain fully AGPL-3.0+ compliant, including exposure of source code modifications when applicable under the license.

For full legal details, please refer to the AGPL-3.0+ license and the project’s notice.md file.

Notice – Resolva

Attribution Requirement: Under Section 7 of the AGPL 3.0+ license, all redistributions, forks, and derivative works, including network-deployed versions of this project, must provide attribution to Roxanne Ardary and roxanneardary.com.

Contributors

This file tracks contributors and their specific contributions to the project.

  • Roxanne Ardary, roxanneardary.com – March 16, 2026
    Created the repository for Resolva. Developed the open-source AI platform for transforming complaints into actionable solutions with community and AI-driven features.
  • [Add other contributors here] – [Date]
    [Describe contribution in one sentence]

License – Resolva

This repository is licensed under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).

Key Points:

  • You are free to use, modify, and distribute the code.
  • All redistributions, forks, and derivative works or network-deployed versions must also be licensed under AGPL-3.0+ and provide attribution to Roxanne Ardary and roxanneardary.com as required under Section 7 of the license.
  • The software is provided “as is,” without warranty of any kind.

For the full license text, see GNU AGPL-3.0 License.

Related posts:

EchoCore Memory

CodeIgniter Specification

CovenantAI