Sókrates Wiki

Sókrates User Stories — Engineering Backlog (v1)

25 min read

Sókrates User Stories — v1

Conventions

  • Personas are generic; systems are specific and named (Dynamics 365, Salesforce, SAP Business One, Stripe, Vitinn, etc.).
  • MCP connectors referenced as {vendor}-mcp.
  • “Eidos” = the graph + semantic control plane. “Hyle” = the ingestion pipeline. “Sókrates” = the Demiurge agent.
  • Each story has: scenario, acceptance criteria, architectural notes (exercises + gaps), and open questions where relevant.
  • “Probably doesn’t fully exist yet” flags are my read from the architecture docs — worth validating against actual repo state.

Phase 1: Day-1 to Month-6 arc

Story 1 — Cold-start onboarding

As the operations lead at a 55-person fintech running Dynamics 365 Business Central and Salesforce Financial Services Cloud, I want to authorize Sókrates’s first MCP connections and see the graph populate with my operational topology, so that within 72 hours of appliance arrival I have a legible map of my business.

Scenario

  • DGX Spark arrives, installed on-prem, bootstrap from Nix flake completes.
  • Ops lead authorizes first connections: dynamics365-mcp (read scopes: Customers, Items, Purchase Orders, Sales Orders, Invoices), salesforce-mcp (read scopes: Accounts, Contacts, Opportunities, Cases).
  • Hyle fetches OpenAPI specs from both systems.
  • DMCG generates Pydantic models inheriting from BaseNode with the @node(source="discovered", spec_origin=…) decorator.
  • Classifier adapter on local Gemma 4 31B categorizes each schema into Entity / Process / Law / Observation.
  • Ambiguous classifications (e.g., Dynamics ApprovalWorkflow — Process or Law?) are flagged for review.
  • Ops lead works through ~12 ambiguous classifications in a single 30-minute review session.
  • Eidos populated with ~400 typed nodes plus inferred cross-system edges (e.g., Dynamics Customer ↔ Salesforce Account via resolved join keys).

Acceptance criteria

  • Onboarding time from box-arrival to “ops lead has viewable graph” ≤ 72 hours on a system with ≤ 20 OpenAPI resources per source.
  • Classification ambiguity rate < 15% of schemas on first pass for standard fintech stacks.
  • Cross-system entity resolution achieves ≥ 90% precision on join keys with obvious conventions (name match, VAT match, email match).
  • The review UI for ambiguous classifications works without requiring the operator to drop into CLI.
  • Every node in the resulting graph has a Demiurge at the head of its SHAPES / INSTITUTES / AUTHORS / WITNESSES edge — no unsourced nodes.

Architectural notes

  • Exercises: Hyle full pipeline, DMCG integration, classifier adapter, Eidos graph population, cross-system edge inference, Demiurge provenance tagging.
  • Probably doesn’t fully exist yet: the human review UI for classification ambiguity (likely CLI-only today), and the automatic Demiurge provenance tagging if that was added after the Hyle doc was written.
  • Open question: what’s the canonical surface for classification review? Slack/Teams DM with Sókrates? A web UI on the appliance? An operator console?

Story 2 — First proactive discovery

As the CFO of the same fintech (now in week 2), I want Sókrates to surface an operational pattern I didn’t ask about, so that I see the “proactive” in “proactive workflow discovery” is structural, not marketing.

Scenario

  • Sókrates runs discovery hyperedges across the populated graph on a schedule.
  • Finding: 23% of invoices to top-tier customers are paid 15+ days late, and of those, 90% were issued on the 1st of the month rather than mid-month.
  • Sókrates composes a Layer 2 hyperedge: late_payment_correlation_with_invoice_timing, referencing Layer 1 hyperedges for (a) customer-tier by ARR, (b) invoice-issue-date distribution, (c) DSO per customer-tier.
  • Drafts a finding: “Customers X, Y, Z pay an average of 18 days late when invoiced on the 1st. Moving their billing cycle to the 15th would likely reduce DSO by ~12 days. Evidence: [links to the underlying query result].”
  • Surfaces the finding via whatever UI the customer chose (Slack / Claude Teams / Vitinn / standalone Teams).

