Monderman Workspace

Govern diagnostic work with precision and continuity.

This workspace is designed to become the operating layer above individual runs: assign diagnostics at scale, govern visibility and anonymity, review results, normalize institutional signal, and compare what the organization is learning over time.

Workspace status

Checking session…

Confirming signed-in access, organization role, saved runs, batch assignments, and analytic governance state.

Runs
0
Saved runs visible in this workspace.
Assignments
0
Open or recent assignments.
Flagged
0
Runs marked for caution or exclusion.

Built for governance

Assignments, visibility, normalization, and trust

Monderman should not just collect diagnostic responses. It should govern who receives them, how they are interpreted, and which signals are included in aggregate learning.

Workspace overview

A premium operating layer for repeated diagnostic use.

This workspace now centers executive visibility, batch assignment operations, role-sensitive output governance, and cleaner organizational learning over time.

Saved runs

0

Diagnostics currently visible in this workspace.

Included in aggregates

0

Runs currently included in aggregate reporting.

Organization

Personal workspace or assigned organization.

Last activity

Most recent run or assignment activity visible here.

Identity and role

Your sign-in, organization membership, and workspace permissions resolve here.

Loading role
M

Loading…

Checking signed-in session.

How the workspace is organized

One console. Three clear admin modes.

Build is where batches are configured and sent. Tracking is where live response flow and status are monitored. Analytics is where raw response activity becomes governed institutional interpretation.

Admin orientation

Build

Validate recipients, choose diagnostic defaults, apply anonymity and output policy, set timing, review, and dispatch.

Tracking

Watch sent, opened, due-soon, completed, flagged, included, and excluded states in one operating surface.

Analytics

Review normalized signal, governance defaults, flagged-run treatment, synthesis, and executive export pathways.

Admin console

Use one clear rail to move between configuring runs, monitoring live response flow, and interpreting governed signal.

Primary navigation

Build

Configure and dispatch diagnostic batches

Move through one clean admin sequence: validate recipients, choose diagnostic defaults, set visibility and anonymity policy, review the batch, and send.

Admin module
1Required

Build recipient set

Paste emails, upload CSV or Excel, or import JSON. Validate before any configuration decisions are finalized.

2Locked

Configure, review, and send

Apply diagnostic defaults, privacy controls, delivery timing, and review the final exposure profile before dispatch.

Best for a quick send list or when you only have emails and a few optional attributes.
One email per line Optional name, team, unit
Drop CSV, Excel, or JSON here
Use this for larger sends. The workspace will validate the file locally and can also call the batch preview route before dispatch.
CSVXLSXJSON
No file selected.
For structured imports from another administrative system.
Rows
0
Valid
0
Duplicates
0
Invalid
0
Your validated recipient set will appear here. Until this step is complete, the configuration stage remains locked.
Let participant see their full output

Turn this off if the run should complete without revealing the full narrative to the participant.

Anonymous response

Store the run as anonymous for reporting purposes while preserving controlled assignment linkage behind the scenes if needed.

Hide full output from admin by default

Use this when the admin should only see metadata or aggregate-level outcomes rather than the full participant narrative.

Request normalization review after completion

Flag this assignment so the backend normalization engine evaluates it immediately after the run lands.

Batch review

Final review before the batch send route is called.

0 recipients

Delivery

Decision Velocity • Managerial • About 30 minutes

Visibility

Participant-visible output, named response, admin-visible by default.

Timing

Send now

Build guidance

Policy decisions that matter before anything goes out

The batch builder should make the send logic feel deliberate: validated recipients, explicit visibility rules, and review-before-dispatch.

Bulk intake, not guesswork

Large sends should begin with recipient validation, duplicate control, and clear row-level issues before any invitations go out.

Visibility state

Participant-visible, admin-visible, aggregate-only, and metadata-only outcomes should be distinct, explicit states.

Anonymity state

Anonymous should not mean lost. It should mean protected reporting treatment governed by policy.

