Plexara
What you will take away from this lesson
The December price sheet arrives from Blue Harbor Wholesale. Same columns, same 400 SKUs, new numbers. Everything the series built in November, the registration, the knowledge page, the margin dashboard, was built against the November file, and the useful question is how much of it has to be done again.
The answer is one replacement and one re-registration, and the reason it is not zero is worth understanding, because it is the same reason a table over a file can be trusted at all: the platform never moves a table forward on its own.
Learning Objectives
- 01Update a file when the new one arrives, with Replace content on the file’s page or the agent’s replace_content, and know that both write a new revision the Version history keeps and can restore.
- 02Read the Behind the file state on the Scratch Tables page and move the table forward by registering again under the same name.
- 03Tell the two cases apart: a file overwritten in place is followed by the table; a new revision is not, until somebody registers again.
- 04Unregister without touching the file, and know that deleting the file drops every table over it.
- 05Save the monthly procedure as a prompt, and know the two ways a table stays current with nobody in the loop.
- 06Recognize the point at which a monthly file needs more than a join, which is where the 600 series begins.
Where this lesson sits
This is the last lesson of the 500 series. The file has been uploaded, registered, explained to the agent, joined, and turned into a dashboard the right people can open. What remains is the part that decides whether any of that survives past the first month: what happens when the next file arrives.
500 Series: Spreadsheets as Tables
- 501The last mile of data is a spreadsheetThe join was never the expensive part; loading was, and loading was staffed. Why a chat agent does not close the gap on its own, and what a table over the file where it sits changes.
- 502Uploading a file and registering it as a tableThe resource library, the Excel rule, the Query as a table panel, what a registration answers with, the Scratch Tables page, and the three things a file is refused for.
- 503Teaching the agent what the file meansUnits, grain, effective dating, the join key, and what a missing row means: captured once, promoted to a knowledge page, recalled by every teammate’s agent.
- 504Joining, visualizing, and sharingThe join with the cast, a supplier quote against a month of sales, a dashboard asset with provenance, and when a dashboard should reference the file instead of querying it.
- 505Next month’s fileA new revision leaves the table behind; register again to move it forward. Unregistering, deleting, the monthly procedure as a prompt, and where a join stops being enough.
The 500 series assumes the asset mechanics from the 300 series and the knowledge loop from 206. It ends where the 600 series begins: the point at which a monthly file needs more than a join.
Two changes that look the same and behave differently
A registration points at the place the file lives, not at a particular set of bytes. That one fact explains everything in this lesson. Change the bytes where the table is already looking and the next query reads them. Put the new bytes somewhere else and the table keeps reading the old place until somebody points it forward.
On Plexara, replacing a file in the portal and asking the agent to replace it both write a new revision. The file keeps its id, its address, and its name, so every dashboard that references it shows the new content on its next open. The registered table does not follow, and the platform tells you so rather than moving it on its own.
Two ways a file changes, and what the table does about each
The file is overwritten in place
- What happened
- The same object is written again at the same address. A vendor drop replacing yesterday’s file, or a script writing over its own output.
- What the table does
- The next query reads the new contents.
- What to do
- Nothing.
A new revision is written
- What happened
- Replace content in the portal, or replace_content from the agent. The file keeps its id, address, and name; the new bytes are a new revision in its Version history.
- What the table does
- Keeps serving the revision it was registered against. That is correct SQL over the file as it was, and it will not change on its own.
- What to do
- Register again, same connection, same name.
The second case is the one a monthly sheet lands in, whichever surface you use to update it. A dashboard that references the file by its address follows the new revision on its next open (504); a table registered over the file does not, and says so.
The Scratch Tables page states it
Nothing else can report that a table is behind its file, so the Scratch Tables page calls it out. The table is not broken and it is not dropped: a report built on it keeps running, against the revision that was current when it was registered. What the page adds is the fact that a newer revision exists.
manage_table action=list answer.Moving the table forward
Registering again under the same name on the same connection replaces the registration and points the table at the current revision. There is no unregister step first. The trace below is the December revision landing on the demo tenant: the replacement, the check that shows the table behind, the second registration, and the query that confirms the table now reads December.
The December revision landing on the demo tenant
What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it.
- 1
manage_resource action=replace_content reference=mcp:resource:71131796… change_summary="December 2025 price sheet from Blue Harbor Wholesale: 400 SKUs requoted, effective 2025-12-01."
Content replaced and recorded as version 2, restorable from the file’s version history. The id, uri and filename are unchanged, so every asset referencing this file now serves the new bytes without being re-saved.
- 2
manage_table action=list reference=mcp:resource:71131796…
registration_id reg_a9de2c4f… · query_table scratch.uploads.admin_supplier_price_sheet · stale: true
- 3
manage_table action=register reference=mcp:resource:71131796… connection=scratch table_name=supplier_price_sheet
registration_id reg_67fe6630… · query_table scratch.uploads.admin_supplier_price_sheet · stale: false. Registered as scratch.uploads.admin_supplier_price_sheet on connection scratch.
- 4
trino_query … SELECT s.effective_date, COUNT(*) … FROM scratch.uploads.admin_supplier_price_sheet s JOIN warehouse.public.products p ON p.sku = s.sku … GROUP BY s.effective_date
effective_date 2025-12-01 · quoted_products 400 · weighted_cost_change_pct 2.38 · below_20_margin 73
Four calls, and the table reads December: every one of the 400 quoted rows now carries an effective date of 2025-12-01, the weighted cost change against the cost of record is +2.38% on November volume, and 73 quoted SKUs sit below a 20% projected margin. Registering the same name on the same connection replaces the registration, which is why the panel says to register again rather than to unregister first. A name somebody else registered is refused and names who holds it, so nothing is overwritten by accident; an administrator is unrestricted and does replace it.
The monthly procedure as a prompt
Three steps, once a month, in the same order every time: replace the file’s content, register again, rerun the dashboard. That is a procedure, and the 400 series already covered where a procedure goes. Ask the agent that just did it to write the prompt, review the draft, and next month the whole thing is one sentence.
The monthly procedure, in the order it runs
- 1
Replace the file’s content
Replace content on the file’s page in the portal, or hand the agent the new sheet. Either way it is a new revision, restorable from Version history, and the file keeps its address.
- 2
Register again
Same connection, same name. The Scratch Tables page stops reporting the table as behind the file, and a search hit for the file stops carrying the stale flag.
- 3
Rerun the dashboard
The margin dashboard from 504 was built from queries against the table, so its numbers are a snapshot of the month it was built. Rerunning the procedure writes a new version of the same asset.
Lesson 402 covers asking the agent that just ran a procedure to write the prompt that repeats it. This one is three steps and one argument, the month, and next time it is a sentence: “the December price sheet is in, run the monthly supplier update.”
Keeping the table current without a person
The monthly prompt still needs someone to say it. Two shapes remove the person from the loop, and which one fits depends on how the file arrives.
Two shapes that keep a table current with nobody in the loop
A file that is overwritten in place
When the supplier, or a system on your side, writes the new sheet over the same object, the table reads the new contents on its next query and nothing has to be registered again. This is the better shape when the table has to stay current by itself.
A script that refreshes the file and registers again
When the sheet arrives as a new revision, a managed script can do the two steps a person would: replace the resource’s content, then call manage_table to register the same name again. The dashboard rerun is the same script’s next lines.
The second shape is a managed script, which is what the 600 series is about. Lesson 603 shows the call: the script refreshes the file with replace_content, then registers again with platform.call("manage_table", …), because a new revision leaves the table behind exactly as it did here.
Unregistering, deleting, and the record
Two more actions complete the lifecycle, and they are not the same action. One removes the table and leaves the file. The other removes the file and takes every table over it along. Both, like every registration, are written to the audit log.
Removing a table, and removing a file
Unregister
- What it does
- Drops the table and forgets the registration. The file is not touched: it stays exactly where it was, byte for byte, with its revisions.
- Who may
- The person who registered the table, or an administrator. The table lives in a schema everyone granted the connection shares, so the person who put it there is the one who takes it out.
- What is recorded
- An audit event: who, which connection, the statement that ran, the table it named.
Delete the file
- What it does
- Removes the resource or asset, and drops every table registered over it, whoever registered them. A registration that survived a deletion would read a place whose contents are gone; that is the Source deleted state, and deleting the file properly leaves none behind.
- Who may
- Whoever may change the file: its owner or uploader, or an administrator. The same authority registering it took.
- What is recorded
- One audit event per table dropped, alongside the deletion itself. Failed attempts are recorded too.
Unregistering is offered on the Scratch Tables page and on the file’s own Query as a table panel, on the tables you may drop. Registering stays on the file’s page, because it needs the file: the platform reads the header row to learn the columns.
What a join cannot do
A registered table turns a file into something SQL can reach. That is the whole of what it does, and for a price sheet joined to a catalog it is enough. Some monthly files need more than a join before they are useful, and that work is not a registration problem.
Five things a registration does not do
- 01
Parse a file that is not a flat table: a workbook with three sheets, a report with a title block above the header, a nested export.
- 02
Normalize what arrives: a supplier who sends prices in cases this month and units the next, a code that changes spelling, a currency that is not always USD.
- 03
Call an API on the way through: an exchange rate on the effective date, a geocode for a new address, a forecast for the week.
- 04
Recompute a KPI every time the file lands, on a cadence, without somebody asking.
- 05
Deliver a result somewhere else: a feed another system reads, a drop in a bucket, a dashboard whose numbers refresh while its layout stays put.
The end of the series
Five lessons, one file. It arrived as a spreadsheet and left as a table the whole team can join, with its meaning written down where every agent finds it, a dashboard built on it, and a monthly procedure that keeps it current.
Key terms
Five terms cover the lifecycle of a registered file after its first month.
Key Terms
- Revision
- A new version of a managed resource’s content, written by Replace content in the portal or replace_content from the agent. The file keeps its id, address, and name; the previous revision stays in Version history and can be restored.
- StaleBehind the file
- A registration whose file has a newer revision than the table points at. The table keeps serving the revision it was registered against. Reported on the Scratch Tables page, on the file’s panel, on a search hit, and in manage_table action=list.
- Register again
- Registering the same name on the same connection, which replaces the registration and points the table at the current revision. A different name, or another connection, adds a second table over the same file instead.
- Unregister
- Dropping the table and forgetting the registration while leaving the file untouched. The registrant’s action, or an administrator’s. Deleting the file is the other direction: it drops every table over the file.
- Overwrite in place
- Writing new bytes over the same object at the same address, as a vendor drop or a script writing its own output does. A table over that object reads the new contents on its next query with no re-registration.