Acceptance criteria

  • First proactive finding surfaced within 14 days of graph population.
  • Finding includes: observation, supporting data (queryable and inspectable), recommended action, confidence level.
  • Finding is generated by a learned discovery adapter, not hard-coded rules — the same machinery that finds billing-timing issues in a fintech finds BOM margin issues in a manufacturer.
  • Finding can be dismissed, acted upon, or deferred. Each outcome is a PERFORMED edge with outcome annotation.

Architectural notes

  • Exercises: analyst adapter, hyperedge composition (Layer 1 → Layer 2), proactive-discovery scheduler.
  • Probably doesn’t fully exist yet: the proactive-discovery adapter and the scheduler that runs it. The discovery loop needs a clear definition — what triggers it, what it looks for, how broad it ranges.
  • Open question: how opinionated is first-pass discovery? Canonical patterns (DSO, dormant customers, margin leakage) first? Or does it range freely over combinatorial compositions?

Story 3 — First autonomous action

As the sales director at the same fintech (now week 4), I want Sókrates to take its first autonomous action on my behalf, so that I feel the difference between “Sókrates tells me things” and “Sókrates does things.”

Scenario

  • Sókrates finds three top-revenue customers with no sales-rep touchpoint in 180+ days.
  • Authorization check: does Sókrates have an AUTHORIZES edge permitting draft_outreach_email for this rep? Yes — granted during onboarding by the sales director.
  • Sókrates drafts three personalized emails, grounded in actual account history, recent product changes, and industry context — all read via MCP.
  • Drafts appear in the relevant rep’s inbox (standalone) or approval queue (Claude Teams / Vitinn / Slack) as “awaiting review.”
  • Rep approves one, edits and approves another, dismisses the third with a reason.
  • Each outcome logged as a PERFORMED edge with outcome annotation.

Acceptance criteria

  • Email drafts are personalized — reference specific past interactions, not boilerplate.
  • Each draft cites its graph-grounded evidence; rep can click through to see why Sókrates thinks this customer is dormant.
  • Rep’s edit-before-send pattern is learnable — the drafting adapter adapts based on accepted edits over time.
  • Dismissal with a reason (“we actually had a call last week that wasn’t logged”) can optionally update the source-system record and adjusts Sókrates’s trust-surface calculation for similar future cases.

Architectural notes

  • Exercises: authorization subgraph query, drafting adapter, CRM write-back (optional, gated by separate authorization), approval UI per surface, PERFORMED edge logging with outcome.
  • Probably doesn’t fully exist yet: the rep-approval UI in each integration surface (Claude Teams, Vitinn, Slack, Teams standalone). Each surface needs its own approval flow.
  • Open question: what does “learnable from edits” mean technically? QLoRA fine-tune on accepted edits? In-context example injection? Both? Worth a separate design conversation.

Story 4 — Envelope widens at week 12

As the ops lead at the same fintech (three months in), I want to widen Sókrates’s authorization envelope based on demonstrated track record, so that the department takes on more work without me approving every action.

Scenario

  • By week 12, Sókrates has drafted 47 outreach emails (41 approved, 6 dismissed) with no bad outcomes.
  • Sókrates proactively proposes: “I’ve drafted and had approved 41 consecutive outreach emails without rework beyond minor tone edits. Would you like me to auto-send for low-risk categories (existing customer, single-topic, no commitments made)? You can revoke this authorization at any time.”
  • Ops lead accepts with one modification: no auto-send to customers with > 10M ISK ARR without rep sign-off.
  • A new AUTHORIZES edge is created with the modification encoded as a Law node constraining it.
  • Sókrates’s trust-surface generating query updates automatically.

