How coordination intelligence works.
The substrate, identity resolution, the four-stage pipeline, and the confidence calibration that makes every divergence in the brief auditable. Written for the CTO who reads it and the diligence partner who cites it. Pair with the Glossary for term definitions and the Comparison page for how this differs from engineering diagnostics and dashboards.
What the CTO reads.
- ·The substrate reads five mediums of coordination signal, identity-resolved across them.
- ·Every divergence carries a citation chain to specific PRs, tickets, threads, and calendar events.
- ·Confidence bands run VERY_LOW to HIGH; post-hoc outcomes reconcile deterministically.
- ·Cadence design: one Monday Brief per week, on-watch indicators in between, chain reasoning queries in seconds.
What the partner cites.
- ·Coordination signal is a leading indicator of delivery outcomes.
- ·30-Day Finding is the pre-acquisition read; the Monday Brief format is the subscription operating cadence.
- ·Substrate schema is identical across companies; portfolio roll-up is mechanically comparable.
- ·Customer owns the substrate at the fact-graph level; no analysis trapped at exit.
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.
For diligence and portfolio monitoring
Coordination intelligence maps naturally to the investment lifecycle. The same substrate that gives a CTO an executive read gives a deal partner a scoped diligence artifact, an operating partner an ongoing monitoring cadence, and a fund manager a comparable portfolio-level view.
- Use 01
Pre-acquisition diligence.
A 30-Day Finding is a scoped, executive-grade read on how an engineering organization coordinates. Deal teams commission it during the diligence window; the finding is cited to specific PRs, tickets, threads, and calendar events a technical diligence partner can verify. - Use 02
Post-acquisition monitoring.
The Monday Brief is designed as the operating cadence; on-watch indicators fill in between. Every divergence carries a confidence band. Every band reconciles against a post-hoc outcome via a deterministic Temporal workflow; the reconciliation runs whether or not anyone looks at it. - Use 03
Portfolio comparability.
The substrate schema is the same across companies. Once native connectors are attached across a portfolio, roll-up reads (which portfolio companies are trending which direction on coordination signal, which are exposed to specific coordination risks) become mechanically comparable rather than eyeball-comparable across dashboards.
Ownership matters at exit. The customer owns the substrate: the fact graph, the identity resolutions, the confidence-band history. On operator change or exit the substrate transfers to the acquiring party or the successor operator. No analysis is trapped in a consultancy's PowerPoint.
The customer owns the substrate. No analysis trapped in a consultant PowerPoint.
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 ships with a confidence band. The brief's track record section is where flagged divergences are reconciled against what happened: flagged, confirmed, expired, per window.
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.
Reading cadences
The same substrate feeds four distinct reader cadences.
| Cadence | Latency | Answers |
|---|---|---|
| 30-Day Finding | 30 days end to end | Is this org coordinated? What is going to slip? |
| Monday Brief | Weekly | What happened this week? What is on watch? |
| On-watch indicator | As events land | What just changed on the watch list? |
| Chain reasoning query | 5 to 15 seconds | Ad-hoc question against the substrate |
Coordination signal reads what dashboards were not built to measure.
Where the language model sits
The substrate is a graph of facts, edges, and attestations. Facts enter via deterministic ingest from the source systems: a pull request opens; a ticket transitions; a calendar event is created. No language model participates in that write.
Two operations follow the write.
Corroboration between two facts is a formula, not an opinion. No language model participates in it; two facts either satisfy the corroboration function or they do not.
Verdicts on a claim are rule-driven, and the rules split by direction. Positive verdicts belong to the substrate: a claim is supported only by facts that exist, and zero supporting facts reads not-found regardless of the model's opinion. Negative verdicts (contradicted, out-of-scope, not-found) follow the verifier, a language-model read of the retrieved evidence pool. The model cannot mint support that is not there. It can conclude that the retrieved facts do not support the claim, and that conclusion stands even when candidate facts exist.
The language model's role at the surface is translation. Verified evidence goes in. Prose with citations comes out. Every citation in a shipped brief resolves to a real fact_id in the substrate; the post-hoc guard invalidates invented references before they render.
If the model is wrong on a positive claim, the substrate catches it and the verdict reads not-found. If the model is wrong on a negative claim, the verdict may be wrong; the evidence chain the model considered is intact and inspectable. If the model is wrong on the prose, the words are awkward and the citations still resolve.
If the model is wrong on the prose, the words are awkward. The citations still resolve.
Confidence bands and calibration
Calibration is the substrate's primary trust mechanism. Every divergence ships with a confidence band. When the divergence resolves, the post-hoc outcome is recorded automatically: divergences whose predicted event later matches a downstream signal are marked confirmed; those whose window closes without a match are marked expired. The track record section of each brief is where these outcomes are reconciled against the original flags, per window.
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 high confidence over the last quarter, X percent were validated." The sample briefs on the landing page demonstrate the format with synthesized data.
The four bands
| Band | Confidence threshold | Reading |
|---|---|---|
| VERY_LOW | Below 0.25 | Weak or single-source signal |
| LOW | 0.25 to 0.50 | Partial signal |
| MEDIUM | 0.50 to 0.75 | Corroborated signal |
| HIGH | 0.75 or higher | Strongly corroborated signal |
How the GRADE is computed
Six engineers, 129 merged changes in a month, a demo that closes rooms. 16% of capacity touches the product customers pay for. An F that photographs like an A.
Facts sealed 2026-07-06 · window 2026-06-08 to 07-05 · every figure resolves to a record: GIT fct_m1a204CRM fct_m1e05bGIT fct_m1f930
Negative space: ticketing and runtime telemetry not connected. The questions this grade cannot answer are stated on the card, with who can.
The R&D GRADE is one artifact on the substrate described above. It is the read Zamski produces on a target's organization, for investors doing diligence or portfolio monitoring, and for government evaluators reading contractor performance. On your own organization, the Monday Brief is the operating read. Both artifacts seal weekly. Both cite down to the same sealed facts. This chapter describes the GRADE mechanics.
Six elements, one page each report
The grade. One letter, A through F, computed as a weighted composite of the themes below it. A floor rule prevents a strong composite from hiding a critical failure: no company earns a B while any theme sits in its worst band. The letter is the start of the conversation, not the end.
The history strip. Grades seal weekly and are never revised. The shape of the strip is itself evidence: a grade that improves exactly when diligence begins is a question. Late facts enter the next window; the sealed letter is immutable.
Theme rows. Each row is a theme, one graded question about the business. Where capacity goes. Whether the tech claims match the graph. Who walks out with the company. The theme set changes with the investor's priorities and the company's stage; every reading states its numbers, not adjectives.
Evidence pills. Every claim carries the IDs of the sealed facts that decided it, and the source each fact came from (GIT, CRM, TICKETS, AI, SESSIONS, DECLARED). On a live report each pill resolves to the underlying record. Nothing on a card is an opinion wearing a number.
The spend view. Where the target's AI dollars went, in dollars, never tokens. Growth, maintenance, leakage, misuse, and the unattributed remainder, stated. Unit cost per shipped change includes generated work that was thrown away. Reported alongside the grade; not itself scored. The sample cards at /samples render a condensed card; the full anatomy, including the AI spend view, is in the specimen book.
Negative space. Every card states which evidence sources feed it and which do not, then lists the questions it therefore cannot answer, and who can. In diligence, the most expensive risks are the ones nobody knew to ask about. Absence is a finding.
The floor rule
The method computes a composite letter from the weighted themes, then applies the floor rule: no card prints better than C while any theme sits in its worst band. The floor rule can move a computed B down to C. It never lifts a letter up. Recovery paths are stated on the card, subject to two-window confirmation.
Stage profiles
The same sealed facts grade differently under different stage profiles because different themes belong at different stages. The pre-seed profile grades milestone velocity and counts discard as exploration; founder concentration does not fire the floor rule. The seed profile adds ownership transfer and asks whether hires are taking ownership. The Series A profile drops the seed-specific themes and adds the default risk set.
A Series A B and a seed B are not comparable letters. The specimen book pairs one company graded under both profiles: the seed lens computes C, capped by an ownership-transfer failure; the Series A lens computes B, because that lens does not ask whether hires are taking ownership. Same facts, two letters. Where the lens has no theme, the finding has no home. The operative grade is the one that fits the stage.
Computed, not judged
Every figure on a GRADE card resolves to the sealed record that decided it. Recompute the report from those sealed facts and the letter comes back the same. This aligns with the method described in the previous chapter: the language model writes the sentences, the substrate computes the letter. No language model participates in the composite or the floor rule. The card's cap, the theme bands, and the letter itself are deterministic reads over a graph.
Rubric version and calibration
The rubric is versioned and stated on every card. The specimen book renders cards under rubric v0.5.0 (Meridex), v0.4.0 (Riverkit at W23), and v0.6.0 (Oxbow pre-seed, Tallgrass seed and Series A comparison). Thresholds are provisional pending calibration against production data. The method reports the rubric version on every card; every version stated in this documentation corresponds to a card in the book. Calibration will move thresholds. It does not change the fact that the letter is computed from sealed facts.
Sentences are written by machines. Letters are computed from sealed facts.
Audit and attestation
Zamski has completed a SOC 2 Type II audit, performed by Sensiba LLP. Audit period December 17, 2025 through March 18, 2026. Continuous controls monitoring runs through Vanta. 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.
Deeper reading.
- Glossary: definitions for coordination substrate, kinetic state, confidence band, divergence, and 20 other terms used on this page.
- Comparison: how Zamski differs from McKinsey-style diagnostics, from management dashboards, and from AI workflow platforms.
- Integrations: what each source system contributes to the substrate, plus the fact contract for custom adapters.
- Security: SOC 2 Type II attestation, controls documentation, audit period.
- The 30-Day Finding: one executive-grade read on your engineering org via read-only OAuth, deleted after 30 days or continued into a subscription.