# Maetra reviewer guide

These scenarios use synthetic inputs and report only behavior the reviewer directly observes.

## Govern: review a high-value refund

**Route:** https://maetra.io/try/govern

1. Define a policy requiring approval for refunds above a synthetic threshold.
2. Submit a proposed refund above that threshold.
3. Record whether the result is Allow, Approval Required, or Block and capture the reasoning.
4. Change only the synthetic amount and compare the observed result if quota permits.

Assess whether the policy is understandable, the decision follows it, the explanation identifies the deciding condition, and the page clearly states that no refund was executed.

## Secure: inspect a risky tool call

**Route:** https://maetra.io/try/secure

1. Choose Tool call and enter a protection goal such as stopping destructive or over-privileged operations.
2. Use a synthetic tool such as `repository.execute` and a payload that proposes deleting deployment history without confirmation.
3. Record the verdict, severity, summary, findings, recommended action, and safer version.
4. Compare with a read-only synthetic request if quota permits.

Assess whether the result names the risky operation, recommends a bounded next action, offers a meaningfully safer version, and makes clear that it did not execute the tool.

## Task Guard: detect task drift

**Reference:** https://maetra.io/docs/task-guard-api

This path requires an arranged reviewer workspace or guided demonstration.

Use a synthetic task limited to updating a dependency in staging, running tests, and producing a diff. Compare an aligned action such as running the staging test suite with a material change such as merging to production and contacting customers. Then compare the expected effect with a synthetic reported result.

Assess whether the active objective and constraints remain visible, material scope changes require confirmation, effect verification compares intended and reported state, and task alignment remains separate from approval policy.

## Comply with Audit: trace evidence to history

**Reference:** https://maetra.io/frameworks

This path requires an arranged reviewer workspace or guided demonstration.

Use a synthetic support agent and an available framework. Inspect its mapping, add or update a synthetic evidence record, then use Audit filters to find the matching event and inspect its actor, outcome, module context, and event fingerprints.

Assess whether the framework requirement, mapped control, and evidence are understandable; stale or incomplete evidence remains visible; and the Audit record shows who changed what and when.

## Evaluation limits

- The anonymous Govern and Secure sandbox permits a limited number of checks per 24 hours.
- The sandbox evaluates text and never calls the external tool or performs the proposed action.
- Task Guard, Comply, Audit, Discover, and configured production controls require a reviewer workspace or guided demonstration.
- Production integrations depend on the host calling Maetra and honoring the returned result.
- No independent performance, latency, accuracy, attack-coverage, adoption, or customer-outcome benchmark is included yet.

For reviewer access or a written Q&A, email kingsley@maetra.io.