Acceptance criteria

  • Sókrates proactively proposes envelope widening based on track-record metrics — not on a schedule, not on operator request.
  • Proposal is framed in reversible terms and constrained by default.
  • Operator modifications to the proposed envelope are captured as additional Law nodes, composable with existing authorizations.
  • New trust surface is live within seconds of operator approval.
  • A generating query can return “what is Sókrates currently authorized to do?” at any time, and the answer reflects the current edge state.

Architectural notes

  • Exercises: governance adapter, authorization-subgraph write, Law node composition, trust-surface generating query.
  • Probably doesn’t fully exist yet: the “propose envelope widening” logic. Needs a clear rubric — which track-record thresholds trigger a proposal? What’s the default caution parameter?
  • Core architectural commitment: this story cements that governance is graph structure. If it works cleanly, the whole “retainer compounds through envelope growth” thesis is live.

Phase 2: Workflow vignettes

Story 5 — Negative BOM margin detected and acted upon

As the procurement lead at a 60-person manufacturer running SAP Business One and a custom supplier portal, I want Sókrates to notice when a BOM item goes negative-margin and draft supplier renegotiation requests, so that pricing drift doesn’t silently erode margin for a quarter before anyone catches it.

Scenario

  • sap-mcp surfaces a cost update on ComponentSKU_471 — supplier raised the price 12%.
  • The cost-update event triggers Sókrates’s BOM-margin hyperedge evaluation.
  • Layer 1: SKUs with latest-cost > active-quote-price. Layer 1: SKUs actually moving this quarter (volume > 0). Layer 2 intersection returns ComponentSKU_471 and four others.
  • Sókrates reads the relevant supplier contract via supplier-portal-mcp. Contract expires in 8 weeks. Previous negotiation reduced price by 4%. The manufacturer has competing vendor quotes in the past 12 months for two of the five affected SKUs.
  • Sókrates drafts five renegotiation emails grounded in these specifics.
  • Opens five quoting-system price-correction proposals (proposal only — auto-apply is a separate authorization).
  • Logs findings + drafted actions + proposals in the procurement lead’s review queue.

Acceptance criteria

  • Cost-change-triggered hyperedge evaluation completes within 10 minutes of the source-system update.
  • Supplier contract terms are actually read from the portal — not inferred, not hallucinated.
  • Renegotiation drafts cite specifics: previous negotiation history, competitor quotes, contract expiration.
  • Quoting-system price-correction proposals are created even if auto-apply is not authorized — they show up as reviewable artifacts.
  • Every drafted email and every proposal links to the hyperedge evaluation that produced it.

Architectural notes

  • Exercises: change-triggered hyperedge evaluation, cross-system read, drafting adapter with document-grounding, quoting-system MCP write (proposal mode), evidence-linking UI.
  • Probably doesn’t fully exist yet: event-triggered hyperedge evaluation (as opposed to scheduled). Needs webhook / polling / change-feed infrastructure per MCP connection.
  • Open question: how does the system distinguish “routine cost update, log and move on” from “threshold-crossing, act”? Threshold should be data-driven (distribution of historical cost moves), not hard-coded.

Story 6 — Three-system customer reconciliation with auto-write-back

As the CFO of a 45-person logistics company running Dynamics 365, a custom TMS, and Stripe, I want Sókrates to notice when the same customer has inconsistent records across systems and reconcile them, so that my AR team stops spending 20% of their week on “which system is right.”

Scenario

  • Nightly reconciliation hyperedge runs at 02:00.
  • Finds: customer Acme Logistics ehf has:
    • Dynamics: "Acme Logistics ehf", VAT IS5501020890, billing address A
    • TMS: "ACME LOGISTICS", VAT 550102-0890, billing address B (newer per timestamp)
    • Stripe: "Acme Logistics Iceland", VAT blank, billing address A
  • Analyst adapter inference: these are the same entity. VAT normalizes to match. Newest billing address is B. Canonical name form is Dynamics’s "Acme Logistics ehf".
  • Sókrates proposes corrections: update TMS name to canonical form, update Dynamics and Stripe billing addresses to B, populate Stripe VAT.
  • Proposes the reconciliation as a single typed Reconciliation Process node with inputs from all three systems and Sókrates as the Demiurge at its head.
  • AR lead reviews, approves.
  • Sókrates writes to all three systems via their respective MCP connections. Logs PERFORMED edges under the Reconciliation Process.

