Skip to main content
Glama

concurrent_delay_matrix

Build the per-window x per-party concurrent-delay attribution matrix from a chronological list of XER snapshots.

        Implements the per-window concurrency view per AACE RP 29R-03
        §3.3.I (apportionment) and §4.2 (concurrency). Where
        ``forensic_windows_analysis`` answers "how many days does each
        party own across the whole project?", this tool answers "how did
        each window distribute its shift across the parties?" — useful
        when defending or attacking concurrency findings on a
        window-by-window basis.

        CPP conservation check, per the AACE 29R-03 §3.3.E.13
        requirement that the summed per-period net impacts equal the
        difference between the first schedule update and the last
        schedule update used in the evaluation: the sum of per-party
        column totals equals the sum of per-window completion shifts
        within ±1 day of rounding. The column-total definition is this
        tool's own bookkeeping, not an AACE rule. The ``conservation_check`` field on
        the response reflects this; ``conservation_diff_days`` carries
        the exact gap.

        IMPORTANT — conservation is NOT attribution. ``conservation_check``
        can be True (the columns sum to the grand total) even when 100% of
        the shift lands in the Unattributed column, i.e. no party owns any
        of the drift. Read ``unattributed_share_pct`` and
        ``high_unattributed_share_warning`` to know whether a meaningful
        apportionment actually occurred. A fully-unattributed matrix
        conserves perfectly but attributes nothing — never present its
        green conservation check as a validated apportionment.

        Use this tool when you only need the matrix view; use
        ``forensic_windows_analysis`` for the full claim.

        Args:
            schedules: chronologically ordered list of dicts — the SAME
                shape ``forensic_windows_analysis`` accepts. Each dict
                carries ``label`` (optional) and EXACTLY ONE of
                ``xer_content`` (full XER text, hosted/remote use) or
                ``xer_path`` (server-side path, local use). This is the
                preferred input for hosted/remote clients.
            xer_paths: legacy chronologically ordered list of server-side
                XER file paths (local-server use).
            xer_contents: legacy chronologically ordered list of XER text
                contents. Each element is the full text of one XER.
            Supply EXACTLY ONE of schedules / xer_paths / xer_contents
            (lists must have at least 2 entries either way).

        Returns:
            {
              "parties": ["Owner", "Contractor", "Concurrent",
                          "Force Majeure", "Unattributed"],
              # Unit for every shift_* field and the grand totals. Always
              # "working_days" — the matrix measures the completion shift
              # in working days (Dana default). The *_calendar_days twins
              # express the SAME shift in calendar days so an unlabeled
              # "11" can never be mistaken for the 15-calendar-day value.
              "shift_unit": "working_days",
              "rows": [{ "window_label", "period_start", "period_end",
                         # shift_days == shift_workdays (working days,
                         # legacy alias). shift_calendar_days is the same
                         # shift in calendar days; shift_basis names the
                         # finish driver the shift was measured on.
                         "shift_days", "shift_unit", "shift_workdays",
                         "shift_calendar_days", "shift_basis",
                         "parties": {party: days},
                         "cascade_inferred": bool }, ...],
              "column_totals": {party: days},
              "grand_total_shift": int,          # working days (legacy)
              "grand_total_shift_workdays": int,
              "grand_total_shift_calendar_days": int | None,
              "conservation_check": bool,
              "conservation_diff_days": int,
              # Disambiguates "conserved AND attributed" from "conserved
              # but entirely Unattributed". unattributed_share_pct is
              # |Unattributed| / sum|shift| as a percent; the warning
              # flips True when that share is dominant (>= 50%).
              "unattributed_share_pct": float,
              "high_unattributed_share_warning": bool,
              "standard": "AACE RP 29R-03 §3.3.I (apportionment) · §4.2 (concurrency)"
            }
        

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
schedulesNo
xer_pathsNo
xer_contentsNo

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full burden. It discloses several critical nuances: conservation is not attribution, the meaning of unattributed_share_pct and its warning, the distinction between working days and calendar days, and the CPP conservation check. This goes far beyond a basic description and prevents misinterpretation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with clear paragraphs and an Args/Returns layout. The first sentence is front-loaded and specific. While every part adds value, the detailed Returns block is verbose and could be trimmed without losing critical meaning, though the lack of an output schema makes the detail useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the absence of an output schema, the description is effectively complete. It documents all return fields, units, conservation flags, and the unattributed share metadata. It also covers usage context, input constraints, and the distinction from a sibling tool, leaving no significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It does so thoroughly in the Args section, detailing the structure of schedules, xer_paths, and xer_contents, and emphasizing the 'EXACTLY ONE' rule. It also clarifies legacy vs. preferred input, adding substantial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Build the per-window x per-party concurrent-delay attribution matrix from a chronological list of XER snapshots.' It also distinguishes this tool from sibling forensic_windows_analysis by contrasting the questions each answers, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'Use this tool when you only need the matrix view; use forensic_windows_analysis for the full claim.' It also clarifies the mutually exclusive input parameters and the requirement of at least 2 entries, providing clear and actionable usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation4/5

Each tool targets a distinct analytical deliverable (windows analysis, concurrency matrix, slip velocity, TIA, collapsed as-built, SRA, etc.), and descriptions explicitly cross-reference sibling tools to clarify boundaries. Some pairs like critical_path_validator vs dcma14_health_check and forensic_windows_analysis vs concurrent_delay_matrix share inputs and close conceptual territory, but the stated distinctions are clear enough to prevent misselection.

Naming Consistency4/5

All tool names follow a consistent lowercase snake_case style with descriptive noun phrases (e.g., forensic_windows_analysis, slip_velocity, xer_parser), so there is no mixing of conventions. However, the pattern is not verb_noun and a few names embed acronyms or numbers (dcma14_health_check, monte_carlo_p50_p80, woet_classifier), which is a minor deviation from a fully uniform naming scheme.

Tool Count5/5

13 tools is well-scoped for a forensic CPM/schedule delay analysis server. Each tool covers a distinct method or deliverable—parsing, logic health, DCMA-14, windows analysis, concurrency, slip trends, TIA, collapsed as-built, Monte Carlo SRA, maturity assessment, WOET, path tracing, and an evidence workbench—so every tool earns its place without redundancy.

Completeness5/5

The tool surface comprehensively covers the forensic delay analysis lifecycle: input parsing, schedule logic validation, DCMA-14 health assessment, retrospective windows analysis, concurrency attribution, slip trending, prospective TIA, collapsed as-built, probabilistic SRA, maturity rating, execution classification, and raw-evidence workbench. Minor gaps like schedule editing or cost analysis exist but are outside the server's stated forensic-analysis purpose.