Sortium docs

Process Architecture V1

A high-level architecture for turning uncertain situations into shared understanding, accountable action, evidence, and learning.

View raw Markdown

Sortium Process Architecture V1

Date: 2026-05-31

Status: V1 architectural synthesis

Purpose: define Sortium's full process architecture without making the product feel complicated

0. Executive summary

Sortium should not be designed as a chatbot, graph viewer, volunteer platform, or task board.

Sortium is a collaborative situation-processing system.

Its job is to turn:

messy reality + scattered human input + distributed capabilities

into:

shared understanding → accountable decision → coordinated action → evidence → learning

The product must stay simple at the surface while carrying real structure underneath.

The central architectural rule:

Hide complexity in the process engine. Expose only the next useful move to each user.

The full Sortium loop is:

Situation
→ Signals
→ Synthesis
→ Contribution Requests
→ Workstreams
→ Proposals
→ Decisions
→ Actions
→ Results / Evidence / Blockers
→ Updated Shared Picture
→ Learning
→ Next Cycle

Short form:

Sense → Synthesize → Decide → Act → Learn

1. Core product definition

Sortium is a trust-aware coordination process system for uncertain civic, humanitarian, organizational, and resilience situations.

It helps people and organizations:

Sortium should feel like:

“I know what needs my attention, why it matters, what I can safely do, and how my contribution changes the shared picture.”

Not:

“I am managing a graph of suggestions.”

2. The simplicity principle

The system may contain many objects, but the user should usually see one of five simple questions:

What is happening?
What needs attention?
What can I contribute?
What decision/action is needed?
What changed because of action?

Everything else is supporting machinery.

Anti-complexity rules

1. Do not build a task board. Build situation-linked contribution requests.

2. Do not expose the raw graph by default. Show scoped projections.

3. Do not let AI become accountable. AI proposes; named humans decide.

4. Do not make Cronos a boss-agent. Cronos is the process clock and escalation kernel.

5. Do not create independent subgroup realities. Parallel groups work on scoped slices that return to the shared situation.

6. Do not make roles global. Roles are contextual to project, situation, workstream, and domain.

7. Do not make critique social or chaotic. Make contrarian inquiry structured, requested, and node-bound.

8. Do not leak sensitive information through convenience. Every request carries an access envelope.

9. Do not gamify pressure. Recognize useful closed loops, not volume or speed.

10. Do not optimize for dashboards. Optimize for next responsible action.

3. Core architectural model

Sortium V1 should be organized as:

Event-sourced process kernel
+ Situation Object state machines
+ Cronos process-clock service
+ semantic graph projection
+ contribution request / workstream layer
+ access envelope / domain facade layer
+ LLM-assisted synthesis and proposal layer
+ role-specific UX projections

Expanded:

[Human / Org / Group Inputs]
        ↓
[Intake + Access Envelope]
        ↓
[Event Log / Process Kernel]
        ↓
[Situation Object + State Machines]
        ↓
[Semantic Graph Projection]
        ↓
[Synthesis + Contribution Request Engine]
        ↓
[Workstreams + Proposals + Decisions]
        ↓
[Actions + Results + Evidence]
        ↓
[Shared Picture + Learning]

4. Situation Object

The Situation Object is the core unit of Sortium.

A Situation Object represents:

Something uncertain that a group may need to understand, coordinate around, improve, or act on.

Examples:

A Situation Object contains:

title
summary
state
known facts
assumptions
open questions
risks
needs
actors
capabilities
contribution requests
workstreams
proposals
decisions
actions
results
blockers
evidence
learning
permissions
event history

Situation states

emerging
observing
orienting
requesting_input
synthesizing
deciding
acting
reviewing_results
learning
resolved
archived
escalated

These states are not all shown to users. They are used by the process engine.

User-facing language should be simpler:

Getting clear
Needs input
Decision needed
Action in progress
Results coming in
Updated
Closed

5. Event-sourced process kernel

Sortium needs to know not only current state, but how the state changed.

Every meaningful change should be stored as an event.

Example events:

