Expert FAQ

An Expert is a domain authority — a professional with genuine expertise in a field such as law, finance, compliance, or research — who builds execution tools on Majormatic. Experts define how professional workflows should be executed. They are accountable for the accuracy and correctness of the logic they design.

The Expert role is distinct from both end users (who execute workflows) and platform engineers (who build the GEOS Kernel infrastructure). Experts sit between these two — they define what happens, the platform enforces how it happens.

No. Experts do not write code. You use Builder — a visual tool that generates the required ABI contract files from your design decisions. You need domain expertise and an ability to think in structured workflows. No programming experience is required.

You will be working with structured JSON concepts, but Builder abstracts this from direct editing. What matters is professional judgment, not technical skill.

Yes. Law firms, accountancy practices, compliance consultancies, and other professional organisations can register as Expert entities on the platform. Individual professionals within an organisation can build and publish apps under the organisation's account, subject to the Developer Terms and the organisation's internal governance.

An Expert is a domain professional who builds and publishes ABI Apps to Appstream using Builder. The Expert role emphasises domain authority and professional accountability — the Expert owns the correctness of the logic they design.

Platform engineers (who build GEOS infrastructure, engines, and internal systems) are a separate internal category. They are not the audience for Appstream.

The Digital Oath is a formal statement of professional responsibility that every Expert must accept before publishing any version of an app to Appstream: "I accept professional responsibility for this execution tool version."

It is not a checkbox formality. Accepting it creates a permanent record in the platform's audit chain and establishes that you have reviewed the logic, verified the outputs, and are prepared to stand behind the app professionally.

Yes. Every new version requires a fresh oath acceptance. The oath is version-specific — it is not inherited from prior versions. This is intentional: each update is an independent accountability event, and you must re-verify your logic with the same rigour you applied when first publishing.

The platform executed your logic correctly — it always does. Professional responsibility for the logic's accuracy rests with you. When you discover an issue, you must:

• Investigate the root cause promptly
• Release a corrected version
• Accept the oath for the corrected version
• Notify platform governance if the issue may have affected users

Prior versions remain in the audit record. They cannot be modified. Users who ran executions against the incorrect version are protected by the platform's immutable audit trail.

Every app is defined by exactly six ABI contract files:

• input.json — what the user provides
• preset.json — the execution structure template
• result.json — the output validation schema
• meta.json — execution metadata and engine binding
• governance.json — governance rules and supervision requirements
• info.json — public-facing app identity and listing metadata

Builder generates these files from your design decisions. You do not edit the files directly in normal Expert workflow.

supervision_required must be set to true in governance.json for any app that produces outputs affecting a user's legal, financial, regulatory, or professional position. This includes:

• Legal documents, opinions, or advice
• Financial calculations or assessments
• Regulatory compliance outputs
• Any output a professional will act on without independent verification

If you are uncertain, set it to true. Setting it to false when the output carries professional risk is a policy violation that will result in rejection during review.

No. Model selection is determined by the platform based on your engine binding and the SSOT configuration. You declare which Primary Engine your app uses (in meta.json). The Kernel selects the appropriate underlying model. Experts have no access to model routing decisions.

This is a structural property of the platform, not a restriction. It ensures governance consistency and prevents individual apps from making uncontrolled choices about AI resource usage.

The platform review process requires a minimum of 3 test cases. However, the professional standard is more than the minimum. Your test library should cover all four test types: valid input, invalid input, missing data, and extreme cases.

An app with exactly 3 identical test cases will be flagged for inadequate coverage during review. Build as many tests as needed to demonstrate that your app handles the realistic range of professional inputs correctly.

Every output your app produces must be: Accurate (reflects what the input data actually states), Clear (professional language appropriate to the audience), Consistent (same input produces structurally consistent results), and Explainable (the user can understand how the output was produced).

You must also avoid ambiguity, over-generalisation, and unverifiable claims. These are the criteria platform reviewers apply and the standards your professional users depend on.

App ranking in Appstream is determined by execution performance metrics, not promotional activity. Key factors include: execution success rate, output acceptance rate (whether users acknowledge outputs without heavy modification), schema conformance rate, and user trust signals.

Poor performance results in lower visibility and reduced usage. Persistent quality issues may trigger a review of your app's continued availability.

Your Expert Dashboard shows key performance metrics for each published app: usage volume, execution success rate, output modification rate (how often users edit outputs before acknowledging), and any reported issues.

Monitor these metrics regularly. A rising modification rate signals that your outputs are not meeting user needs — this requires a logic review and likely a new version.

Users may accept outputs, modify outputs before acknowledging, or reject outputs entirely. These signals are aggregated and made available in your Dashboard. Individual user data is never exposed — only anonymised aggregate performance signals are provided to Experts.

You must use this feedback to improve your logic and release updated versions. Ignoring persistent quality signals is a conduct violation under the Expert Agreement.

You earn a share of the platform fee for every eligible execution of your published app. An eligible execution is one that completes successfully and reaches the acknowledged state — failed executions, schema-rejected outputs, and unacknowledged drafts do not generate Expert revenue.

No. Prices are set by Budget Control™ based on the computational complexity of each execution. Experts do not set prices, manage billing, or interact with payment infrastructure. The platform handles all fee calculation, collection, and settlement. Your revenue share is a percentage of the platform fee as defined in the Developer Terms.

Accrued earnings are paid out periodically to your verified bank account, subject to platform policy and the conditions defined in the Developer Terms. You must register a verified bank account before your first payout can be processed.