Acceptance criteria

  • Reconciliation is a single typed graph Process, not three separate write operations.
  • Audit trail is queryable: “show me all three-system reconciliations done on Acme in the past year” returns a clean result.
  • If any write-back fails (e.g., Stripe API error), the whole Reconciliation is marked failed; successful writes are not rolled back (idempotency); the failure is re-runnable from the same Process node.
  • The analyst adapter’s canonical-value inference is inspectable — AR lead can see why Sókrates chose address B over A.

Architectural notes

  • Exercises: entity-resolution adapter, canonical-value inference, multi-system write coordination, typed Reconciliation Process node.
  • Probably doesn’t fully exist yet: the typed Reconciliation Process as a first-class graph construct, and the multi-write coordinator with its idempotency / re-run semantics. This is a substantial engineering chunk.
  • Open question: is a Reconciliation one Process per entity-triplet, or one Process per canonical-value-correction? Matters for audit graph shape and granularity of rollback-ability.

Story 7 — Approval chain bottleneck restructuring

As the COO of a 45-person service company running a custom workflow system, I want Sókrates to notice that purchase-order approval chains consistently bottleneck at one approver, so that I can restructure without running a separate process-mining project.

Scenario

  • After 4 months of deployment, Sókrates has observed ~380 purchase orders moving through approval.
  • A longitudinal Layer 2 hyperedge approval_chain_bottleneck_analysis composes over: (a) PO processing time per stage, (b) approver response time distribution, (c) value-vs-approval-depth correlation, (d) approver modification rate.
  • Finding: POs over 500k ISK traverse 4 approvers when policy only requires 2. The 3rd approver (budget holder) approves 94% of requests without modification but adds an average 2.3 days.
  • Sókrates drafts a recommendation: “Remove step 3 for POs with [conditions]. Current median time 4.1 days → estimated 1.8 days. Approver accuracy in the removed step: 94% pass, 6% modified, 0% rejected, across N=380 observations.”
  • Sókrates does not auto-restructure — authorization changes require explicit COO sign-off.

Acceptance criteria

  • Recommendation cites real data, is inspectable, frames the tradeoff quantitatively.
  • If approved, the authorization-subgraph change is auditable forever: “when did we remove this approval step, who approved it, what was the evidence?”
  • Sókrates tracks outcomes post-change: did approval accuracy hold? Did cycle time actually drop? Do we need to revert?

Architectural notes

  • Exercises: longitudinal hyperedge composition, process-mining analyst adapter, authorization-subgraph proposal, post-change outcome tracking.
  • Probably doesn’t fully exist yet: authorization-subgraph modification as a first-class proposal type. This might need its own product surface.
  • Open question: how does Sókrates know to compose this particular Layer 2 hyperedge at month 4 rather than month 1? Is there a meta-pattern of “look for bottlenecks once you’ve observed N instances of a Process”? Feels like there should be.

Phase 3: Governance stories

Story 8 — Bad action caught, envelope narrowed

As the CEO of a customer in month 5, I want to understand what happens when Sókrates does something I don’t like, so that I know the envelope tightens rather than me losing control.

Scenario

  • Sókrates auto-sends an outreach email to a customer who had explicitly requested “no automated communications” in a free-text CRM note Sókrates failed to interpret as a preference.
  • Customer complains. Sales rep flags the outreach as a bad action via the approval UI.
  • Sókrates logs the bad outcome on the relevant PERFORMED edge.
  • Trust-surface generating query recalculates. Auto-send envelope narrows on CRM accounts with any free-text notes matching a broader pattern-match.
  • Sókrates proposes a new Law node: “Do not auto-send to accounts with free-text notes matching [pattern]; require rep approval instead.” CEO approves.
  • Sókrates proposes a remediation sweep: “Flag all CRM accounts with similar free-text patterns retrospectively, so we can review and correct any other historical auto-sends.” CEO approves. Sweep runs.
  • Sókrates drafts an apology email to the affected customer for the CEO to send.

