# 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: ```text messy reality + scattered human input + distributed capabilities ``` into: ```text 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: ```text Situation → Signals → Synthesis → Contribution Requests → Workstreams → Proposals → Decisions → Actions → Results / Evidence / Blockers → Updated Shared Picture → Learning → Next Cycle ``` Short form: ```text 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: - understand what is happening; - identify what is known, unknown, risky, or contested; - request the right input from the right people; - organize parallel work without fragmenting reality; - use AI for synthesis and guidance; - keep humans accountable for decisions; - route action safely; - collect results and evidence; - preserve learning for future coordination. 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: ```text 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: ```text 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: ```text [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: - “Heating outage may affect elderly residents.” - “JCI Latvia wants to contribute to civil resilience.” - “A community center could become a crisis support point.” - “An NGO has volunteers but no clear activation process.” - “A partner request arrived, but ownership and contribution paths are unclear.” A Situation Object contains: ```text 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 ```text 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: ```text 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: ```text 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: - auditability; - accountability; - replayable history; - learning from previous loops; - safe correction of mistakes; - role-specific projections; - visible rationale behind decisions. 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 ```text 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 ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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 ```text 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 ```text 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: ```text AI proposal → accountable human confirmation → logged decision record → state transition ``` Decision records should contain: ```text 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: - the process was explicitly approved beforehand; - the steps are low-risk or bounded; - no sensitive disclosure is made automatically; - escalation exists when confidence is low; - the user can stop or ask for human review. Example: ```text 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: ```text One Situation Object → many Workstreams → many Contribution Requests → many Actions → one synthesized shared picture ``` Workstreams are bounded slices of a situation. Example: ```text 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 ```text 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: ```text 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: - medical support; - vulnerable resident outreach; - legal/privacy review; - logistics; - language/translation; - municipal coordination; - cybersecurity; - local building knowledge; - communications/public messaging. 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 ```text 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: ```text 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: ```text 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: ```text 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: ```text 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 ```text requestId situationId workstreamId optional requestType question / prompt why_needed candidatePool owner optional deadline accessEnvelope sensitivity expectedOutput status ``` States: ```text drafted sent accepted declined answered expired cancelled integrated ``` ### Action Request fields ```text actionId situationId workstreamId optional purpose instruction owner / candidatePool allowedContext expectedResult deadline reportingRequirement fallback / escalation status ``` States: ```text drafted routed accepted declined blocked active reported completed cancelled escalated ``` ### Matching factors Sortium can suggest candidate owners based on: ```text 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: ```text 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: - contributor in one situation; - coordinator in another; - steward in a domain group; - observer in an organization; - partner representative in a workstream; - sensitive-data eligible only for a narrow context. Model: ```text User → OrganizationMembership → ProjectMembership → SituationRole → WorkstreamRole → DomainRole → Capability / Permission Grants ``` Permissions are contextual. Example: ```text 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: ```text Viewing as: Coordinator · Heating outage [Switch] ``` Switch menu: ```text 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: ```text What needs my attention, and how can I help safely? ``` Shows: - short situation brief; - why I was invited; - my requested input/actions; - context boundary; - accept / ask / pass / offer smaller help; - report-back flow; - impact receipt. ### Coordinator view Question: ```text Is the situation moving responsibly? ``` Shows: - current synthesis; - open decisions; - missing owners; - overdue requests; - blocked workstreams; - actions in progress; - results waiting synthesis; - next best coordination move. ### Steward view Question: ```text Is this safe, accurate, and aligned enough to proceed? ``` Shows: - items needing review; - contested assumptions; - sensitive-sharing risks; - domain standards; - evidence quality; - proposals needing approval; - integration decisions. ### Organization view Question: ```text What is being asked of us, and what can we responsibly contribute? ``` Shows: - requests to the organization; - commitments made; - available capacity; - boundaries; - outcomes from org actions; - unresolved partner decisions. ### Domain group view Question: ```text What requires our expertise, and what safe output should we provide? ``` Shows: - incoming domain requests; - active domain workstreams; - standards/templates; - sensitive material if permitted; - facade outputs; - cross-situation patterns. --- ## 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 ```text 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. ```text 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: ```text 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: ```text Viewing as: Coordinator · Heating outage [Switch] ``` Switch menu: ```text 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. ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text incoming requests accepted commitments capacity organizational boundaries partner responses outcomes ``` ### V1 recommendation Fold both into one UI shell: ```text Oversight [Quality & Safety] [Org Commitments] [Domain Requests] [Blocked / At Risk] ``` But keep them distinct as lenses: ```text 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 ```text 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: ```text What needs my attention now? What should I do next? Why does it matter? ``` Supporting views answer: ```text How does this fit into the larger process, team, domain, or situation? ``` ### Chat should handle ```text task intake clarifying questions status updates what changed summaries handoffs next-step suggestions quick decisions reminders report-back flows ``` ### Chat should not handle alone ```text 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: ```text 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 ```text Situation pulse Status: Needs decision Attention needed: 3 Blocked: 1 Recent movement: 5 updates Next deadline: Today 18:00 ``` ### Fold level 2: Lanes ```text Input needed Decisions Actions Blocked Results Learning ``` ### Fold level 3: Clusters ```text Vulnerable resident support Communication Transport Warm spaces Verified information ``` ### Fold level 4: Requests/actions ```text Verify building-manager channel Draft calm info note Confirm transport availability ``` ### Fold level 5: Full context ```text 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. ```text 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. ```text 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. ```text You are seeing this because you are steward for vulnerable resident support and this proposal touches privacy boundaries. ``` ### 4. Mode switch ```text Mode: [Focus] [Overview] [Deep Work] [Review] ``` - Focus: next actions only. - Overview: situation health. - Deep Work: assigned work. - Review: decisions, approvals, quality checks. ### 5. Process breadcrumbs ```text Situation → Workstream → Request → Action → Result ``` Example: ```text Heating outage → Vulnerable support → Verify support route → Contact manager → Report result ``` ### 6. Ask Sortium Every view supports natural language: ```text 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: ```text Your input helped identify a privacy risk before volunteers were activated. ``` Or: ```text 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: - public leaderboards; - streaks; - productivity scores; - shame indicators; - response-speed competition; - ranking contributors. Use: ```text closed-loop receipts thank-you prompts quiet badges for contribution quality team impact summaries personal progress against accepted commitments ``` Examples: ```text You closed the loop on 3 handoffs this week. ``` ```text Your review prevented a privacy issue. ``` ```text Anna’s report helped update the shared picture. Send thanks? ``` Recognition should feel like sunlight, not surveillance. --- ## 20. Full example: heating outage ### Situation ```text District heating is down during a cold week. The group wants to coordinate safe support without panic, duplication, or privacy violations. ``` Sortium creates: ```text 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: ```text 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: ```text evidence candidate communication risk volunteer offer stakeholder route ``` ### Synthesis ```text 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: ```text 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: ```text What could go wrong if we publish a general support call now? ``` Answer: ```text People may share unverified messages, duplicate calls, or expose resident details. ``` ### Proposal Sortium drafts: ```text 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: ```text Decision: Use building-manager-first route before volunteer activation. Reason: Privacy-preserving and lower panic risk. ``` ### Action ```text 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: ```text Building A has a WhatsApp group. Building B has no contact route. Manager requested calm LV/RU info note. ``` ### Updated shared picture ```text 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 ```text 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: ```text SituationObject EventLog StateMachine Signal AccessEnvelope ``` Success test: ```text Can the system record how a situation evolved? ``` ### Milestone 2: Requests and Cronos Implement: ```text ContributionRequest RequestBundle Deadline Cronos reminders Escalation rules ``` Success test: ```text Can Sortium request the right input from the right person by the right time? ``` ### Milestone 3: Workstreams and domain facades Implement: ```text Workstream DomainGroup DomainFacade RedactedProjection ``` Success test: ```text Can parallel groups work independently while returning safe outputs to one shared situation? ``` ### Milestone 4: Proposals, decisions, actions Implement: ```text Proposal Decision ActionRequest Action lifecycle Human confirmation ``` Success test: ```text Can a synthesized need become an accountable action without AI becoming the decisionmaker? ``` ### Milestone 5: Results, evidence, learning Implement: ```text ResultReport Evidence Blocker SharedPictureUpdate LearningRecord ``` Success test: ```text Does every action return evidence, blocker, or learning into the shared picture? ``` ### Milestone 6: Role-specific UX projections Implement simple views: ```text Contributor attention inbox Coordinator situation pulse Steward review queue Domain group request inbox Shared picture ``` Success test: ```text Does each role know only what they need to know and what to do next? ``` --- ## 22. Minimum V1 object list Start with these: ```text 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: ```text Here is what needs attention. Here is why it matters. Here is what you can safely do. Here is what changed. ``` The engine manages: ```text 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: - `SORTIUM_PRD_PREP_SOURCE_OF_TRUTH.md` - `SORTIUM_SEMANTIC_PROCESS_AGENT_FOUNDATION.md` - `SORTIUM_SITUATION_OBJECT_PROCESS_FLOW.md` - `SORTIUM_INITIATIVE_COLLABORATION_MECHANISMS.md` - `SORTIUM_CORE_PRODUCT_CLARITY.md` - `SORTIUM_GRAPH_CHALLENGE_SPACE_MODEL.md` - `SORTIUM_FULL_FLOW_ARCHITECTURE_REPORT.md` - `docs/SORTIUM_SCHEMA_AND_SEED_V1.md` - `docs/SORTIUM_CONTEXT_AND_LLM_SPEC_V1.md` - `docs/SORTIUM_TECHNICAL_ARCHITECTURE_V1.md` It also integrates the latest founder feedback on: - Cronos/process ownership; - coordinated input requests; - contrarian inquiry; - AI vs accountable human decision-making; - parallel autonomous groups; - sensitive access and subgroup/domain facades; - multi-role users; - chat-first UX; - simple folded views; - low-pressure recognition.