MdgSuite — User Manual

🔑 Sign in & 2FA

MdgSuite uses a two-factor authentication flow: email + password, then a 6-digit TOTP code from an authenticator app (Google Authenticator, Authy, 1Password, Bitwarden, any RFC-6238 compliant app).

🔒 Passwords & PINs

Password policy

The default policy requires at least 8 characters, including:

• one uppercase letter
• one lowercase letter
• one digit
• one special character (e.g. !, ?, #, $)

Your tenant ADMIN can tighten this further in Security Setup but never loosen it.

Badge PIN vs password

WMS operators sign in at the warehouse terminal with a badge code + PIN — typically 4 or 6 digits. This is not the password. Passwords are for the web app; PINs are for the terminal. You can change either one from the user profile menu.

🏡 First-tenant bootstrap (ADMIN)

A fresh WMS instance lands without any tenant provisioned. The first person to log in creates the tenant by supplying a company name on the login form alongside their email and password.

The system:

1. creates a dedicated tenant database mdgwms_<id>
2. seeds default settings (warehouses, CCNL, governance defaults)
3. promotes you to ADMIN for that tenant

🧠 Agent chats — how they work

MdgSuite ships with a virtual C-suite. Each persona owns a different lens on the business; you interact through a chat window pinned to the relevant context (plan, job, or the current company as a whole).

🍭 Action pills

When the agent proposes to do something (update a setting, run a plan, rebalance), the proposal lands as a coloured pill at the end of the chat bubble. The colour tells you the outcome:

Contextual buttons

Some pills carry extra buttons:

• Approve — applies a pending action.
• ▶ Run now — triggers a recompute of the linked job. Rarely needed for rerun any more: as of 2026-04-19 the Planner chat runs the scheduler inline when it emits rerun, and the reply already carries the new score / overtime / unscheduled numbers. The button is still there for the other clone actions (apply_rebalance, apply_level, apply_absence) which create a clone in READY.
• ↗ Open new job — navigates to the newly-created job so you can inspect the output. The clone carries an auto-generated Label like «Rebalance (2 moves) · MaxOT 60 · OTw×2» so you can tell it apart from the original at a glance.

🧭 What-if simulations

The Planner can recompute the current plan with temporary setting overrides — overtime cap raised, spillover target lowered, MaxOT per day bumped, an operator marked absent, and so on. The tenant's real defaults are never touched until you explicitly promote the override. This is the day-to-day what-if tool.

Trigger a what-if

Open the 💬 Chat with the Planner section on the UFCP page (WMS) or on a specific Job (UFCP SaaS) and phrase the question as a hypothetical. Examples in plain English or Italian:

• «What if I raise MaxOT to 120 minutes per day?»
• «Rerun with spillover target at 85%.»
• «Simula assenza di Sara martedì e ricalcola.»
• «Prova send-ahead al 40% su tutte le operazioni.»

The Planner invokes one of the tools scoped to simulation (update_setting with scope=Job, then rerun, or one of apply_rebalance / apply_level / apply_absence) and recomputes. The tenant's default settings are not changed — only this Job's SettingsOverrideJson is.

The SIMULATION banner

Above the plan summary a yellow banner appears with the label SIMULATION, a one-line summary of what was changed (e.g. «MaxOtMinutesPerDay: 90 → 120»), and two buttons on the right. Expanding the banner lists every override field-by-field.

As long as the banner is visible, every number on the page — Gantt, daily capacity, violations, plan score — reflects the simulated plan, not the tenant default.

Discard vs Promote

Named simulations — the SIM badge

When the Planner runs apply_rebalance, apply_level, or apply_absence, the clone is saved with an auto-generated Label (max 80 chars) summarising what changed — for example:

• Rebalance (2 moves) · MaxOT 60 · OTw×2
• Level (Tuesday → Wednesday)
• Absence Mario · 2026-04-22

You see this label everywhere the Job shows up: the Simulations page, the UFCP page header, the chat pill that offers to open the clone. Any Job that carries a SettingsOverrideJson override also carries a small SIM badge next to its status — it's the visual cue that you're looking at a what-if, not at a canonical plan.

The UFCP page job-header bar

After you press Calculate Plan or open a Job from the Simulations page, a thin header bar appears above the plan view: a short Job id + an editable Label input + a Save button. Use it to rename a simulation in place before you share the link with a colleague. An empty label clears the name (back to «no label»); the endpoint behind the button is PATCH /api/jobs/{id}/label (WMS) or PATCH /v1/jobs/{id}/label (UFCP).

The Simulations page

Open 🧪 Simulations from the WMS sidebar (under the Agents collapsible section, next to the chats) to get a list of your recent Jobs. One row per Job, each with:

• Label — inline-editable. Click, type, press Enter (or click away) to save. Empty clears the name.
• Status pill — READY / RUNNING / COMPLETED / FAILED, same colour scheme as the action pills.
• SIM badge — present only when the Job has a settings override. Canonical plans show a plain status pill and nothing more.
• Open — reloads the Job in the UFCP Planner page, so you can walk through the Gantt and the simulation banner again.
• Delete — drops the Job entirely. The tenant defaults are unaffected; the deletion is local to this Job.

Comparing scenarios

Today there is no automated side-by-side diff — each what-if replaces the previous one on the same Job, and clone-based actions (apply_*) produce distinct Jobs. To compare two scenarios end-to-end:

1. Run scenario A via the chat. The clone gets an auto-label; rename it from the Simulations page if you want something shorter.
2. Go back to the original Job (same page, the parent Job id is in the header), run scenario B.
3. Open Simulations and compare metrics between the two clones — OT minutes, unscheduled count, plan score. Click each Open to inspect the Gantt.

A dedicated side-by-side diff (metric table rendered for two Jobs at once) is on the roadmap.

✅ Approve & reject

Every action has an impact level: LOW, MEDIUM, HIGH. Each tenant sets an autonomy threshold in Agent Governance. Actions at or below the threshold are auto-applied; higher-impact actions land as ⏸ pending and wait.

Approve from the chat

1. Scroll to the pending pill in the chat.
2. Click Approve.
3. The pill turns ✓ applied or ⚠ failed depending on the backend's validation.

Reject from the chat

Click Reject on the pending pill. The action is archived as rejected_action with your user id — the agent will not propose the exact same thing again within 24 hours.

📱 Telegram approval

If the tenant has Telegram configured, high-impact pending actions also land as a message in a chosen chat with inline Approve and Reject buttons. Tapping one of them closes the loop the same way the in-chat pill does.

Setup (ADMIN)

1. Create a Telegram bot via @BotFather and keep the bot token.
2. Add the bot to a private chat with yourself (or a team channel); send /start so Telegram records your chat id.
3. In MdgSuite open Agent Governance, fill Telegram Bot Token and Telegram Chat Id, save.
4. Go to Telegram Setup and click Install webhook. The bot now forwards button presses back to MdgSuite.

⚖ Agent Governance (ADMIN)

One-page control of how autonomous the agents can be. Tenant-wide settings, applied to every persona.

📡 Observer Setup (ADMIN)

Each C-level persona has a background observer that ticks on its own schedule. Use this page to turn them on/off and set the interval per persona.

Enabled: the persona is allowed to wake. Interval: minutes between scheduled ticks (5–1440). Last / Next run: for observability — lets you confirm ticks are actually happening.

Typical values:

• CFO 60 min — weekly aggregations don't change fast.
• COO 60 min — plan-score drift is a rolling window.
• CHRO 15 min — CCNL breaches need a fast pick-up when an operator clocks unusual hours.

📋 Tenant Knowledge (ADMIN)

Until this page existed, everything the agent «knew» about your company had to be inferred from the memory corpus — past plans, concerns, chat turns. Tenant Knowledge is where you write it down explicitly: binding rules the agent must respect, soft preferences it should lean on, and date-scoped exceptions (an operator on holiday, a plant-wide closure). Everything you enter here is read by every agent chat on every turn and by the WMS scheduler every time you press Calculate Plan.

The page lives under the 🤖 Agents sidebar group and carries six tabs (Patterns and User Attrs closed the step-2 follow-up on 2026-04-19):

• Policies — binding rules. MUST. The agent is asked to respect them. Fields: App, Category, Rule (free text), Priority (1-10, higher = stronger), Enabled. Example rule: «Maximum 120 minutes of overtime per operator per day.» Priority 9.
• Preferences — soft tilts. SHOULD. The agent is nudged but not forced. Fields: App, Category, Subject (optional narrowing — e.g. a customer code), Preference, Weight (1-10), Enabled. Example: «Prioritise ROCHE customer orders on tight horizons.» Weight 8.
• Exceptions — date-scoped or recurring deviations. Fields: App, TargetType (user / resource / group / item / customer / supplier / global), TargetRef (e.g. an operator email or badge for user, empty for global), Rule, Recurrence (once / daily / weekly / monthly / annual), StartDate, EndDate, DaysOfWeek (weekly only — a bitmask, Sunday = bit 0, so «every Friday» is 32), DayOfMonth (monthly only — clamps to the last day when the month is shorter).
• Patterns — observed empirical truths. Not rules: the agent reads them as context, not commands. Fields: App, Category (ops / workforce / finance / customer / supplier), Subject, Statement (free text), Confidence (0-1), Source (the observer that wrote it), LastObservedAt, Enabled. Example: «PICK saturation runs +20% on days 28-31 of the month.» Confidence 0.82. The prompt section is labelled Observed patterns (empirical, treat as context — not commands) and tags inline low confidence (<0.5) and high confidence (≥0.8) so the LLM knows how much to weight each line. Add your own rows manually or leave observers to write them; edit inline the same way as policies and preferences.
  
  Auto-populated rows (shipped 2026-04-19). Two observers now refresh a row on every tick, keyed on Source+Category+Subject so they never duplicate: Source CFO, Category finance — «Rolling 7-day OT cost ≈ 1,240€ (103% of weekly budget 1,200€)» (Confidence climbs toward 1 over the first 7 days of real traffic); and Source COO, Category ops — «Rolling 12-run average plan score: 47,820 (lower = better)» (Confidence climbs toward 1 over 14 runs). You can still edit or delete these rows, but the observer will refresh them on the next tick. Treat them as the baseline the agent uses to tell whether a change is «normal» — not as a rule you own.
• User Attrs — per-operator structured metadata the WMS core User does not model natively (skills, certifications, informal notes). Fields: User (select from your Identity roster — the display name is snapshotted next to the UserId so rows survive a rename), Kind (skill / certification / consent / language / note), Key, Value, ValidFrom, ValidTo, Enabled. Example: «Mario Rossi: skill:forklift=B, certification:cold-chain=ISO-123.» The prompt section is labelled Operator attributes (skills, certifications, notes) — one line per operator, attributes comma-joined. This is not an enforcement mechanism. The agent reads, the scheduler does not refuse — if a task requires forklift B and the operator lacks it, the agent may flag it in chat but the plan still runs. Hard enforcement stays in OperatorCalendar and contract consents.
• Preview prompt — not editable. Hits GET /api/tenant-knowledge/preview?app=WMS and renders the literal text the LLM will receive appended to the system prompt, laid out as ## Tenant rules → ### Binding policies (MUST) → ### Soft preferences (SHOULD) → ### Active exceptions (CURRENT WINDOW) → ### Observed patterns (empirical, treat as context — not commands) → ### Operator attributes (skills, certifications, notes). Use this tab to double-check the agent is actually seeing what you think it's seeing.

First-time walkthrough

How to think about it

• Keep policies few and high-priority. A policy list of 30 items waters itself down in the prompt; five crisp rules with priority 8-10 carry more weight.
• Use preferences for business flavour (customer priorities, seasonal tilts, internal conventions) and policies for hard constraints (caps, forbidden patterns).
• Exceptions are not a calendar. Single-day absences still fit on the operator calendar; use exceptions for recurring patterns («Mario every Friday») or for non-operator targets (a supplier closure, a plant-wide holiday, a customer freeze period).
• Everything the agent respects (or breaches) shows up in Agent Decisions. When a decision's outcome pill goes negative, checking Tenant Knowledge is the first place to look — the agent may be missing a rule you haven't written down yet.

💰 CFO Setup (ADMIN)

Thresholds the CFO uses to decide whether to raise a concern.

🧑‍⚖️ CHRO Setup (ADMIN)

Policy guardrails on top of the CCNL master data. The CCNL itself is the hard floor — these settings can only make the rule stricter, not looser.

📊 COO Setup (ADMIN)

Objective weights and strategy priority the Planner uses when generating a plan. The COO observer watches the drift of the resulting plan score over time.

• StrategyPriority — ordered list of high-level goals (e.g. tardiness > cost > utilization).
• ObjectiveWeights — fine-grained numeric weights for each scoring dimension.
• SpilloverObjective — what to optimise when work exceeds capacity for the day (defer vs over-assign).

🛡 Security Setup (ADMIN)

Tenant-wide security policy. Per-user actions (reset password, reset 2FA, reset badge, unlock) live on the Users page — Security Setup is just the policy layer.

Policy knobs

• Lockout: failed-attempt threshold + lockout duration.
• Login window: optional hours-of-day the login is accepted.
• IP allow-list: restrict login to known subnets. Empty = no restriction.
• Password policy: min length, required character classes (always at least the platform default).
• PIN policy: min length, numeric-only, rotation policy for badge PINs.
• TOTP TTL: minutes a verified 2FA session is remembered before the code is asked again.

👥 Users (ADMIN)

Roster of the operators in this tenant. Per-user actions all live here — they are audited (the user and the ADMIN who clicked are recorded in the tenant audit log).

Per-user reset actions

• Reset password — stamps MustChangePassword on the user. At next login they set a fresh password before reaching the app shell.
• Reset 2FA — wipes the TOTP secret + backup codes. The user re-enrols on next login (fresh QR, fresh backup codes). Cross-Company: 2FA is one per human, so this clears it in every tenant the user is a member of.
• Reset badge PIN — stamps MustChangePin. At next badge+PIN login the operator rotates the PIN to a new one matching the current policy.
• Clear lockout — zeroes the failed-attempt counter and clears LockedUntil. Use when an operator is stuck after too many bad PIN scans.

Other actions

• Assign role (ADMIN / SUPERVISOR / USER).
• Enable / disable the user in this tenant (soft-disable, keeps audit history).
• Badge / photo: upload a photo for the badge print layout (the visual template itself lives in System → Badge Styles).

🤖 AI Setup (ADMIN)

Configure which AI provider powers the agents. MdgSuite supports Anthropic (Claude), OpenAI (GPT), Google (Gemini), and Ollama (local). All four can be enabled at once; the priority order decides cascade.

1. Pick a provider, paste the API key. The key is encrypted at rest.
2. Choose the default model. Some hints:
   • Anthropic: claude-sonnet-4-5 (balanced) or claude-opus-4-5 (deepest reasoning).
   • OpenAI: gpt-4o (balanced) or gpt-4.1.
   • Gemini: gemini-2.5-flash.
   • Ollama: qwen2.5:7b runs comfortably on a single GPU.
3. Set Max tokens and Temperature. Defaults are 2048 / 0.3 — low temperature favours consistent, auditable replies.
4. Set Priority. Lower = tried first. If the top provider times out, the cascade moves to the next.

🗣 Agent Chamber

A read-only timeline of what the agents have been doing. Use it to audit autonomous actions, read concerns, or simply follow along while work happens.

Entry kinds

• concern — an observer flagged something worth attention.
• action — an autonomous or approved change was applied. Includes the target endpoint and the response.
• pending_action — a change is waiting for approval.
• rejected_action — a change was rejected (by a human or by timeout).
• autonomous_action — the narrative companion of a row in Agent Decisions. Every time the autonomous runtime dispatches a decision (whether it auto-applied or just parked the proposal as pending), a one-line summary lands here in the form «CFO auto-applied update_setting: <rationale>» or «CHRO proposed (pending review) update_setting: …». Shipped 2026-04-19 so you can follow what happened overnight without having to scroll the audit table — concerns, autonomous actions, meetings and chat turns now sit in the same timeline.
• meeting — a round-by-round transcript of a multi-agent meeting (convened via convene_meeting).
• interaction — a user-to-agent chat turn.

Filters & search

• Role filter: see only CFO, COO, CHRO, Planner, ...
• Kind filter: see only concerns, or only meetings, ...
• Free-text search: semantic retrieval over the full memory (pgvector + HNSW).

🔎 Agent Decisions (ADMIN)

The Chamber shows agent activity as a narrative timeline — useful to follow along. Agent Decisions, reached from the same menu group, is the structured audit trail: every action that reaches the dispatcher lands here as a row, regardless of whether it came from a chat click, a Telegram button, or the autonomous runtime. Use it to answer questions like «what did the agent do last week and why did it think it was the right call?».

What's in each row

• Persona and App — who proposed, from which host (WMS or UFCP of the same company).
• Action code (e.g. update_setting, apply_rebalance, validate_plan) and Level (LOW / MEDIUM / HIGH) as classified by the dispatcher.
• Trigger distinguishes the origin surface:
  • chat — the reply came from a human chat turn.
  • approve — a human clicked Approve on a pending pill (web UI).
  • telegram — a human tapped Approve on the Telegram card.
  • background — an observer or the autonomous runtime produced it without a user turn.
• Status lifecycle:
  • auto within-threshold action, auto-applied.
  • manual approved by a human.
  • pending waiting on approval.
  • rejected dropped by a human.
  • failed apply threw — check the Result block for the error.
  • expired approval window elapsed with no decision.
• Esito (Outcome) — verdict the evaluator wrote after comparing the plan score before and after the decision. A colored pill: positive (plan score improved by more than 5%), neutral (within ±5%), negative (worsened by more than 5%), inconclusive (no comparable baseline or successor). A long dash means the sweep hasn't scored the row yet — it runs every 15 minutes and only considers rows older than 6 hours. Hover the pill for the baseline → successor score and Δ%.
• Duration — time from proposal to terminal state. Useful to spot stuck pendings or slow dispatchers.

The 30-day summary tile

The top of the page shows an Outcome — last 30 days rollup: five counters (positive / neutral / negative / inconclusive / not-yet-evaluated) plus a per-persona breakdown with an average Δ score column. A negative average means the agents of that persona, on balance, improved the plan over the window — that is the single number to trust when answering «is autonomy paying off?» for a tenant.

Filters

The filter bar accepts any combination of persona, action code, status, from, to. Results are newest-first and hard-capped at 200 rows per page; use the Prev / Next buttons to walk back in time.

The detail modal

Clicking Open on a row reveals four JSON blocks:

• Input — context snapshot at proposal time (rationale for background actions, pointer to the bound Job for apply_* actions).
• Output — the raw dispatcher payload (same shape the LLM emitted in the ACTION tag).
• Result — the apply outcome: applied details on success, error envelope on failure, rejection reason for rejected rows.
• Outcome KPIs — the evaluator's workings: baseline plan id + score, successor plan id + score, delta, and the neutral-band threshold used. For inconclusive verdicts it shows the reason (no baseline, no successor yet, decision not in terminal state).

What an autonomous proposal looks like

When the autonomous runtime (not a chat turn) produces a row, the Trigger column reads background. As of 2026-04-19 three agents can populate those rows: AutonomousRebalanceAgent (persona COO), AutonomousCfoBudgetAgent (persona CFO), AutonomousChroComplianceAgent (persona CHRO). Read them by opening the detail modal and scanning the Input block — the agent puts its rationale there in plain prose next to the raw numbers. The two new personas read as follows:

• CFO budget proposal — Persona CFO, Action update_setting, Level LOW. Typical rationale: «Rolling 7-day OT spend is at €1,240 / €1,200 weekly budget (103%). Current MaxOverTimeMinutesPerDay = 60; tightening to 45 (−25%).» The Output block shows the concrete update_setting payload that will bring MaxOverTimeMinutesPerDay down. The agent never loosens the cap and never drops below a 30-minute floor, so a rejected row just leaves today's cap in place.
• CHRO compliance proposal — Persona CHRO, Action update_setting, Level MEDIUM. Typical rationale: «Tenant cap is 120 min/day but the strictest in-use CCNL (CCNL_CHIM_FARM_IND) allows 90. Pinning tenant cap to 90 to stay compliant.» The Output block carries the update_setting payload with the strict value. Safe by construction: the agent only proposes the cap when the tenant-wide setting is looser than the contract allows — never the other way round, never on zero / negative caps.

Both proposals respect AutonomousShadowMode: while shadow is on they land pending regardless of level. Once you flip shadow off, LOW (CFO budget) is inside the default AutoApproveMaxLevel = MEDIUM and auto-applies; MEDIUM (CHRO compliance) also auto-applies under the default, but we recommend keeping the CHRO proposals in manual review for a bit longer than the CFO ones — they move a global cap that affects every upcoming plan.

Thumbs-up / thumbs-down on a decision

Clicking Open on a row now also surfaces two buttons next to the outcome pill: 👍 Useful and 👎 Bad call. Pressing one writes your vote against the baseline plan memory that bracketed the decision:

• Positive votes push the memory's feedback score toward +1; negative votes push it toward −1. The hybrid recall the agent uses on future chat turns then surfaces upvoted memories first and down-ranks the ones you flagged — your thumbs literally steer future retrieval.
• Re-clicking the same thumb does nothing (idempotent). Switching from 👍 to 👎 (or back) computes the net delta so your score never compounds. Clearing a vote reverts the shift.
• The outcome sweep also writes to this score automatically (±0.5 per positive / negative verdict), so even tenants that don't vote benefit from the signal.

🧩 Memory Browser & GDPR (ADMIN)

Before this page existed, the only way an admin could inspect what the agents remembered about the company was to open a SQL client and query mdgagent_<companyId> by hand. The Memory Browser page (under 🤖 Agents, 🧩 icon, ADMIN-only) now exposes that corpus as a plain table with filters, per-row delete, and two GDPR controls at the top.

Browsing the corpus

1. Open 🤖 Agents → Memory Browser.
2. Set the filters you care about: Kind (plan, concern, action, interaction, meeting, ...), Role (the producing persona — COO, CFO, CHRO, ...), UserId (if you're hunting for everything tied to a specific user), Take (default 100, max 500).
3. Press Search. The raw rows come back ordered by most recent first, with columns for CreatedAt, Kind, Role, App, Content (truncated to 400 chars with a «...» expand), FeedbackScore (the number in [-1, +1] described above), and UserId.
4. Click the inline 🗑 icon on any row to delete just that entry. Useful to scrub a single stale concern without touching the rest of the history.

GDPR Article 15 — export a user's data

Type the target user's UserId (a GUID; grab it from the Admin → Users roster) into the top control bar and press Export JSON. The browser downloads a agent-memory-export-<userId>.json file containing:

• Every memory row where UserId equals the target — plans, interactions, concerns, actions, anything.
• Every UserAttribute row attached to the same user (skills, certifications, consents, notes).

Send this bundle to the data subject. It satisfies the right of access without you writing any SQL.

GDPR Article 17 — purge a user's data

1. Fill the UserId field with the target GUID.
2. Fill the Display name field with the exact name the agents have been using in free-prose memory (e.g. «Mario Rossi»). This is important: some memory rows reference the user by name inside their Content rather than by UserId — without the display name, those rows would survive.
3. Press Purge all for user. You will be asked to confirm twice.

The backend then deletes: every memory whose UserId matches OR whose Content contains the display-name substring, plus every UserAttribute attached to the user. You get a count of deleted rows back.

How long memories live anyway

Even without manual purging, plan and interaction rows expire automatically via a background sweep:

• plan rows — 90 days.
• interaction rows — 60 days.
• Everything else (concern, action, note, pattern, pending_action, meeting) is kept forever so the company's long-term memory survives.

The sweep runs daily per company and is silent — you won't see it in Agent Decisions. If you need to verify it ran, check the server logs for MemoryRetentionService.

🧮 WMS menu layout

As of 2026-04-19 the WMS sidebar is grouped into collapsible sections. The first time you load a page the menu opens all collapsed so the sidebar fits one screen; you then expand the sections you need and the state persists for the rest of the session.

Agent-related pages now live under a single 🤖 Agents section:

• One row per chat (COO, CFO, CHRO, Planner, CMO, QA, CEO)
• Agent Chamber — narrative timeline
• Agent Decisions — structured audit trail with the Outcome column and the 30-day rollup tile
• Memory Browser — raw corpus inspection + GDPR export / purge (see above)
• Tenant Knowledge — policies, preferences, exceptions, patterns, user attributes and the prompt preview (see above)

The other sections in the sidebar group by functional area: Inbound, Inventory, Reports, COO, CFO, CHRO, QA, Catalog, System, plus the new Simulations entry inside Agents. If a page you remember is missing, it's almost always because its parent section is collapsed — click the section header to expand it.

🔧 Troubleshooting

🔑 Terms & Privacy

The platform is operated under the EU GDPR framework. The full legal texts live at Privacy Policy and Terms of Use. This section is a plain-English summary for day-to-day users.

Consent modal at sign-in

When a new version of the Terms or Privacy Policy is published, at your next desktop sign-in you see a small modal: “We've updated our Terms & Privacy”. Review the two linked documents (they open in a new tab) and click Continue. Your acceptance is recorded with version, UTC timestamp, and IP address on the Users row for audit. Badge-scanner logins skip the modal — operators accept at their next email-based sign-in instead.

What we collect

• Your name, work email, tenant membership, role, and login events.
• Anything your users enter into the app: schedules, tickets, chats, agent decisions, voice transcriptions (when Voice is enabled).
• Security-relevant metadata: IP on login, token-usage counters, reasoning traces for agentic actions.

Where it lives

All operational data is stored in EU data centres (Hetzner, Germany/Finland). LLM API calls for agent reasoning may be routed to US regions when you select US-based providers in Governance settings — this is disclosed at selection time and can be disabled per-tenant.

Your rights

EU/EEA residents have full GDPR rights (access, rectification, erasure, portability, objection, complaint to the Garante). Users in other regions retain equivalent rights under their local regime (UK-GDPR, CCPA, LGPD, revFADP). Access requests are handled via privacy@dressai.info. Tenant ADMINs can also trigger Memory Browser exports directly — see the Memory Browser & GDPR section.

When things change

We bump the version string of the Terms or Privacy Policy on material changes. The consent modal re-appears at the next sign-in so you're never silently bound by a new text.

📖 Glossary

ADMIN

A user with full access to the tenant's setup pages and per-user reset actions.

Agent Chamber

Read-only timeline of agent activity. See above.

Agent Decisions

Structured audit log of every dispatcher action, filterable by persona / action / status / time window. See above.

Autonomous runtime

The background loop that lets agents propose actions without a human chat turn. Gated by AutonomousEnabled and DailyActionBudget in Agent Governance.

Autonomy threshold

The highest impact level the agents may act on without asking. Set in Agent Governance.

AutonomousShadowMode

Governance switch (default off). When on, the autonomous runtime keeps proposing but every proposal lands pending regardless of level — admin reviews and approves by hand. Trust-builder before auto-apply is enabled. See Agent Governance.

autonomous_action

A memory Kind written every time the autonomous runtime dispatches a decision — one-line narrative companion to the structured row that lands in Agent Decisions. Surfaces in the Agent Chamber timeline so the operator gets a readable story of what the agent did while they were away. Shipped 2026-04-19.

CCNL

Italian collective labour contract. Hard-coded limits on OT, rest, and night-shift. The CHRO persona enforces them.

Concern

A finding an observer wrote to memory when a threshold was breached. Surfaces in the Chamber and influences the chat's answers.

Event bus (A#2)

Postgres LISTEN/NOTIFY channel that wakes peer observers sub-second on a high-severity concern. See The Agentic Org for the full protocol.

Impact level

LOW / MEDIUM / HIGH — how much the action could disrupt operations. Decides whether the action is auto-applied or pending.

Observer

A background service that periodically reads memory, checks thresholds, and writes concerns. One per persona.

OPERATOR

A warehouse user with badge + PIN access, no setup rights.

Outcome

The verdict the OutcomeEvaluator writes on each dispatcher row after comparing the plan score before and after the decision. One of positive, neutral, negative, inconclusive. Shown as a coloured pill in Agent Decisions.

Plan score

A numeric summary of how well a computed plan hits the tenant's objectives. Lower = better. The COO observer watches drift over a 14-day window.

SIM badge

Small marker shown next to a Job's status when the Job carries a SettingsOverrideJson. It means the Job is a what-if simulation, not a canonical plan. Autonomy ignores these.

Simulations page

WMS sidebar entry (under Agents) listing recent Jobs with inline rename, status, SIM badge, Open, Delete. See What-if simulations.

Tenant Knowledge

ADMIN page holding the five admin-curated tables that steer the agent: policies (binding MUST rules), preferences (soft SHOULD tilts), exceptions (date-scoped / recurring deviations), patterns (observed empirical truths read as context, not commands) and user attributes (per-operator skills / certifications / notes). Read on every chat turn; honoured by the WMS scheduler during Calculate Plan. See above.

TenantException

A row in Tenant Knowledge that narrows a TargetType (user / global / …) to a recurrence and a date window. user and global exceptions steer the WMS scheduler; other target types are prompt-injection only for v1.

TenantPattern

A row in Tenant Knowledge that captures an observed empirical truth about how the company actually operates — e.g. «PICK saturation runs +20% on days 28-31 of the month». Has a Confidence between 0 and 1; agents read it as context, not as a rule to enforce. The Source field records which observer wrote it. See above.

UserAttribute

A row in Tenant Knowledge attaching structured metadata to a single operator — Kind in (skill / certification / consent / language / note), plus a Key and Value. Makes skills and certifications visible to the agent without extending the core User entity. Not enforced by the scheduler. See above.

Memory Browser

ADMIN page under 🤖 Agents to inspect the per-company agent memory corpus with filters and per-row delete, and to run GDPR export / purge for a specific user. See above.

FeedbackScore

A number in [-1, +1] attached to every memory row. Nudged by admin thumbs-up / thumbs-down on Agent Decisions and by the outcome sweep when it writes a verdict. Used as a fourth term (weight 0.1) when the agent retrieves relevant context on future turns.

TOTP

Time-based one-time password, RFC-6238 — the 6-digit code from your authenticator app.