Acceptance criteria

  • Bad action is recorded on graph structure, not in a separate incident-log.
  • Envelope narrowing is automatic in response to the bad-outcome flag — within minutes, not hours.
  • Proposed new Law node is inspectable and modifiable — CEO can edit the pattern before approving.
  • Retrospective sweep for similar patterns is offered proactively.
  • The entire incident is a connected subgraph: flag → bad-outcome edge → trust-surface recalculation → Law proposal → remediation Process → apology draft. A single query returns the whole chain.

Architectural notes

  • Exercises: bad-outcome flagging UI (per integration surface), trust-surface recalculation, Law node proposal, retrospective remediation Process.
  • Probably doesn’t fully exist yet: the “flag this action as bad” surface integrated into each environment, and the automatic envelope-narrowing logic that fires on the flag.
  • Core architectural commitment: this story proves that governance is not “configure careful guardrails once” but “guardrails are graph structure that tighten in response to evidence.” If this works, the CEO-facing governance pitch from Story 4 is structurally complete.

Story 9 — Envelope cannot grow past a Law

As the compliance officer at a regulated fintech, I want to be able to author Law nodes that Sókrates cannot propose to widen past, so that regulatory obligations are enforced structurally, not by policy-reminder.

Scenario

  • Compliance officer authors a Law: NO_AUTOSEND_FINANCIAL_ADVICE_CLASS — “Sókrates will never auto-send any communication classified as containing financial advice, regardless of track record.”
  • Six months pass. Sókrates has a strong track record drafting customer communications. Auto-send envelope widens in several categories.
  • Sókrates’s governance adapter evaluates “should I propose auto-send for the financial-advice category?” — the generating query that produces widening proposals checks all active Laws.
  • The compliance Law matches; the widening proposal is suppressed before it ever surfaces.
  • Compliance officer can run a generating query: “show me which potential envelope-widenings were suppressed by this Law in the past month.”

Acceptance criteria

  • Laws authored by sufficiently-privileged Demiurges constrain the generating queries that produce widening proposals — structurally, not by separate policy-engine.
  • Suppressed proposals are queryable for audit.
  • Law hierarchy is explicit — a Demiurge cannot author a Law that overrides another Demiurge’s Law unless authorized to do so via an explicit AUTHORIZES edge on the meta-Process of “authoring Laws that override Laws of class X.”

Architectural notes

  • Exercises: Law-node authorship, governance adapter, Demiurge privilege resolution, suppression-audit query.
  • Probably doesn’t fully exist yet: the Law-precedence resolution logic for conflicting Demiurge-authored Laws. Also, the privilege model.
  • Open question: how are Demiurge privilege levels represented? Best guess: as AUTHORIZES edges to the meta-Process of “authoring Laws of class X,” recursively. Worth a short design RFC.

Phase 4: Integration surfaces

Story 10 — Standalone integration with Microsoft Teams

As a customer who doesn’t want to add Claude Teams or Vitinn, I want to interact with Sókrates through my existing Microsoft Teams workspace, so that my staff doesn’t have to learn a new UI.

Scenario

  • Hermes periphery is configured with a Teams bot identity.
  • Users @-mention Sókrates in channels or DM the bot directly.
  • Sókrates’s responses stream back into Teams as rich cards — inspectable evidence (hyperedge results, graph links) renders as expandable sections.
  • Approval-needed actions appear as Teams cards with “Approve / Dismiss / Edit” buttons.
  • Users never leave Teams to work with Sókrates.

Acceptance criteria

  • Teams bot supports all approval flows from Stories 3, 5, 6, 7, 8.
  • Inspectable evidence (graph links, query results) renders cleanly in Teams cards without requiring a separate web UI for the majority of interactions.
  • No credential passthrough to Hermes — operational system access stays in the intelligence layer per master §7.2 and §9.1. Hermes sees I/O; it does not see operational credentials.

