Methodology
How coordination intelligence works. The substrate, identity resolution, the four-stage pipeline, and the confidence calibration that makes every divergence in the brief auditable. Pair this with the Glossary for term definitions and the Comparison page for how this differs from engineering diagnostics and dashboards.
What coordination intelligence is
Coordination intelligence is the reading of how work is actually coordinated across an engineering organization. Not how much work, not how fast, not how much code. How the coordination signal looks across the mediums engineers actually use, identity-resolved across those mediums, with citations down to specific artifacts.
The premise is that the C-suite needs to know what is happening at the level the board reads, and that nothing in the existing engineering tool stack produces that read. Dashboards measure what dashboards can measure: uptime, pull request throughput, ticket cycle time. None of those answer the questions a CTO is asked in a board update.
The substrate: five mediums, identity-resolved
The substrate reads five mediums of coordination signal across the engineering organization. Identities are resolved across all five so that a calendar change for one engineer can be associated with a commit pattern that connects to a revenue chain commitment.
| Medium | Source systems | Signal type |
|---|---|---|
| Code activity | GitHub, GitLab | Commits, PRs, reviews, review latency, branch lifetimes, AI-assisted authorship |
| Task and project state | Jira, Linear, ClickUp | Ticket flow, dependency graphs, sprint commitments versus delivery, scope drift |
| Conversation patterns | Slack, Microsoft Teams | Thread density, decision capture, escalation paths, sentiment shifts |
| Calendar density | Google Calendar, Microsoft Calendar | Meeting load, focus time, after-hours patterns, calendar density decline before departure |
| Customer signal | Salesforce, HubSpot, Zendesk, Intercom | Renewal status, escalation patterns, account-team activity, revenue chain connectedness |
Identity resolution across mediums
A single engineer can show up as a GitHub username, a Slack ID, a calendar email, a Jira account ID, and a CRM contact ID. The substrate resolves these to one identity per person, then projects that identity into a workspace graph that links forward to teams, projects, repos, customers, and revenue chains.
Identity resolution runs at 85 percent confidence threshold. Anything below that threshold is held in a review queue rather than auto-merged. The substrate also enforces a hallucination guard: personal queries without verified identity are blocked, not guessed.
The four-stage pipeline
Every divergence Zamski surfaces follows a four-stage pipeline. The stages are documented in the orchestrator contract and run identically on user queries (synchronous) and the Monday Brief (batch).
Stage 1: Data Retrieval
The substrate retrieves the relevant slice of the workspace graph from ArangoDB. Multi-tenant isolation is enforced via org_id filtering at every query; no cross-tenant reads are possible. Read-only OAuth scopes apply at the integration layer; the substrate cannot write back to source systems.
Stage 2: Analysis
The analysis stage runs identity resolution, intent classification, named entity recognition, and the correlation engine. The correlation engine evaluates rule-based coordination patterns (ten numbered passes in the production system; layers three and four are intentionally disabled as documented in the codebase) and produces candidate divergences with evidence citations.
Stage 3: Scoring and Confidence
Each candidate divergence is scored across three axes: entropy (Shannon entropy of signal sentiments), velocity (recency-weighted signal counts), and impact (unique participants times team breadth). A gravity score (0.35 entropy + 0.40 velocity + 0.25 impact) gates whether the divergence crosses the threshold for the brief. The CatBoost re-ranker (when active per-org) applies a learned correction on top of the deterministic score.
Every divergence is shipped with a confidence band. Bands are logged against post-hoc outcomes. Precision is measured continuously and published as the track record in each Monday Brief.
Stage 4: Response Assembly
The response stage assembles the brief or query response. Narrative generation is grounded in the structured evidence; no free-form LLM output bypasses citation requirements. The brief is rendered to a consistent six-section template: divergences caught, interventions executed, track record, on-watch, tool stack ROI, resolved.
Chain reasoning versus correlation engine
Two distinct runtime paths share the four-stage pipeline.
Chain reasoning handles synchronous user queries (chat-style or API). The path is identity resolution, hallucination guard, intent classification, data retrieval, confidence scoring with up to two iterations, optional CatBoost re-ranking, and grounded LLM response generation. End-to-end latency is typically 5 to 15 seconds.
Correlation engine handles batch analysis for the Monday Brief and the on-watch indicators. It runs the ten-pass correlation matrix across the full org workspace, applies sentinel goals and the prescription layer, and persists candidate situations to the situations collection. Latency is measured in minutes per org per pass.
Confidence bands and calibration
Calibration is the substrate's primary trust mechanism. Every divergence ships with a confidence band (typically expressed as a percentage). Every band is logged with the underlying evidence and the model version that scored it. When the divergence resolves (or doesn't), the post-hoc outcome is recorded. Precision is calculated continuously and surfaced in the track record section of each brief.
The track record is the line item in the Monday Brief that a CTO can point to in a board update: "of the divergences we flagged at 80 percent confidence over the last quarter, X percent were validated."
Audit and attestation
Zamski is SOC 2 Type II certified, audited by Sensiba LLP. Continuous controls monitoring runs through Drata. The audit posture and the specific controls (org-scoped queries, AES-256 encryption, read-only OAuth, no model training on customer data) are documented at /security.
The substrate is built for evidence: every claim in a brief carries a citation chain back to the specific PR, ticket, thread, or calendar event that produced the signal. Buyers can trace any divergence to its constituent evidence.
What this is not
Coordination intelligence is not a developer productivity tool, an engineering management dashboard, or an AI code generator. It does not measure individual engineer performance, score engineers, or expose performance data to managers of the engineers being measured. Multiplier scores and individual performance data are gated at the VP Engineering tier with mandatory audit logging; they are never exposed to the engineers being measured.
Zamski is also not a replacement for engineering tools. Datadog, GitHub, Jira, Slack, Linear, and the rest of the engineering tool stack continue to serve the people they were built for: engineers and engineering managers. Zamski reads the coordination signal across that stack to produce the executive read those tools were not built to produce.
Related references
- Glossary — definitions for coordination substrate, kinetic state, confidence band, divergence, and 20 other terms used in this page
- Comparison — how Zamski differs from McKinsey-style diagnostics, Faros AI, LinearB, Jellyfish, and the engineering tool stack
- Security — SOC 2 Type II attestation, controls documentation, audit period
- The 30-Day Finding — one executive-grade read on your engineering org, free, deleted after 30 days