Admin User Manual

Quick Start

Admin is the control center for Jymni Ethics Advisor. It shows system health, user activity, credits, model usage, and rules that shape evaluations.

1. Open /admin. You must be signed in with an admin role.
2. Check the summary cards. Look for pending requests, total users, credits outstanding, and recent evaluation volume.
3. Use the tabs. Each tab controls one area, such as Users, LLM, Rate Card, Evaluation Specs, or Policy.
4. Write clear reasons for changes. Credit, access, and role changes should include notes so the audit trail is useful.

Credits Overview

Credits are the units Jymni Ethics Advisor uses to run AI-backed work. Each evaluation, rewrite, follow-up question, spec test, or other LLM process can use credits.

How to handle a credit request

1. Open Requests. Start with Pending requests so active needs appear first.
2. Review the user. Check their current balance, request reason, intended use, organization, timeline, optional note, and recent request history.
3. Approve, adjust, or decline. You can approve a different amount than the user requested when that is the better choice.
4. Add a note. Explain the decision so the audit trail is useful later.
5. Confirm the balance. After approval, check the user record if you need to confirm the new credit total.

Analytics

The Analytics tab gives a fast view of platform activity. Use it to see volume, feature mix, user growth, credit activity, and LLM usage.

Requests

The Requests tab is where admins review exceptional trial/support credit requests. Filter by pending, approved, declined, or all requests. Each card shows the reason, intended use, organization, requested timeline, optional user note, amount, and decision history that are available.

1. Open Requests. Start with Pending so active requests appear first.
2. Review the request context. Check the reason, intended use, organization, timeline, optional note, requested amount, current credits, paid-order and purchased-credit totals, last purchase, prior request/grant totals, and automatic review flags before approving.
3. Adjust the credit amount if needed. You can approve a different number than the user requested.
4. Add an admin note. Use notes to explain why the request was approved or declined. Approved grants record a specific source for beta, support, nonprofit/education, or sales-trial use.

Users

The Users tab lets admins search accounts, create users, change credits, manage access, and review usage. Super admins can also change roles.

Audit Trail

The Audit tab records important admin actions. Use it to answer who changed credits, access, roles, requests, policy rules, or evaluation specs.

• Check actor: Who made the change.
• Check target: Which user, request, rule, or spec was affected.
• Check metadata: Extra details such as credits, notes, and before or after values.
• Use dates: Match audit records to support tickets or review meetings.

LLM

The LLM tab controls the active Google model and API key. It also shows model usage, estimated spend, tokens, and latency.

• Estimated spend: Approximate LLM cost for the selected time range.
• Total tokens: Input and output token volume.
• Evaluations: LLM-backed actions with stored usage.
• Average latency: How long requests take on average.
• Model mix: Which models were used and what they cost.

Rate Card

The Rate Card tab controls how many credits each process costs. Use it when you need to change credit pricing for evaluations, rewrites, tests, or follow-up actions.

1. Review base credits. The base value is the default cost.
2. Enter an override only when needed. Leave the field blank to use the base value.
3. Save pricing. New runs use the updated effective credit cost.

Evaluation Specs

Evaluation Specs are the rule books Studio uses when it reviews a case. They tell Studio what to look for, how to score it, what risks matter, and how to explain the result.

Page layout and scrolling

On desktop, the Evaluation Specs page has two columns. The left column is the version stack. The right column has the editor and test tools. Each column scrolls on its own, so the mouse wheel works where your pointer is.

• Version stack: Use the left column to select drafts, archived specs, and the live spec.
• Editor and test tools: Use the right column to edit fields, review the read-only output contract, and run spec tests.
• Text boxes: Criteria fields grow with normal content. A field only shows its own scrollbar when that one field gets very long.

What an Evaluation Spec controls

Version stack

Common actions

Recommended process

1. Review the active spec. Read the current purpose, scoring rules, examples, and result format before you change anything.
2. Clone the active spec. Start from the live rule book when you want a careful update. Use New draft only for a larger reset.
3. Update the identity fields. Use a clear name, version label, and scope so other admins know why the draft exists.
4. Edit one part at a time. Small changes are easier to test. Avoid changing scoring, tone, examples, and classification rules all at once.
5. Add or update calibration examples. Use examples that show the behavior you want Studio to repeat.
6. Save the draft. Saving does not make it live. It only stores the draft so you can test it.
7. Run Spec test. Use real or realistic cases. Compare the draft result with the active spec result.
8. Review the differences. Look at labels, scores, risk flags, missing facts, tone, and action steps.
9. Revise and retest. If the draft is too strict, too loose, confusing, or uneven, edit it and run another test.
10. Make live only after review. Making a spec live changes Studio behavior for new evaluations.

Sample specs

Admin includes a sample draft named Trust and Power personal ethics spec. It focuses on whether the people involved are trustworthy, transparent about their interests, respectful of consent, and using power responsibly.

Use the Trust and Power sample when a choice depends on advice, private information, unequal authority, dependence, or a conflict of interest. Test it before using Make live.

Spec test

Spec test is the dry run for an Evaluation Spec. It lets you test a selected spec against a case before that spec becomes live. Use it before making any draft live.

Build a useful test case

• Use a real or realistic case. Include the choice, people affected, relationships, setting, stakes, and goal.
• Add facts when they exist. Include relevant history, promises, consent, alternatives, evidence, and likely outcomes.
• Call out the risk. Note vulnerability, health or money issues, urgency, unequal power, personal data, safety, or social pressure.
• Include missing facts on purpose. A good spec should notice when consent, relationship detail, likely consequences, or evidence is missing.
• Keep the case readable. A clear test case gives a clearer comparison.

Run and compare

1. Select the draft or archived spec you want to test. The selected spec result shows how that spec would answer.
2. Paste the test case. Use enough detail for Studio to understand the case, not just a vague one-line description.
3. Choose Compare with active spec when available. This shows the current live result beside the selected spec result.
4. Run the test. The run uses credits and may take a moment because it calls the evaluation model.
5. Study the differences. A better draft should be clearer, more useful, and more consistent with your rules.

Use a small test set

Decision rules

• Make live when the draft is better than the active spec across several test cases and the output still fits Studio.
• Revise when one test improves but another gets worse, or when the result is too strict, too soft, or unclear.
• Do not make live if the draft changes the platform output contract, breaks display fields, or gives results that admins cannot explain.
• Archive older drafts that are no longer being tested so the list stays clean.

Policy Memory

Policy Memory stores compact personal-ethics guardrails. A rule can apply when trigger terms match a case, or it can always be included.

1. Add a clear title. Use a name that explains the rule, such as Medical decisions need qualified help.
2. Choose a type. Types include prohibited action, required disclosure, vulnerable person or group, high-stakes topic, and reflection rule.
3. Add trigger terms. Use terms that should cause the rule to appear during an evaluation.
4. Write short guidance. Tell the evaluator exactly what to watch for or require.
5. Save the rule. Keep Active checked if the rule should be used now.

Safety Rules