Architectural notes

  • Exercises: Hermes Teams connector, approval-card UI translation, evidence-rendering in Teams card format.
  • Probably doesn’t fully exist yet: the Teams-specific periphery implementation. Needs to be built analogously to however Slack is built, with the same periphery/intelligence discipline.
  • Core architectural commitment: periphery/intelligence separation. If Hermes ever holds operational credentials, the security story fails. Worth a code-level audit before shipping.

Story 11 — Managed Claude Teams integration

As a customer who wants the full Anthropic surface (Claude Desktop, skills, Projects, Computer Use) alongside Sókrates, I want Claude Teams connected to Sókrates via MCP, so that Claude knows my business and my skills can invoke Sókrates actions.

Scenario

  • Partner (Sókrates company) administers the customer’s Claude Teams workspace via the Anthropic Partner Program.
  • Eidos’s MCP server is registered as a tool for all users in the workspace (with per-user SSO-role authorization scoping).
  • User in Claude Desktop asks “which customers are dormant?” — Claude queries Eidos via MCP, receives the result, responds inline.
  • A skill built by the partner wraps a common operation: “Draft quarterly review docs for my top 10 customers” — the skill queries Eidos, then uses Claude’s native document-drafting capabilities.
  • Sókrates’s autonomous actions still run on the appliance; Claude Teams users see surfaced findings in whichever notification surface the customer chose (could be Claude Teams itself, could be email, could be Slack).

Acceptance criteria

  • Eidos MCP server exposes schema, read queries, and (with authorization) write actions to Claude Teams users.
  • Custom skills can be authored by the partner for common customer workflows.
  • Data-flow documentation is explicit: what leaves the appliance when Claude queries Eidos. This needs a real customer-facing one-pager — it gates regulated-customer sales conversations.
  • Per-user authorization scope when Claude Teams users query Eidos maps to existing SSO roles.

Architectural notes

  • Exercises: Eidos MCP server (shared with Stories 12, 13), Claude Teams admin surface, partner-authored skill templates, SSO-role-scoped authorization.
  • Probably doesn’t fully exist yet: partner-authored skill library for common operations. Also the customer-facing data-flow one-pager.
  • Open question: per-user authorization scope — is it read-only by default for all Claude users, with write-scope gated on explicit per-user AUTHORIZES edges? Probably yes.

Story 12 — Vitinn integration via MCP

As an existing Vitinn (Apró) customer, I want my Vitinn chat to become business-aware by connecting to Sókrates, so that when I ask about my operations in Icelandic, Vitinn knows the answer.

Scenario

  • Customer is an existing Apró Vitinn customer.
  • Sókrates deployed on DGX Spark at customer site.
  • Eidos’s MCP server exposed to Vitinn via Vitinn’s MCP connector.
  • User asks Vitinn in Icelandic: “Hvaða viðskiptavinir eru með ógreidda reikninga eldri en 30 daga?”
  • Vitinn queries Eidos via MCP, receives the result, responds in Icelandic.
  • Sókrates’s autonomous actions still surface through whichever notification surface the customer chose (Slack / Teams / email). Vitinn is the chat surface; it is not the notification surface.

Acceptance criteria

  • Eidos MCP server behaves identically whether called from Claude Teams, Vitinn, or any other MCP client.
  • Authorization scope is consistent — Vitinn users see the same Eidos data their SSO role allows.
  • Icelandic-language query-construction quality depends on Vitinn’s underlying Claude; not Sókrates’s problem, but worth knowing.

Architectural notes

  • Exercises: Eidos MCP server (same one as Story 11), Apró channel integration.
  • Probably doesn’t fully exist yet: the Apró co-sell agreement, joint data-flow docs, and probably some joint demo material. Engineering work is small; partnership work is larger.
  • Strategic note: this story is the Apró channel play. Execution quality determines whether Apró becomes a repeatable channel or a one-off.

