Cognitive Mesh
Socio-cognitive copilot layer that models human cognition and bias, then mediates human-AI and human-human teaming under explicit consent and governance
Overview
Cognitive Mesh is a socio-cognitive copilot layer that models how individual people and teams reason, where bias and influence pressure show up in their day-to-day collaboration, and how an organization can mediate those moments under explicit consent and human-in-the-loop governance. Today it delivers a complete Phase 1 governance loop — every subject's consent is captured before any analysis happens, every cognitive observation is treated as a reviewer-disposable hypothesis (never a fact), every intervention is gated by a versioned policy pack, and every action is audited end-to-end. Subjects now have two dedicated portals: the SubjectTransparencyPortal gives anyone whose interactions are observed a clear view of their cognitive profile and consent state, and the SubjectSelfServicePortal lets them manage their own consent and submit correction requests without going through an operator. Together, these portals complete the subject-facing side of the privacy compliance story and make the consent-first design tangible for the people it is designed to protect. Customers get a coaching, governance, and calibration platform that strengthens human judgment without replacing it, with a growing test suite and a clear roadmap to wider channel coverage and threat-analysis activation.
Why Cognitive Mesh
Executive View
Cognitive Mesh gives leadership a governed, defensible way to improve organizational decision quality and resilience to social engineering — without the surveillance posture that usually torpedoes adoption. The consent-first design (subjects authorize each channel and can revoke within 30 seconds), the explicit exclusions (no surveillance without consent, no automated adverse employment actions, no minor inference, no clinical diagnosis), and the four-role review model (cognitive reviewer, security reviewer, privacy governor, system owner) make it safe to deploy in environments where trust and policy compliance are non-negotiable. Executives gain calibration and drift dashboards that show how the platform's interventions are performing, plus a complete audit trail per intervention class, so the value story is measurable and the governance story is auditable from day one.
User Experience
Reviewers (cognitive, security, privacy, system owner) work from a Dashboard that shows live metric cards, a Review Queue that walks each case through `submitted → assigned → decided → closed`, and a Hypotheses page that paginates evidence chains so they can confirm, flag, or reject each cognitive hypothesis with full provenance. Privacy governors handle subject correction requests inside the same console. System owners publish new policy pack versions in shadow mode, promote them, and roll back with one action when a calibration report or drift alert says so.…
Available Now — 12 Capabilities
Identity, Consent & Reviewer Roles
🟩 DeliveredCAP-001 · 5 use cases
Domain extension tables (UserRow, OrganizationRow, ConsentProfile, ChannelAuthorization, ReviewRoleAssignment) live in the cognitive_mesh database with subject_id linking back to the platform-DB CustomerProfile (per C-006 / ADR-002). consent_guard middleware enforces consent on every state-changing operation and propagates revocation through Redis within the 30-second window described in UC-01 §11. ReviewRoleAssignment supports the four canonical roles (cognitive_reviewer, security_reviewer, privacy_governor, system_owner). Subjects and Admin frontend pages render the lists. v1.5: uc-ic-consent-management.spec.ts now confirmed. v1.6: uc-ic-self-service.spec.ts now confirmed (CAP-001/UC-IC-05). All 5 UCs now have at least partial E2E coverage. GET /identity-consent/profiles/by-subject/{subject_id} route confirmed in fact bundle. Subject-facing self-service consent toggle exposed via SubjectSelfServicePortal page.
Interaction Ingestion & Episode Lifecycle
🟩 DeliveredCAP-002 · 6 use cases
Append-only InteractionEvent + ChannelMessage + InteractionEpisode store with EpisodeParticipant join, normalization service, replay endpoint, and webhook ingress (webhook.py). Background enrichment runs through tasks.py / scheduler.py. Teams adapter in providers/teams_adapter.py wires the first channel surface. Other collaboration channels (Slack, email, ticketing) are not adapted yet — overview.md §"Suggested initial architecture slice" calls out Slack/Teams as the MVP channel and that is what is wired. No frontend page surfaces ingestion controls — this is a backend pipeline capability with pytest_only test surface. v1.5: uc-ii-interaction-ingestion.spec.ts confirmed. v1.6: UC evidence shows UC-II-01 through UC-II-04 all partial — UC-II-02, UC-II-03, and UC-II-04 upgraded from uncovered to partial.
Cognitive Modeling & Subject Profiles
🟩 DeliveredCAP-003 · 5 use cases
HumanProfile, TeamCognitiveProfile, CognitiveStateSnapshot, and ProfileEvidenceLink are persisted with ContractRecordMixin. The service exposes restriction-aware reads, archival, and accepts ProfileCorrectionRequest objects fed from UC-03. Team profile synthesis (B3 in intent) is modeled but not surfaced in the operator console. AI-driven longitudinal pattern discovery (B1, H3) depends on the reasoning runtime adapter and is partial. v1.6: uc-cm-profiles.spec.ts now confirmed in 01_impl/frontend/e2e/ — provides partial coverage of UC-CM-01, UC-CM-03, UC-CM-04, UC-CM-05. All 5 UCs now have at least partial E2E coverage.
Bias Analysis & Hypothesis Workflow
🟩 DeliveredCAP-004 · 5 use cases
BiasHypothesis + BiasEvidence + BiasTaxonomyReference + BiasReviewDecision modeled. Reviewer workflow supports confirm/flag/reject transitions. Inference is performed by the reasoning runtime via providers/cm_adapter.py and providers/episode_analysis_adapter.py; pattern KB (intent §"Bias & threat patterns KB") is not yet a separately maintained library — taxonomy references live as inline reference rows. Hypotheses page in the operator console paginates and renders evidence chains. ui-hypotheses.spec.ts confirms page load, search, create, and flag action flows. UC evidence (v1.6) shows UC-BA-01 through UC-BA-03 all partial via multiple specs including 02_final_validation/browser/tests/cross-cutting.spec.ts and ui-uc01-coaching.spec.ts. UC-BA-04 and UC-BA-05 remain uncovered.
Intervention Policy & Decision Engine
🟩 DeliveredCAP-005 · 6 use cases
Four intervention classes (I0 internal, I1 private coaching, I2 team-visible verification, I3 consequential review) implemented with policy-pack gating from governance_audit/policy_loader.py. UC-01 (private coaching) is the primary live path; UC-04 (team-visible verification) is gated off by default. Outcomes are recorded for calibration. EscalationCase records support the I3 path. Channel delivery uses providers/teams_adapter.py + providers/intervention_adapter.py. ui-interventions.spec.ts confirms page load, form visibility, search, and filter flows. UC evidence shows UC-IP-01, UC-IP-02, UC-IP-04, UC-IP-05 all partial via multiple 02_final_validation specs. UC-IP-03 and UC-IP-06 are covered by pytest specs added 2026-05-05.
Threat & Influence Analysis
🟩 DeliveredCAP-006 · 6 use cases
Full Phase 2 surface: ThreatHypothesis, ThreatEvidenceChain, VerificationAction, and Campaign aggregation. providers/ threat_adapter.py routes inference to the reasoning runtime. Per release_gate_readiness.md §5, Phase 2 features remain feature-flagged off by default until calibration maturity is established. Operator console page ThreatAnalysis.tsx is gated behind the security_reviewer role. Long-horizon influence campaigns (intent D2) have data model support but no surfaced timeline view yet. UC evidence (v1.6) now shows UC-TA-01, UC-TA-02, UC-TA-03, UC-TA-04, UC-TA-05, and UC-TA-06 as partial — uc-ta-campaigns.spec.ts now confirmed in 01_impl/frontend/e2e/ covering UC-TA-03, UC-TA-05, UC-TA-06.
Subject Correction & Appeal
🟩 DeliveredCAP-007 · 5 use cases
DataSubjectRequest pipeline implemented end-to-end: subject submits, cognitive_modeling marks fields under review, reviewer resolves with correct / restrict / reject. SLA-expiry behavior and conservative-default outcomes are coded per UC-03 §6 failure-flow table. Subject identity verification handoff exposed via identity_consent context. v1.6: uc-sc-reviewer-actions.spec.ts and uc-sc-self-service-portal.spec.ts now confirmed in 01_impl/frontend/e2e/ covering UC-SC-03 and UC-SC-05. UC-SC-04 covered by pytest spec. All 5 UCs now have at least partial or covered status.
Governance Review Queue & Policy Pack Rollout
🟩 DeliveredCAP-008 · 6 use cases
ReviewQueue state machine (submitted → assigned → decided → closed) is functional. policy_loader.py loads versioned policy packs from 03_ops/config/policy/ (defect D-02 fix made the path environment-aware via COGNITIVE_MESH_POLICY_PACK_ROOT). AccessAuditEntry rows back the explainability use case (G2). Operator console exposes ReviewQueue.tsx and Policies.tsx (the latter gated to system_owner). Stage rollout (shadow / staged / promoted / rolled back) is modeled in policy version metadata. UC evidence (v1.6) shows UC-GA-01 through UC-GA-04 all partial. uc-ga-policy-rollback.spec.ts now confirmed in 01_impl/frontend/e2e/ providing partial coverage for UC-GA-05.
Operator Console (Frontend)
🟡 Partially DeliveredCAP-009 · 11 use cases
React + Vite + Tailwind + sf-ui DashboardLayout / Sidebar / Header / AuthGuard. 14 routed pages (up from 10 in v1.5) backed by useCogMeshApi + TanStack Query and a useWebSocket hook for live notifications. Role-aware nav (security_reviewer, privacy_governor, system_owner). Common components MetricCard and StatusBadge have unit tests (vitest / testing-library). v1.6: SubjectAnalytics, SubjectSelfServicePortal, SubjectTransparencyPortal (/my-profile), and LoadHotspots are now confirmed in the fact bundle — 4 additional pages. All 11 UCs now have at least partial coverage. Marker remains 🟡 pending machine-verified pass artifacts.
Analytics, Calibration & Drift Reporting
🟡 Partially DeliveredCAP-010 · 6 use cases
Aggregate dashboard endpoint, CalibrationReport generation, and DriftAlert acknowledgement are wired. Calibration.tsx and DriftAlerts.tsx render reports and alerts with operator acknowledge action. Analytics jobs run via scheduler.py / tasks.py. UC-05 is targeted for Phase 3; aggregate-only access discipline enforced. v1.6: SubjectAnalytics.tsx and LoadHotspots.tsx confirmed in fact bundle — covering GET /analytics/subjects/{subject_id} and GET /analytics/hotspots. UC-AR-05 and UC-AR-06 are covered by uc-ar05-ar06-analytics-drill.spec.ts. uc-ar-analytics-views.spec.ts provides coverage for UC-AR-04. UC-AR-04 upgraded from uncovered to partial. Marker remains 🟡 pending machine-verified pass artifacts.
Reasoning Runtime Adapters (CM, KB, Channels)
🟩 DeliveredCAP-011 · 6 use cases
providers/ houses 11 adapters: cm_adapter (collaborative_machines runtime), collab_adapter, direct_llm_adapter (sf_shared LLM factory), episode_analysis_adapter, evolution_bridge, feedback_emitter, intervention_adapter, kb_enrichment (KB retrieval per ADR-002 and skill_kb_sources), runtime_adapter, stub_adapter (test/dev), teams_adapter, threat_adapter. boundary_guard.py enforces the runtime boundary called out in §3.2 of the system design. Slack / email / ticketing channel adapters are not implemented (Teams only). This is a backend infrastructure capability with pytest_only test surface — no frontend or confirmed Playwright spec.
Multi-Tenant Isolation, RBAC & Audit Middleware
🟩 DeliveredCAP-012 · 6 use cases
Middleware stack: auth (JWT via sf_shared with AUTH_ENABLED bypass for E2E), rbac (role-aware route enforcement), consent_guard (per-call consent validation), rate_limiter, logging (structured + trace_id propagation). Alembic chain ships RLS policies (a1b2c3d4e5f6_add_rls_policies), tenant isolation (c3d4e5f6a7b8_tenant_isolation_to_cog_app), and soft-delete (b2c3d4e5f6a7_add_soft_delete) on the baseline. otel.py wires OpenTelemetry. capabilities.py emits the capability advert. All cross-context user/org references use UUID-by-value (C-006). This is a backend cross-cutting capability with pytest_only test surface. UC evidence (v1.6) shows UC-MW-02 as partial via cross-cutting.spec.ts, uc02-threat-assessment.spec.ts, and ui-threat-analysis.spec.ts. UC-MW-01, UC-MW-03, UC-MW-04, UC-MW-05, UC-MW-06 remain uncovered.
Coming Soon — 1 Capabilities
Cross-Org Aggregate & Org-DNA Service
🟠 DesignedCAP-013 · 4 use cases
ADR-003 records the decision to defer the dedicated governance_org service until multi-tenant needs arise — DNA artifacts exist under collaborative_machines/dna/ but no service has been built. The Phase 3 organizational dashboard concept (UC-05 §8) and the dna_evolution_lifecycle.md design depend on this layer for a true cross-team, longitudinal cognitive-health narrative. §14.5 of the use-case doc explicitly excludes cross-organization subject profiling without consent and a data sharing agreement, so this capability must ship with strong consent-scoping primitives before activation. Status unchanged.
Capability Maturity Levels
Shared Platform Foundation
All RDS products share infrastructure that accelerates delivery and ensures consistency:
sf_shared
LLM factory, auth, BaseTask, agent profiles
sf-ui
React components, hooks, Tailwind palette
Knowledge Base
pgvector hybrid search, 7 content domains
Collaboration Platform
WebSocket rooms, presence, real-time sync
Interested in Cognitive Mesh?
RDS delivers and extends Cognitive Mesh through fixed-cost Capability Delivery Sprints — start with a Capability Pilot to see governed socio-cognitive analytics operating in your environment in weeks.
Discuss Your Program