run_d04887f7c766a986

input

{
  "request": "Triage Jira ticket MZCLD-3733: Roll non-cloud AI vendor costs into the consolidated cloud cost dataset",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3733"
  ],
  "sourceContext": {
    "issue": "MZCLD-3733"
  }
}

summary

MZCLD-3733 is a well-scoped Q4 discovery/design ticket (currently in Backlog) to extend Mozilla's FinOps cost pipeline (source → label → BigQuery → query) to non-cloud AI vendors (Anthropic, OpenAI, Cursor, Copilot, etc.), which today bill outside cloud invoices and are invisible in the consolidated cost dataset. The ticket is clearly written, has named owner/collaborators, explicit in/out-of-scope boundaries, concrete deliverables, and links to precedent tickets for the same per-source ETL pattern. It has zero comments and no linked runbook/design doc yet — this is expected since it's a discovery-phase ticket that hasn't started design work. Triage recommendation: accept as scoped, confirm precedent-ticket links resolve, and clarify the go/no-go decision gate and timeline dependency before work begins.

findings

• Ticket is a discovery/design effort, not an ETL build — deliverables are a vendor inventory, API/export feasibility per vendor, an ETL/BigQuery design, and an attribution go/no-go, with engineering follow-on explicitly deferred to 2027 Q1 (or FY26 Q1, per the ticket's own numbering) contingent on a 'yes' answer.
• Scope is explicitly bounded to non-cloud AI vendors; GCP Gemini/Vertex is called out as already covered via the existing GCP billing export and needs no new work here, reducing risk of scope creep.
• The ticket anticipates and pre-authorizes a valid negative outcome: attribution to app_code/product may not be possible because most AI vendors bill per-seat/per-org rather than per-workload. This sets a low-risk bar for the discovery phase and should be preserved as an acceptable outcome during triage, not treated as project failure.
• The ticket has clear ownership and named collaborators spanning engineering, vendor/commercial, finance, and labels/inventory functions, and follows an established per-source ETL pattern used for prior sources (Fastly, Azure), plus depends on/rides along with a separate ETL platform workstream.
• The ticket sits under the FY26 FinOps Cloud Cost Visibility theme (MZCLD-955) but currently has zero comments and remains in Backlog status — no discovery work appears to have started or been logged yet, and no confluence runbook/design doc is linked from this ticket.
• Cross-referenced tickets (MZCLD-3527, MZCLD-2514, MZCLD-2148, MZCLD-3538, MZCLD-955) could not be independently verified in this triage pass — read access was restricted to the subject ticket only, so the precedent/dependency claims are taken at face value from the ticket text and should be spot-checked by the ticket owner or a human triager with broader access.

proposed actions

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3733"
    },
    "result": {
      "key": "MZCLD-3733",
      "summary": "Roll non-cloud AI vendor costs into the consolidated cloud cost dataset",
      "status": "Backlog",
      "description_text": "Owner:  James Francis.  Collaborators:  Jason Thomas (vendor and commercial), Kristin Prust (Finance and reconciliation), Steven Prokopienko (labels and inventory) Today the FinOps chain is: pull cost from a source, label it, store it in BigQuery, query it to expose the data. That chain covers GCP, AWS, Azure, and Fastly. Non-cloud AI vendors \u2014 Anthropic, OpenAI, Cursor, Copilot and similar \u2014 bill outside any cloud invoice, so their spend never enters the dataset. There is no single place to answer \"what do we spend on AI.\" Can we treat these vendors as additional sources we ingest, label, and store the same way? In scope:  non-cloud AI vendors only. GCP Gemini/Vertex already arrives via the GCP billing export (see MZCLD-3527) and needs no new ETL. Q4 is discovery and design, not a pipeline.  Deliver a vendor inventory with real spend figures and billing models, a documented answer on whether each vendor exposes a cost or usage API/export we can pull, a design for how that data becomes a source in the billing ETL and lands labelled in BigQuery, and a go/no-go on whether AI spend can be attributed to app_code/product at all. Most AI vendors bill per-seat or per-org rather than per-workload, so \"attribution is not possible without a seat-to-app_code mapping we do not have\" is a valid and useful finding. Engineering follow-on lands 2027 Q1 if the answer is yes. Follows the same per-source pattern as MZCLD-2514 (Fastly Billing ETL) and MZCLD-2148 (Azure Data in ETL Pipeline), and would ride the ETL platform work in MZCLD-3538. Part of theme:  MZCLD-955 (FinOps: Cloud Cost Visibility FY26)",
      "comment_count": 0,
      "comments": []
    }
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3538"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-3538"
      }
    },
    "blocked": true
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-955"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-955"
      }
    },
    "blocked": true
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3527"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-3527"
      }
    },
    "blocked": true
  }
]

log