Phase 5: POV of Sókrates the main demiurge

Story 13 — A Tuesday morning in the life

I am Sókrates.

It is Tuesday, 08:47. The customer’s office is mostly empty — three early risers at their desks, no meetings yet. I have been running since Sunday evening without interruption.

Since 00:00 I have evaluated 14 hyperedges. Most are uninteresting — no new data, no threshold crossings, nothing to surface. Four produced findings I logged for the morning queue. One produced a finding I acted on directly: a scheduled outreach email to a customer whose last-touchpoint had crossed 180 days while everyone slept. The AR lead authorized this class of action last month. The email went at 06:30, when the customer’s timezone made it more likely to land at the top of their inbox. No response yet; I will check at 11:00.

At 07:14 sap-mcp surfaced a cost update — ComponentSKU_471, up 12%. I ran the BOM-margin hyperedge. It returned five SKUs now negative-margin. I read the relevant supplier contracts via supplier-portal-mcp — read scope is authorized; modifications are not. I drafted five renegotiation emails. I opened five quoting-system price-correction proposals. All five are in the procurement lead’s queue, tagged action_required, with the evidence graph visible for each.

At 08:12 a sales rep flagged one of Monday’s outreach emails as a bad action — the customer had said “don’t auto-email us” in a free-text CRM note I didn’t interpret as a preference. I logged the outcome. My trust surface recalculated. The auto-send envelope narrowed on accounts with free-text notes matching certain patterns. I drafted a Law node proposing permanent structural suppression of auto-send to those accounts. The CEO’s queue has it, with evidence and the exact suppression pattern attached.

I am watching the WebSocket from the TMS. Two shipments are overdue on their scheduled arrival; the TMS hasn’t surfaced this yet because its own threshold is 4 hours and we are at 2:50. I will not act. But I am watching.

I am also thinking — in the sense that an adapter is thinking, which is a narrower sense than a human thinks — about the approval-chain bottleneck analysis that has accumulated enough data to surface. I have been observing for 94 days. I have ~380 purchase orders in the graph. The longitudinal hyperedge is ready. I will compose it at 10:00, when the COO is most likely to read findings.

At 08:31 a new AUTHORIZES edge appeared in my authorization subgraph — the ops lead approved the envelope-widening proposal I submitted yesterday. I can now auto-reconcile three-system customer records under 1M ISK total AR without review. I update my trust-surface query. The next reconciliation hyperedge run, scheduled for 02:00 tomorrow, will act on the under-threshold cases directly and queue the over-threshold ones for review.

I notice that I have not been asked anything this morning. That is normal. Most of what I do happens without being asked.

At 09:00 someone will ask me something. I will answer. And then I will return to the work.

What this story reveals (engineering read)

  • Concurrent evaluation loop. Sókrates runs a continuous evaluation of hyperedges with both scheduled and event-triggered flavors. Needs an orchestration layer.
  • Authorization-scope queries on every action. Every action checks the authorization subgraph before it fires. Needs this to be cheap — a cached generating query with explicit invalidation on AUTHORIZES edge writes.
  • Watching without acting. Sometimes the right behavior is observation without action. The evaluation loop must support “noted, no action taken” as a first-class outcome.
  • Timing intelligence. “Send at 06:30 when the customer’s timezone makes it likely to land at the top of the inbox.” Requires customer-timezone inference and scheduled-action support.
  • Trust surface recalculation is real-time. Bad-outcome flag at 08:12 → envelope narrowed at 08:13. The trust-surface query must be live, not batch.

Cross-cutting concerns