SituationCreated
SignalSubmitted
SignalMapped
AccessEnvelopeCreated
InputRequestCreated
InputRequestAnswered
ContrarianInquiryRequested
WorkstreamCreated
WorkstreamUpdated
SynthesisDrafted
SynthesisAccepted
ProposalDrafted
DecisionRequested
DecisionConfirmed
DecisionRejected
ActionRouted
ActionAccepted
ActionDeclined
ActionBlocked
ResultReported
EvidenceAttached
SharedPictureUpdated
LearningRecorded
DeadlineSet
DeadlineMissed
EscalationTriggered

Why event sourcing matters:

The event log is the source of process truth.

The graph, dashboards, chat cards, and reports are projections from it.

6. Cronos: process clock and escalation kernel

Cronos is a named internal service, not an autonomous manager.

Cronos tracks time, ownership, deadlines, staleness, and escalation.

Cronos may say:

“This input request expires tomorrow.”
“This action has no owner.”
“This decision has been waiting for 48 hours.”
“This workstream is blocked and needs coordinator attention.”

Cronos may not decide:

“Therefore we will do X.”

Consequential state changes still require human confirmation, except for pre-decided low-risk algorithmic flows.

Cronos responsibilities

track deadlines
track review windows
detect stale requests
detect missing owners
detect blocked actions
detect unresolved contradictions
generate reminders
trigger escalation rules
surface process drift
create attention cards

Cronos objects

ProcessRun
ProcessStep
Deadline
ReviewWindow
EscalationRule
AccountableOwner
DecisionGate
Reminder
StalenessSignal

Cronos rule

Cronos is allowed to move attention. Cronos is not allowed to move authority.

7. Coordinated input requests

Sortium should not simply wait for random suggestions.

It should actively create coordinated input requests.

An input request asks a specific person, group, or domain to contribute something useful for a specific reason.

Examples:

Can you verify this source?
Can you identify what could go wrong?
Can your organization confirm availability?
Can this domain group review the risk?
Can someone with local knowledge clarify this?

Request Bundle

A Request Bundle contains:

topic / node / question
why this input is needed
who is being asked
required response shape
deadline
visibility scope
sensitivity level
contrarian requirement
expected downstream use

Request types:

evidence request
local knowledge request
risk / criticism request
partner confirmation request
decision input request
capability check
availability check
domain review
result report

This keeps contribution focused.

Instead of:

“Add anything useful.”

Sortium asks:

“We need someone with building-manager context to confirm whether a trusted check-in channel exists before volunteers are activated.”

8. Contrarian inquiry

Contrarian input should be first-class, but structured.

It should not become debate chaos.

Sortium should explicitly request critique when needed:

What assumption could break this plan?
Who might be harmed or excluded?
What evidence would change our mind?
What privacy risk are we missing?
What could make this action backfire?
What would a skeptical local coordinator object to?

Contrarian inquiry is attached to a node, proposal, decision, or workstream.

It has a purpose, deadline, and review path.

User-facing label options:

Spot a risk
Challenge this assumption
Find what could go wrong
Review before action

Avoid framing it as “argue” or “debate.”

9. AI and accountable human decision-making

AI is a synthesis and guidance layer.

Humans remain accountable for consequential decisions.

AI can

summarize
classify
draft
compare options
detect contradictions
identify missing context
suggest contribution requests
suggest workstreams
suggest owners / candidate pools
explain risks
surface stale process items
prepare decision cards
prepare action briefs
prepare result summaries

AI cannot

approve consequential decisions
assign sensitive work without human confirmation
share sensitive data autonomously
close high-stakes questions
determine official truth
decide who receives aid/support
silently change permissions

Decision pattern

Every consequential move follows:

AI proposal
→ accountable human confirmation
→ logged decision record
→ state transition

Decision records should contain:

decision owner
selected option
reasoning
context used
rejected alternatives
remaining uncertainty
permissions / sharing boundary
timestamp
affected workstreams/actions

Exception: pre-decided algorithms

AI or automation may guide users through a pre-decided algorithm when:

Example:

If a task is overdue by 24h, Cronos sends reminder.
If overdue by 48h, Cronos alerts coordinator.
If still unresolved, coordinator decides whether to reassign.

Automation manages process pressure. Humans decide responsibility changes.

10. Parallelism and autonomous groups

Sortium must support many groups acting independently without fragmenting the shared picture.

The model:

One Situation Object
→ many Workstreams
→ many Contribution Requests
→ many Actions
→ one synthesized shared picture

Workstreams are bounded slices of a situation.

