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. 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.

For engineering buyers

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.
For diligence and portfolio monitoring

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.

Chapter 01

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 annual physical and the continuous heart monitor are not the same product. McKinsey-style engineering diagnostics run on per-tool aggregation plus a leadership survey, take 6 to 12 weeks, and produce a deck dated the week the consultants pack up. Zamski is built to run continuously and publish a Monday Brief every Monday morning.
Chapter 02

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.
Chapter 03

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.

CODEGitHub · GitLabTICKETSJira · Linear · ClickUpCHATSlack · TeamsSUBSTRATEIdentity-resolved fact graphCALENDARGoogle · MicrosoftCRMSalesforce · HubSpot · Zendesk
MediumSource systemsSignal type
Code activityGitHub, GitLabCommits, PRs, reviews, review latency, branch lifetimes, AI-assisted authorship
Task and project stateJira, Linear, ClickUpTicket flow, dependency graphs, sprint commitments versus delivery, scope drift
Conversation patternsSlack, Microsoft TeamsThread density, decision capture, escalation paths, sentiment shifts
Calendar densityGoogle Calendar, Microsoft CalendarMeeting load, focus time, after-hours patterns, calendar density decline before departure
Customer signalSalesforce, HubSpot, Zendesk, IntercomRenewal status, escalation patterns, account-team activity, revenue chain connectedness
Chapter 04

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.

Chapter 05

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).

01RETRIEVALScoped by org_id02ANALYSISCorrelation, ten passes03SCORINGGravity + confidence04ASSEMBLYGrounded, cited

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.

Chapter 06

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.

CadenceLatencyAnswers
30-Day Finding30 days end to endIs this org coordinated? What is going to slip?
Monday BriefWeeklyWhat happened this week? What is on watch?
On-watch indicatorAs events landWhat just changed on the watch list?
Chain reasoning query5 to 15 secondsAd-hoc question against the substrate
Coordination signal reads what dashboards were not built to measure.
Chapter 07

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.
Chapter 08

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

BandConfidence thresholdReading
VERY_LOWBelow 0.25Weak or single-source signal
LOW0.25 to 0.50Partial signal
MEDIUM0.50 to 0.75Corroborated signal
HIGH0.75 or higherStrongly corroborated signal
Chapter 09

How the GRADE is computed

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.
Chapter 10

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.

Chapter 11

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

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.
Cookies

How Zamski uses cookies

Zamski uses strictly necessary cookies to operate this website. We also use one optional analytics cookie (PostHog) to understand how visitors arrive and which pages they read, so we can write better. We do not use advertising or targeting cookies, and we do not sell visitor data.

You can accept analytics, decline them, or tailor your preferences. You can change this any time from the Cookie settings link in the footer. Read the Cookie Notice for the full detail.