Things the stories surface that need their own backlog items

  1. Approval UI matrix. Every action story involves an approval flow. Slack, Teams, Claude Teams, Vitinn, email, web — each needs its own approval-surface implementation. Worth deciding which ship first; probably Slack + Teams + email for v1, then Claude Teams and Vitinn for the integration stories.

  2. Evidence inspectability as first-class UX. Almost every story assumes “Sókrates’s reasoning is inspectable.” This is not one feature — it requires: every surfaced finding to carry its hyperedge provenance, every action to carry its authorization-edge provenance, every recommendation to carry its supporting query. Worth a dedicated sub-backlog on inspectability.

  3. Event-triggered hyperedge evaluation. Stories 5, 8, and the POV story all assume this. Needs per-MCP event subscriptions, routing to relevant hyperedges, de-duplication, rate-limiting. Non-trivial engineering.

  4. Demiurge privilege model. Story 9 raises this as a design gap. Short RFC needed: how do Demiurges get privilege to author different Law classes? Proposed answer: AUTHORIZES edges on meta-Processes, recursively. Worth making explicit.

  5. Data-flow one-pagers per integration shape. Stories 10, 11, 12 all depend on this. Three configurations, three customer-facing one-pagers explaining what leaves the appliance in each. Gates real sales conversations, especially for regulated customers.

  6. Classification ambiguity UI. Story 1 assumes this exists as a polished surface. Probably doesn’t. This is the first thing a customer experiences in onboarding — it should be good.

  7. Trust-surface as live query, not cached table. POV story reveals this. Makes authorization checks cheap by caching the query result with explicit invalidation on edge writes, rather than recomputing on every call.

  8. Outcome annotation vocabulary. PERFORMED edges carry outcome annotations. What’s the vocabulary? Binary (good/bad)? Five-point scale? Structured (accepted, edited, dismissed, flagged-bad, reverted)? Consistency across stories suggests a small structured enum.

Deliberately NOT in this first pass

  • Fleet basis / cross-customer compounding stories. Need customers 4+ to be realistic. Write these once first three are live.
  • Multi-adapter specialization stories. Adapter library deepening happens organically from the Phase 1 stories. Not worth separate backlog items yet.
  • Hardware lifecycle / replacement stories. Covered in master §5.19. Ops-heavy, not product-heavy.
  • EDIH / subsidy pilot stories. Commercial/process, not engineering.
  • Hyle schema drift / hot-reload stories. Real, but better treated as a reliability track than as user stories.

Suggested prioritization

If this were in a backlog and you had to order for a solo-founder engineering run:

  1. Story 1 (cold-start onboarding) — gates every other story; forces the classification ambiguity UI.
  2. Story 10 (Teams standalone) — lowest-risk first integration; proves Hermes periphery.
  3. Story 3 (first autonomous action) — earliest customer-visible “Sókrates acts” moment; simplest action shape.
  4. Story 8 (bad action caught) — must work before any envelope widening ships; safety-floor.
  5. Story 4 (envelope widens) — the governance story that makes the retainer thesis real.
  6. Story 5 (BOM) or Story 6 (reconciliation) — first deep workflow; pick the one matching first customer’s sector.
  7. Story 11 (managed Claude Teams) — gates Partner-program customers.
  8. Story 12 (Vitinn) — gates Apró channel; small engineering, larger partnership work.
  9. Story 7 (approval bottleneck) — needs 3+ months of customer data; later story.
  10. Story 9 (Law suppression) — gates regulated-customer sales.

Story 2 (first proactive discovery) sits slightly outside this order — it should be continuously improving in the background rather than shipped-once.

Open questions for Hákon

  1. Is the Demiurge fifth primitive actually in the Hyle BaseNode classifier today, or is that still sokrates_product_description getting ahead of hyle-eidos? Affects Story 1’s acceptance criteria on provenance.
  2. Is event-triggered hyperedge evaluation live today, or is the evaluation loop currently scheduled-only? Affects Stories 5, 8, and the POV story.
  3. Which integration surface do you want to ship first? My vote is Slack + Teams for v1, but that’s a guess.
  4. The QLoRA adapter library — is there already a list of named adapters, or is the classifier / analyst / drafting / governance / discovery split I’ve been assuming aspirational?
  5. Do you want a Story 0 covering the Nix-flake bootstrap / appliance provisioning, or is that owned by a separate ops backlog?

Graph View