Example:

Situation: Heating outage
Workstream A: Verified information
Workstream B: Vulnerable resident support
Workstream C: Warm spaces
Workstream D: Transport
Workstream E: Communication risk

Each workstream has autonomy inside scope.

But all workstreams report outputs back to the Situation Object.

Workstream fields

situationId
scopeNodeIds
purpose
leadOwnerId
members
roles
permissions
sensitivity level
deadline
output contract
open questions
active requests
actions
status

Output contract

Every workstream should know what it must return:

answer
recommendation
risk review
action result
verified evidence
resource list
decision input
blocker report

This enables parallelism without chaos.

Rule

Workstreams may own local process. They may not fork reality.

The shared situation remains the synthesis layer.

11. Domain groups and domain facades

Some coordination requires niche expertise or sensitive context.

Examples:

These should be modeled as Domain Groups.

A Domain Group is a standing or temporary group responsible for a domain of expertise.

It can receive requests, maintain standards, review proposals, and provide safe outputs.

Domain Group fields

domainId
name
scope
members
stewards
capabilities
permission rules
intake rules
output formats
quality thresholds
related situations

Domain facade

A Domain Facade is the safe public surface of a domain group.

It lets the broader situation use domain knowledge without exposing raw sensitive data.

Example:

Raw sensitive data:
Resident names, addresses, medical details.

Domain facade output:
“Three buildings need support-channel verification. No resident-level details should be shared outside the vulnerable support group.”

Another example:

Raw private partner note:
Partner may have vehicles but cannot publicly commit yet.

Domain facade output:
“Transport capacity is possible but unconfirmed. Request partner confirmation before relying on it.”

This is how Sortium supports niche expertise under one umbrella.

The umbrella is the Situation Object.

The domain facade is the safe interface.

12. Access envelopes and sensitive information

Every request, action, and view should carry an Access Envelope.

An Access Envelope defines:

who can see this
what context they can see
what context is redacted
what they can do
what they can share
what requires approval
expiry / review window
audit requirement

This avoids spreading sensitive data through the system.

Access levels

V1 can use simple levels:

public_within_situation
invited_group
workstream_only
domain_restricted
named_people_only
redacted_summary_only

Principle

Users receive the minimum useful context required to contribute responsibly.

Not zero context.

Not full context.

Useful bounded context.

13. Task assignment and contribution matching

Sortium should avoid generic task assignment language where possible.

Use Contribution Requests and Action Requests.

A Contribution Request asks for input.

An Action Request asks for execution.

Contribution Request fields

requestId
situationId
workstreamId optional
requestType
question / prompt
why_needed
candidatePool
owner optional
deadline
accessEnvelope
sensitivity
expectedOutput
status

States:

drafted
sent
accepted
declined
answered
expired
cancelled
integrated

Action Request fields

actionId
situationId
workstreamId optional
purpose
instruction
owner / candidatePool
allowedContext
expectedResult
deadline
reportingRequirement
fallback / escalation
status

States:

drafted
routed
accepted
declined
blocked
active
reported
completed
cancelled
escalated

Matching factors

Sortium can suggest candidate owners based on:

role
capability
availability
location / local knowledge
language
organization affiliation
trust / verification level
past contribution evidence
sensitivity clearance
motivation / interest
current load

But assignment should remain human-confirmed for sensitive or consequential work.

User-facing options should preserve autonomy:

Accept
Ask a question
Offer smaller help
Suggest someone else
Decline gracefully
Mark unavailable

14. Multi-role users

A user’s role is not global.

The same person can be:

Model:

User
→ OrganizationMembership
→ ProjectMembership
→ SituationRole
→ WorkstreamRole
→ DomainRole
→ Capability / Permission Grants

Permissions are contextual.

Example:

User A may approve communication drafts in Situation 1,
but only contribute evidence in Situation 2,
and steward privacy reviews in Domain Group 3.

UX must show the current role clearly.

Persistent role/context pill:

Viewing as: Coordinator · Heating outage
[Switch]

Switch menu:

Heating outage
- Coordinator
- Contributor

Vulnerable support domain
- Steward

JCI readiness pilot
- Observer

15. Role-specific UX projections

The same Situation Object produces different views.

Contributor view

Question:

What needs my attention, and how can I help safely?

Shows:

