After publishing your app, your responsibility does not end. You must track how your app performs in production, interpret user feedback signals, and release improvements when quality falls short.
Your Expert Dashboard provides performance metrics for every published app. These metrics are your primary signal of whether your logic is working as intended in real professional use. Review them regularly — not just after a new release.
Total executions over time. A declining trend after strong initial uptake often indicates a quality problem — users have tried the app and stopped using it.
Percentage of runs that complete without failure. Failed executions are not charged but indicate your app may be producing outputs that fail schema validation or hitting unexpected errors.
Percentage of outputs acknowledged by users without significant modification. A low acceptance rate means users are routinely editing your outputs before they are professional-grade — your logic needs improvement.
How often users re-run the same app with the same or modified inputs on the same task. A high re-run rate indicates users were not satisfied with the first output — they tried again hoping for a better result.
Percentage of completed executions where the output passed result.json validation. Non-conformant outputs are discarded and not charged. A declining conformance rate suggests your output schema or logic has drifted.
How often users reject outputs entirely rather than acknowledge them. Rejections are a strong signal that your app's outputs are not meeting professional requirements for the declared use case.
Users interact with your outputs in three ways. Each interaction type is an aggregated signal visible in your Dashboard. Individual user data is never exposed — you receive anonymised aggregate patterns only.
User acknowledges the output without modification. This is the strongest positive signal — your logic produced an output that required no correction. High acceptance rates are the primary indicator of a well-designed app.
User modifies the output before acknowledging. This indicates the output structure was correct but the content needed adjustment. Isolated edits are normal. A consistent pattern of the same fields being edited points to a specific logic gap you need to address.
User rejects the output entirely. This is a strong negative signal. Rejections mean your app produced an output that could not be made professional-grade even with editing. Investigate the use cases behind rejection patterns.
Every app in Appstream has a Trust Score that determines its ranking and visibility. The Trust Score is computed from your performance metrics and updated continuously. It is not based on promotional activity or manual editorial choices.
Apps that reliably complete executions without error are trusted by the platform and prioritised in results.
Outputs that users acknowledge without modification demonstrate that your logic is meeting professional standards.
Apps that reliably produce schema-conformant outputs demonstrate technical stability and predictability.
Apps that retain and grow their user base signal that they are solving real professional needs effectively.
Consistently edited outputs signal the logic does not produce professional-grade content independently.
Rejected outputs are the clearest indicator that an app is not meeting its declared use case.
Repeated failures reduce trust in the app's reliability and harm its position in search results.
Apps that have known quality problems but receive no update from the Expert are penalised for neglect.
When your metrics indicate a quality problem, you have a professional obligation to investigate and respond. The correct response cycle is:
Use your Dashboard to identify which metric is degrading and at what rate. A rising edit rate in one specific output section points to a logic problem in that area. A rising rejection rate points to a fundamental fit problem between your app's output and professional user needs.
Use your test library to reproduce the likely failure scenario. Run your existing test cases. If they pass, the problem may be in an edge case your test library did not cover — add new test cases that exercise the affected area.
Update the affected ABI contract files in Builder. Common fixes: tighten the result.json schema to remove ambiguity, revise the preset.json workflow steps, or add missing professional caveats to the output.
Run your full test library against the revised version — including the new test cases you added. Do not submit an update you have not verified against all four test types.
Accept the Digital Oath for the new version. This commits you to the accuracy of the revised logic. Submit the update for review. The update follows the same review process as the initial submission.
Every update to your app creates a new version with its own audit chain and oath acceptance. Understanding the versioning model is essential for maintaining your apps responsibly.
When you publish a new version, the previous version remains in the audit record exactly as it was. Users who ran executions against the old version retain an accurate record of which version they used. You cannot modify, correct, or delete old versions.
Each version publication requires a fresh Digital Oath acceptance. The oath is not inherited. If your update changes the logic significantly, take extra care reviewing the new version before accepting the oath.
The version history of your app is visible to users in Appstream. A pattern of frequent small corrections may signal instability. A long gap without updates on an app with known issues signals neglect. Both affect trust.
Version when you have made a meaningful improvement, fixed a documented quality issue, or updated the logic to reflect changed professional standards. Do not publish versions without genuine changes — unnecessary version churn degrades the revision history.
Experts who do not maintain their apps face escalating consequences. The platform monitors quality signals continuously and takes action when standards are not met.
Apps with declining quality metrics are progressively ranked lower in Appstream search results. Reduced visibility leads to reduced usage and revenue.
Apps with persistent quality signals below acceptable thresholds are flagged in Appstream with a quality notice. Users are informed that the app's quality metrics are below platform standards.
Apps that remain below quality thresholds without a corrective update from the Expert are suspended from Appstream pending a governance review. The Expert is notified and given a defined window to respond.
Apps where the Expert has not responded to suspension notice or where the quality failure represents a serious violation of Developer Policies may be permanently removed from Appstream.
Role definition, accountability model, and how Experts fit into the Majormatic platform
Read overview →How to build a test library and validate logic before accepting the Digital Oath
View guide →Quality standards, conduct expectations, and enforcement actions for published apps
View agreement →