306 - How an asset was built

• 301Creating reports and dashboardsHow to ask the agent for shareable work product instead of chat that scrolls away. The habits that decide whether your dashboard survives next week.
• 302Exporting dataWhen you need a spreadsheet a teammate can sort, or a data file for another system, instead of a view.
• 303Sharing your workTwo ways to share: a user share to a named teammate, or a public link anyone with the URL can open. Three controls on either: expiration, notice text, revocation.
• 304Creating collectionsBundle a dashboard, a summary, and the underlying data into one navigable briefing. Build it during the session via the agent, or by hand on the portal's Collections page.
• 305Editing what you already haveUpdate an asset in place so shared links keep working and history stays on one record. Metadata edits do not bump the version; content edits do; revert is append-only.
• 306How an asset was builtThe audit trail Plexara records at the MCP boundary: which tool calls the agent invoked, with what parameters, in the producing session. Captured at save time, readable by you or the agent.
• 308Reproducible promptsSave the starting instruction as a first-class prompt with named arguments via Manage Prompts (manage_prompt). Re-run it later with different values. Personal, persona, or global scope. What re-running does and does not guarantee.

• Descriptive metadata

  What it is

  Name, description, tags. The agent fills these on save based on your prompt and the session context. Indexed for search; shown on the Assets page and the asset viewer. Editable later through the agent or the portal without bumping the version.

  Who sets it

  The agent on save, taking cues from your prompt. You can edit any of it later (through the agent or the portal) and the platform never overwrites your edits on subsequent updates.

  Example

  name: "Q3 2025 regional sales review", tags: ["sales", "q3-2025", "regional"]

• Provenance metadata

  What it is

  A snapshot of the MCP tool calls Plexara observed during the session before save_artifact harvested the buffer. Captured automatically; not editable by anyone. Includes each call's name, timestamp, and parameters, plus the session_id and user_id. Does not include chat content, tool responses, or agent reasoning.

  Who sets it

  The platform, on every save_artifact and trino_export call. You never write to it; you only read it. The record is an approximation of how the asset was built, not a step-by-step proof.

  Example

  tool_calls: [datahub_search → trino_query → trino_query]; session_id, user_id.

• tool_name

  The MCP tool the agent called. Examples: datahub_search, trino_query, knowledge_search.

• timestamp

  RFC 3339 UTC timestamp of when the call ran. Lets you sequence events and correlate with audit logs.

• parameters

  The arguments the agent passed to the tool, as a JSON object. For trino_query, this includes the SQL. For datahub_search, the search query string and any filters.

• session_id

  The Plexara session that produced the asset. Use this to find the conversation log that goes with the audit trail.

• user_id

  The authenticated user whose session ran the calls. The owner field on the asset is the same person; provenance.user_id is a redundant copy at the moment of save.

• What Plexara records

  • The name of every MCP tool the agent invoked in your session.
  • The parameters the agent passed to each tool (the JSON arguments).
  • A UTC timestamp for each call.
  • The session_id and the authenticated user_id.

• What Plexara does not record

  • The text of your prompts to the agent.
  • The agent's responses back to you.
  • The agent's internal reasoning between turns.
  • The content of the tool responses (only the parameters going in, not the data coming back).
  • Which captured tool calls the agent actually used to build the asset, versus called and ignored.
  • Any transformations the agent applied (rounding, filtering, joining results) that were not themselves separate tool calls.

{
  "session_id": "sess_2026_05_15_abc",
  "user_id":    "550e8400-e29b-41d4-a716-446655440000",
  "tool_calls": [
    {
      "tool_name":  "datahub_search",
      "timestamp":  "2026-05-15T14:22:03Z",
      "parameters": { "query": "regional sales 2025", "type": "dataset" }
    },
    {
      "tool_name":  "trino_query",
      "timestamp":  "2026-05-15T14:23:11Z",
      "parameters": {
        "sql": "SELECT region, transaction_date, net_amount FROM sales.transactions WHERE quarter='Q3' AND year=2025",
        "limit": 10
      }
    },
    {
      "tool_name":  "trino_query",
      "timestamp":  "2026-05-15T14:24:55Z",
      "parameters": {
        "sql": "SELECT region, SUM(net_amount) FROM sales.transactions WHERE quarter='Q3' AND year IN (2024, 2025) GROUP BY region, year",
        "limit": 100
      }
    }
  ]
}

• export_query

  The SQL that produced the export, captured verbatim. You can read it later, copy it into a notebook, or hand it to a colleague to re-run.

• source_tables

  The tables Plexara extracted from the SQL. Used for sensitivity-tag inheritance (302) and useful as a quick "what data sources fed this" reference.

• format

  csv, json, markdown, or text. Records which shape the export was produced in.

• row_count

  How many rows were in the export at save time. Lets a reviewer compare today's row count against the historical one.

• "Where did this number come from?"

  Provenance shows which queries the agent ran and what they asked for. That is usually enough to point at the source: a trino_query against a specific table with a specific filter. The honest framing is that provenance gives you a strong correlation, not a step-by-step proof, since the agent may have transformed the query result on its way into the chart.

• "Who had access to produce this?"

  The user_id and session_id at the top of the provenance, plus the asset's owner_email field. These are exact: they identify the authenticated user whose session produced the asset. Compliance can correlate them with the platform audit log to confirm access controls applied at the time.

• "Can I reproduce this analysis next quarter?"

  The captured SQL is your starting point. Copy the export_query (for exports) or the trino_query parameters into a new session, parameterize the date, and the agent will produce a comparable asset. Whether it matches exactly depends on whether the original session applied transformations the provenance does not record. Article 308 covers reproducible prompts in depth.

• Phrase a stakeholder question as a provenance question. "Where did this number come from?" becomes "open the Q3 dashboard and show me its provenance." The agent reads the record and translates it into prose.

• Quote the SQL when you reproduce. If you want a new asset built the same way last quarter's was, ask the agent to read the export_query from the prior asset's provenance and re-run it with adjusted dates. Article 308 makes this its own subject.

• Treat session_id as the link back to the chat log. When the audit story needs more than what is in provenance, the session_id is the breadcrumb that gets you to the original conversation.