Coordinator view

Question:

Is the situation moving responsibly?

Shows:

Steward view

Question:

Is this safe, accurate, and aligned enough to proceed?

Shows:

Organization view

Question:

What is being asked of us, and what can we responsibly contribute?

Shows:

Domain group view

Question:

What requires our expertise, and what safe output should we provide?

Shows:

15A. Context switching without infinite scroll

Sortium must not make users scroll through chat history or giant dashboards to find operational context.

The UX should be built around context packets and attention objects, not endless timelines.

Core pattern

Global Attention Inbox
→ Context Switcher
→ Focus Card
→ Detail Drawer
→ Full History only when requested

1. Global Attention Inbox

The home surface is not a feed. It is a prioritized list of items requiring attention.

Needs your attention
- Decision needed: approve communication draft
- Action report overdue: Building Manager A check
- Domain review requested: privacy boundary
- Input request: transport availability by 17:00

Each item shows:

what it is
why I see it
which role I am in
deadline / urgency
next action buttons

2. Context Switcher

Users move by context, not by scrolling.

Persistent pill:

Viewing as: Coordinator · Heating outage
[Switch]

Switch menu:

My active contexts

Heating outage
- Coordinator: 3 items
- Contributor: 1 item

Vulnerable support domain
- Steward: 2 reviews

JCI readiness pilot
- Observer: 1 update

This solves the multi-role problem. Role is contextual, not global.

3. Focus Card

Every task/request/action opens as a compact Focus Card.

Focus: Contact Building Manager A

Why this matters:
We need to know whether a trusted check-in channel exists before activating volunteers.

Your role:
Local connector

Allowed context:
Heating outage concern. Do not collect resident names.

Needed by:
Today 18:00

Actions:
[Report result] [Ask question] [Pass] [Show background]

The Focus Card replaces scrolling through history.

4. Detail Drawer

If the user needs more, open a drawer with:

Summary
Decision history
Related evidence
Dependencies
People involved
Sensitive boundaries
Full audit trail

Default should be summary, not history.

5. Search / ask instead of scroll

Every context supports:

Ask Sortium:
- Why am I assigned this?
- What changed since yesterday?
- What is blocked?
- Show decisions behind this.
- What can I safely share?
- Find the last report from Anna.

Search should retrieve structured objects, not just messages.

6. Object timeline, not chat scroll

Chat is useful for interaction, but operational memory should live on objects.

Each object has a short activity timeline:

Decision confirmed → Action routed → Anna accepted → Result reported → Shared picture updated

Users should rarely need to read full chat history.

Design rule

Sortium should behave like a calm operational inbox with conversational help, not like a Slack channel where truth is buried upstream.

15B. Should Steward and Organization be one view?

Steward and Organization can share one Oversight View in V1, but they should remain separate lenses inside the data model.

The user is right that they can feel similar in early UX. Both ask:

Is this healthy?
Is something waiting on us?
Are there risks, decisions, or commitments?

But they differ in accountability.

Steward lens

The Steward lens protects quality, safety, truth, and domain integrity.

It asks:

Is this accurate enough?
Is this safe enough?
Does this respect privacy and domain standards?
Should this be verified, contested, merged, or blocked?

Typical objects:

review queues
contested claims
sensitive access boundaries
domain standards
evidence quality
proposal safety

Organization lens

The Organization lens protects capacity, commitments, and representation.

It asks:

What is being asked of our organization?
What have we committed to?
Do we have capacity?
Who can represent us?
What outcomes did our contribution produce?

Typical objects:

incoming requests
accepted commitments
capacity
organizational boundaries
partner responses
outcomes

V1 recommendation

Fold both into one UI shell:

Oversight
[Quality & Safety] [Org Commitments] [Domain Requests] [Blocked / At Risk]

But keep them distinct as lenses:

Steward = can this proceed safely / correctly?
Organization = can we commit / represent / resource this?

This reduces UI complexity while preserving the architecture.

Example combined Oversight screen

Oversight · Heating outage

Needs attention
1. Privacy review needed before volunteer call list
   Lens: Steward / Quality & Safety
   [Review]

2. JCI Latvia asked to provide 3 bilingual callers
   Lens: Organization / Commitments
   [Accept partial] [Ask capacity] [Decline]