Normalization recommendation

Admins should request backend normalization review, not manipulate results manually.

Batch status

Route readiness

This gives admins immediate confidence about whether the console is still validating and dispatching through the expected backend flow.

Preview route

Not run yet.

Send route

Not run yet.

Recommended additions

What would make Build even stronger

These are product-ready extensions that fit the current architecture without changing the backend model.

  • Saved drafts: preserve partially configured batches before dispatch.
  • Reusable templates: let admins store common diagnostic + visibility combinations.
  • Multi-diagnostic sends: support one recipient set with more than one assigned tool.
  • Scheduled digests: allow send-now, scheduled, and batched reminder patterns to feel native.

Tracking

Live response and assignment flow

This is the admin operating view: what has been sent, what has been opened, what has been completed, what is due soon, and what is beginning to distort signal quality.

0 visible
Open rate
Assignments opened relative to sent volume.
Completion rate
Assignments completed relative to sent volume.
Due soon
0
Assignments approaching due time.
Flagged
0
Runs marked for caution or exclusion.
Included
0
Runs included in aggregate interpretation.
Excluded
0
Runs excluded from aggregates.

Recent assignments

This is the clearest admin queue for what has gone out and where response flow currently stands.

Assignment state
No recent assignments are visible yet.

Recent saved runs

Raw first-arrival responses surface here before they are filtered into governed analytic treatment.

Raw run layer
No saved runs are visible yet. Once diagnostics write to diagnostic_runs, this list will populate automatically.

Governed response review

See runs with visibility, anonymity, and normalization context rather than just raw score storage.

No normalized runs are visible yet. Once the backend normalization routes are mounted, this view will populate with analytic status.

Flagged-run review

This is where the admin can quickly see which responses should not quietly shape institutional interpretation.

No flagged runs are visible yet.

Analytics

Synthesis, signal quality, and governance

This layer turns raw response flow into an institutional learning set: normalized, filtered, governed, and ready for executive interpretation.

Workspace context
All runs
0
Raw runs visible in this workspace.
Included
0
Runs currently included in aggregate reporting.
With caution
0
Runs included, but flagged for caution.
Excluded
0
Runs excluded from aggregate views.

Normalization recommendation log

Raw run preserved, backend recommendation logged, aggregate treatment made explicit.

RunStatusScoreFlagsLast normalized

Cross-diagnostic synthesis

Analytics should culminate in a cleaner institutional picture, not just a list of individual runs.

Cross-tool synthesis

Compare governed signal across Decision Velocity, Structural Clarity, Operational Systems, and Institutional Performance in one executive layer.

Delivery and export

Prepare executive summaries, normalized digests, and downstream exports without changing the raw run record.

Open cross-tool synthesis

Visibility and privacy policy

These controls are where Monderman becomes a governed institutional platform rather than a simple result archive.

Default to participant-visible output

Use as the default assignment policy when the assignee should receive the full narrative immediately after completion.

Default to admin metadata-only for anonymous runs

Helps preserve trust by avoiding accidental upward exposure of full narrative output.

Use normalized analytic set by default

Aggregate views should use included runs first, not raw runs indiscriminately.

Governance model summary

These are the distinctions the product should protect explicitly.

Raw run

Preserved exactly as submitted, never overwritten by normalization or aggregate treatment.

Included analytic set

The default basis for organizational summaries, benchmarks, and leadership dashboards.

Flagged with caution

Still visible, still often included, but explicitly marked as weaker signal.

Excluded from aggregates

Preserved for auditability, but removed from aggregate interpretation when the backend recommends it.

What the backend should govern

The workspace shows these states clearly, but the logic belongs in the API.

  • Completion-speed sanity for each diagnostic depth.
  • Contradiction burden relative to structured answers.
  • Coverage adequacy for adaptive branch completion.
  • Outlier detection relative to the organization comparison set.
  • Duplicate-like patterns that should not quietly distort aggregate signal.