MIOSAx

Discovery workbook

Phase 1 / Workstream A
Complete together
Revision 2

Pritt Investment Partners

Define the business before asking software to operate it.

A working document for turning Pritt's organization, language, workflows, information, authority, and desired outcomes into an implementable BusinessOS architecture.

Required participantsScott, department owner, operating user, technical or security owner, MIOSA architecture lead, and Merydian delivery lead.

Required outputAn approved language map, work-location model, workflow contract, artifact register, boundary map, and first implementation backlog.

Authority and outcome

This is an architecture session. Every answer should identify an owner, an example, and the evidence needed to accept it.

Selected pilot department

Operations or Marketing, unless discovery supports a stronger candidate.

Executive sponsor and acceptance authority

Department owner

Named operating users

Technical and security owner

Rules for the session

Use real work, not hypothetical workflows.
Distinguish current reality from the desired future.
Name the person who owns each decision.
Show the source system or artifact when possible.
Record uncertainty instead of inventing an answer.
Do not add scope without recording its commercial effect.

Session success: the team can explain one operating loop from source input to accepted outcome and identify where each object lives.

From language to executable architecture

The workshop moves from what Pritt means to where work lives and how the system should behave.

01 / Define

Language

Canonical terms, aliases, exclusions, and the difference between similar operating concepts.

02 / Classify

Types

Departments, roles, work objects, documents, signals, decisions, and outcomes.

03 / Relate

Ontology

Ownership, authority, dependencies, evidence, access, handoffs, and lifecycle.

04 / Implement

Interfaces

Modules, views, agents, actions, permissions, memory, and acceptance evidence.

Do not skip the middle: a screen should not be built until the team knows which operating object it represents, what can happen to it, and who has authority to act.

What words mean at Pritt

Record the terms the system must understand without ambiguity.

Term	Pritt definition	Example	Owner
Organization
Company / entity
Department / circle
Workspace
Project
Client / partner
Decision
Signal
Evidence
Accepted outcome

Terms Pritt uses that outsiders misunderstand

Terms that currently mean different things to different teams

Decision: every ambiguous term must receive one canonical definition or remain explicitly unresolved before implementation.

What exists and how it relates

Define the operating objects that matter to the pilot and the relationships that make them useful.

Taxonomy: object types

Type	Required examples
People and roles
Companies and departments
Projects and workflows
Clients, assets, and offers
Documents and records
Signals and events
Decisions and risks
Metrics and outcomes

Ontology: relationship verbs

Relationship	Pritt rule
owns / approves
belongs to / contains
depends on / blocks
created by / derived from
supports / contradicts
visible to / restricted from
triggers / responds to
accepts / rejects / supersedes

One relationship that must never be inferred without human confirmation

Implementation use: these types and relationships become schemas, filters, permissions, retrieval constraints, interface views, and agent guardrails.

Where every object belongs

Map the selected department into organizations, workspaces, nodes, signals, and accepted memory.

Object	System of record	Workspace	Owner	Access rule
Department operating model
Selected workflow
Source documents
Agent configuration
Decisions and approvals
Outcome evidence

Boundary question: if an object belongs to two departments, identify its authoritative workspace and define which other workspaces receive a reference, a synchronized copy, or no access.

One real loop

Trace a real example from input through governed work to an accepted outcome.

Trigger and input

What starts the work and where does the source material originate?

Required context

Which facts, policies, examples, decisions, and history are required?

Actions and handoffs

What happens, in what order, and who must participate?

Expected output

What exact document, record, decision, task, message, or interface state is produced?

Review and approval

Who can accept, reject, revise, or override?

Outcome and feedback

What proves value and what should the system remember?

Failure path: document what happens when context is missing, a provider fails, the agent is uncertain, a deadline passes, or a human rejects the result.

How people ask and receive

Identify every important signal, the channel it arrives through, and the interface best suited to the response.

Signal	Source	Recipient	Expected response	Interface	Urgency
Request
Approval
Exception
Decision
Deadline
Outcome

Command

Ask or direct

Natural-language request, structured action, or delegated task.

Inbox

Triage and respond

Signals requiring review, assignment, clarification, or acceptance.

Module

Operate recurring work

Purpose-built view for a department workflow or operating object.

Dashboard

See state

Progress, risks, exceptions, outcomes, and accountable owners.

Document

Produce an artifact

Proposal, memo, analysis, report, plan, brief, or record.

Notification

Interrupt intentionally

Only when urgency and authority justify leaving the operating surface.

Interfaces users refuse to adopt, and why

What Pritt provides

Collect the current system as evidence before deciding what should be reused, replaced, synchronized, or retired.

Organization chart and legal entities
Department roster and role definitions
Agent commands, prompts, and soul files
Model providers and local model setup
Current applications and integrations
APIs, webhooks, automations, and credentials owners
Source documents and representative records
Templates and accepted output examples
Policies, approvals, and authority rules
Security, privacy, retention, and audit requirements
Cloud provider and deployment constraints
Known failures and unresolved technical debt

Must remain local

May synchronize to Pritt's cloud

Requires human approval

Must be auditable or reversible

Repository rule: the discovery package preserves source evidence and decisions. The implementation repository contains reviewed configuration, schemas, modules, tests, and deployment artifacts.

How the workshop closes

Turn the session into decisions, owners, evidence, and the first implementation backlog.

Decision or action	Owner	Evidence / deliverable	Due	Status
Select pilot department
Approve glossary and aliases
Approve object types and relationships
Confirm local and cloud boundary
Deliver current-state package
Approve workflow contract
Name pilot users and acceptance authority
Authorize implementation workstream

Pilot success measures

Include baseline, target, observation method, owner, and acceptance threshold.

Pritt acceptance authorityDate

MIOSA x Merydian delivery leadDate

Scope rule: unresolved items are recorded as assumptions, exclusions, or follow-up work. They do not silently become implementation commitments.