3. Communication draft waiting for approval
   Lens: Steward + Organization
   [Approve] [Edit] [Request translation]

So: no, you are not wrong. In the first product, they should likely be folded into one Oversight area with lens tabs. The separation matters mostly for permissions, accountability, and future scaling.

16. Chat-first UX model

Chat should be the default operating surface, but not the whole product.

Chat answers:

What needs my attention now?
What should I do next?
Why does it matter?

Supporting views answer:

How does this fit into the larger process, team, domain, or situation?

Chat should handle

task intake
clarifying questions
status updates
what changed summaries
handoffs
next-step suggestions
quick decisions
reminders
report-back flows

Chat should not handle alone

large process maps
cross-project portfolio views
domain health
audit trails
complex risk analysis
bulk backlog management

Structured chat cards

Chat responses should include cards, not only prose.

Example:

Sortium:
You have 2 items needing attention.

[Input Request]
Question: Can you verify whether Building A has a trusted check-in channel?
Why you: You know the building manager.
Due: Today 17:00
Context: Do not collect resident names.
[Answer] [Ask context] [Pass]

[Decision Needed]
Proposal: Draft LV/RU calm info note before activating volunteers.
Risk: avoid panic and duplicate calls.
[Approve] [Edit] [Ask steward]

Chat is the conversational skin over structured process objects.

17. Folding complexity across task sets

Use progressive disclosure aggressively.

Fold level 1: Pulse

Situation pulse
Status: Needs decision
Attention needed: 3
Blocked: 1
Recent movement: 5 updates
Next deadline: Today 18:00

Fold level 2: Lanes

Input needed
Decisions
Actions
Blocked
Results
Learning

Fold level 3: Clusters

Vulnerable resident support
Communication
Transport
Warm spaces
Verified information

Fold level 4: Requests/actions

Verify building-manager channel
Draft calm info note
Confirm transport availability

Fold level 5: Full context

history
dependencies
decisions
evidence
permissions
audit trail

Default UX should start at Level 1 or 2.

Deep structure appears only when needed.

18. Clever UX tricks to keep Sortium simple

1. Attention inbox

Separate ownership from attention.

A person may own 30 things, but only 3 need attention today.

Needs your attention
- 1 decision
- 1 overdue report
- 1 request you can answer quickly

2. Collapse to next action

Every complex process can collapse to one next move.

Next best action:
Ask Anna to confirm whether Building B has a trusted contact route.

[Do it] [Show why] [Show full context]

3. Why am I seeing this?

Every card explains relevance.

You are seeing this because you are steward for vulnerable resident support and this proposal touches privacy boundaries.

4. Mode switch

Mode: [Focus] [Overview] [Deep Work] [Review]

5. Process breadcrumbs

Situation → Workstream → Request → Action → Result

Example:

Heating outage → Vulnerable support → Verify support route → Contact manager → Report result

6. Ask Sortium

Every view supports natural language:

What is blocked?
Who needs to decide?
What changed today?
Show only my actions.
What is sensitive here?
What can I safely share?

7. Impact receipts

After contribution:

Your input helped identify a privacy risk before volunteers were activated.

Or:

Your report changed the next action: Building B now needs an alternative contact route.

This gives motivation without gamified pressure.

19. Recognition and gamification

Sortium should use recognition, not pressure.

Avoid:

Use:

closed-loop receipts
thank-you prompts
quiet badges for contribution quality
team impact summaries
personal progress against accepted commitments

Examples:

You closed the loop on 3 handoffs this week.
Your review prevented a privacy issue.
Anna’s report helped update the shared picture. Send thanks?

Recognition should feel like sunlight, not surveillance.

20. Full example: heating outage

Situation

District heating is down during a cold week.
The group wants to coordinate safe support without panic, duplication, or privacy violations.

Sortium creates:

Situation: Heating outage support
State: emerging
Known: outage reported
Unknown: repair timeline, affected buildings, vulnerable resident support channels
Risk: panic messaging, privacy leakage, duplicate calls
Next step: gather verified situation and safe support channels

Signals

Inputs arrive:

Municipality posted a repair estimate.
Vague reassurance may make people stop checking elderly neighbors.
I can call people in Latvian/Russian after 17:00.
Building managers may already know who needs help.

Sortium maps them as:

evidence candidate
communication risk
volunteer offer
stakeholder route

Synthesis

Known:
- Heating outage reported.

Unclear:
- Exact repair timeline.
- Which buildings are most affected.
- Whether trusted support channels exist.

Risks:
- Panic.
- Privacy leakage.
- Duplicate welfare calls.

Possible workstreams:
- Verified information.
- Vulnerable resident support.
- Communication.
- Volunteer activation.

Coordinated input request

Sortium creates a Request Bundle:

Request:
Confirm whether building managers already have trusted check-in channels.

Why:
Before activating volunteers, the group needs a privacy-safe support route.

Asked of:
Local contact / coordinator.

Deadline:
Today 17:00.

Access envelope:
Do not collect resident names, addresses, or medical details.

Expected output:
Yes/no per building + recommended next contact path.

Contrarian inquiry

Sortium asks the communication steward:

What could go wrong if we publish a general support call now?

Answer:

People may share unverified messages, duplicate calls, or expose resident details.

Proposal

Sortium drafts:

Proposal:
Contact two building managers before creating a volunteer call list.

Why:
This checks existing trusted channels and avoids direct collection of sensitive resident data.

Shared context:
Heating outage concern and need for safe coordination.

Private boundary:
No resident-level data should be collected.

Decision owner:
Coordinator.

Decision

Coordinator confirms.

Decision record:

Decision:
Use building-manager-first route before volunteer activation.

Reason:
Privacy-preserving and lower panic risk.

Action

Action:
Contact Building Manager A and B.

Owner:
Anna.

Expected result:
Confirm whether trusted check-in channels exist.

Report by:
18:00.

Result

Anna reports:

Building A has a WhatsApp group.
Building B has no contact route.
Manager requested calm LV/RU info note.

Updated shared picture

Changed:
- Building A has existing channel.
- Building B needs an alternative route.
- Calm LV/RU info note is useful before wider volunteer activation.

Next action:
Draft multilingual info note and confirm distribution boundary.

Learning

Building-manager-first route reduced privacy risk.
Multilingual templates should be prepared in advance.
Volunteer caller pool should activate only after trusted channel check.

This is the complete Sortium loop.

21. V1 build sequence

Build one complete vertical slice instead of many partial views.

Milestone 1: Process kernel

Implement:

SituationObject
EventLog
StateMachine
Signal
AccessEnvelope

Success test:

Can the system record how a situation evolved?

Milestone 2: Requests and Cronos

Implement:

ContributionRequest
RequestBundle
Deadline
Cronos reminders
Escalation rules

Success test:

Can Sortium request the right input from the right person by the right time?

Milestone 3: Workstreams and domain facades

Implement:

Workstream
DomainGroup
DomainFacade
RedactedProjection

Success test:

Can parallel groups work independently while returning safe outputs to one shared situation?

Milestone 4: Proposals, decisions, actions

Implement:

Proposal
Decision
ActionRequest
Action lifecycle
Human confirmation

Success test:

Can a synthesized need become an accountable action without AI becoming the decisionmaker?

Milestone 5: Results, evidence, learning

Implement:

ResultReport
Evidence
Blocker
SharedPictureUpdate
LearningRecord

Success test:

Does every action return evidence, blocker, or learning into the shared picture?

Milestone 6: Role-specific UX projections

Implement simple views:

Contributor attention inbox
Coordinator situation pulse
Steward review queue
Domain group request inbox
Shared picture

Success test:

Does each role know only what they need to know and what to do next?

22. Minimum V1 object list

Start with these:

User
Organization
SituationObject
Event
GraphNode
AccessEnvelope
ContributionRequest
Workstream
DomainGroup
DomainFacade
Proposal
Decision
ActionRequest
ResultReport
Evidence
LearningRecord
Deadline
EscalationRule

Do not begin with the full future ontology.

The first implementation should prove the loop.

23. Final architecture statement

Sortium V1 should be a simple UX over a serious process engine.

The UX says:

Here is what needs attention.
Here is why it matters.
Here is what you can safely do.
Here is what changed.

The engine manages:

time
ownership
permissions
parallel work
structured critique
AI-assisted synthesis
human-confirmed decisions
action accountability
evidence
learning

That is the path that keeps Sortium powerful without making it complicated.

24. Source context

This architecture synthesizes:

It also integrates the latest founder feedback on: