Open the whole manual on one page

6. Add a source

What the Add NASA evidence dialog does today and what is not built yet.

Add a source (as built today)

"+ Add a source" opens a dialog. Only NASA sources are accepted: an NTRS document number from ntrs.nasa.gov, or a NASA CSV or Excel table you upload (up to 20 MB). Typed links are never fetched.

Today the dialog checks your input and shows the five steps that will run (Read, Extract with quotes, Located in the source by code, Classified only if stated, Every scenario recalculated). Processing arrives in the next build, so the submit button is disabled and nothing is added yet.

+ Add a source button

What it is. The button next to the page title.

What it shows. It opens the Add NASA evidence dialog.

How to use it. Click it to see what a source needs.

Example. Click it, then type an NTRS number.

What it does not do. Processing is not built yet: nothing is added today.

Add NASA evidence dialog

What it is. The dialog that opens from + Add a source.

What it shows. The rule (NASA sources only), the fields and the five steps that will run.

How to use it. Fill a field to see the check; close with the cross or Esc.

Example. Type https://example.com/ and read the message.

What it does not do. The submit button is disabled; nothing is added or fetched.

Close the dialog

What it is. The cross at the dialog's top right.

What it shows. Nothing.

How to use it. Click it, press Esc, or click outside.

Example. Close it after checking a number.

What it does not do. It discards what you typed.

NTRS number field

What it is. A text box for an NTRS document number.

What it shows. Digits only, or the digits of a pasted ntrs.nasa.gov link.

How to use it. Type 20250010653 or paste a citation link.

Example. 20250010653.

What it does not do. It never fetches the text you type: the server will build the address itself.

Upload a table

What it is. A file picker.

What it shows. CSV or Excel tables up to 20 MB.

How to use it. Choose a file; it is checked for type and size.

Example. A NASA CSV table.

What it does not do. Uploads will be labelled "your file, not verified as NASA" unless they match an NTRS download. PDFs are not accepted yet.

See how every value is checked

What it is. A link at the bottom of the Add a source dialog.

What it shows. Nothing by itself; it opens the Data page, which explains how every extracted value is located in the NASA file by code.

How to use it. Click it to read how evidence is checked.

Example. Open it to see the located-by-code counts.

What it does not do. It does not process or add a source; today the dialog only checks your input.

Add a source: what it will do and what exists today

“Add a source” is the feature that lets a visitor bring one new NASA document into PYRION and see exactly how every scenario changes. Its rule is that no value gets in unless code can find it in the source, the same rule that holds for the 10077 records already in the app.

In plain words: an AI may read the document and propose values, but it cannot make a value count. A program checks each proposed value against the document, and anything it cannot find is rejected with the reason shown.

## What works today, and what does not

| | Status |
|---|---|

| The “+ Add a source” button and the dialog, on the Envelope and Data pages | Working today |

| The NTRS number field and the file chooser (CSV, Excel or PDF up to 20 MB) that check what you type or pick | Working today |

| The strip of steps that will run | Working today (display only) |

| The submit button | Disabled: in the next build |

| Reading, extracting, verifying, locating by code, classifying, recalculating | In the next build |

| The recorded run on LUCI, the external-evidence switch, before and after per scenario | In the next build |

| The precision exam on the LUCI golden set | In the next build (the golden set itself exists today) |

Nothing is added to the evidence yet. Everything below the first two rows describes the design, not a working feature.

## For engineers

  • Design document: FASE-3-ADD-SOURCE.md, section “Corrección tras la auditoría independiente” (the corrected design).
  • The hook in the web code is addSource(); the dialog is wired to it and the submit is disabled until the pipeline exists.
  • The golden set and the validator changes it needed are in place: data/external/ntrs-20250010653/ and --conditions in both validators.
Sources: pyrion-ops/FASE-3-ADD-SOURCE.md

Only an NTRS number, only NASA

“Add a source” accepts one kind of source: an NTRS document number (digits only, from ntrs.nasa.gov). If you paste an ntrs.nasa.gov link, only its digits are kept.

In plain words: you give a number, and the server builds the NASA address itself. Nothing you type is ever fetched as a web address, so the feature cannot be used to make the server visit an arbitrary site. Other kinds of links (doi.org, other pages) are not accepted.

## A file you upload

A CSV or Excel file you upload is read by code with columns you map by hand. A file you upload is not NASA unless its SHA-256 matches the one of the file downloaded from NTRS; otherwise it is labelled “your file, not verified”.

## How a document is read

  • Maximum 20 MB and 60 pages.
  • Read in a separate process with a time and memory limit.
  • The text for checking comes from the original file’s text layer, by code. What exists only in a figure or an image is rejected.

## Status

In the next build. Today only the NTRS number field and the file chooser exist, and they check the input; nothing is fetched or read yet.

## For engineers

  • The server builds https://ntrs.nasa.gov/... from the digits; the digits are validated (numbers only) and the host is fixed.
  • The SHA-256 of a download is stored as provenance.
Sources: pyrion-ops/FASE-3-ADD-SOURCE.md

The steps, in order

Once built, a source goes through these steps, each visible on screen with its state (done, failed with the reason, or waiting).

In plain words: read the document, let an AI propose records with quotes, let a different AI object, let a program have the last word, label only what the source states, then recalculate every scenario and show what changed.

  1. Source. An NTRS number. The file’s SHA-256 is stored; title, author and license are shown when the source states them.
  2. Reading. Text and tables per page, by code (tables of CSV and Excel by code, PDF by the PDF reader). The page and table counts are shown.
  3. Extraction. A model proposes records in the schema. Each carries the value as written, the original unit, the quote and the page or cell. The model never converts units; the engine does.
  4. Check by a model of another family. It objects to or approves each record, with a quote.
  5. Validator in code (the last word). The same checks as validation/run_all.py: the quote must appear word for word, or the cell in its row and column; units and ranges must be physically plausible. A record that cannot be located is rejected, with the reason shown.
  6. Classification. Regime, fuel phase, diluent and flame type are filled only if the source says so, with its quote. Otherwise the axis stays “not stated”. Gravity is never inferred.
  7. Recalculation. The engine recalculates the four cards, the map, the routes, “experiments needed”, the results and the receipts, and shows a before and after per scenario.

Before you accept anything, a table lists every proposed record: value, unit, quote, page, the checker’s verdict and the validator’s verdict. At the end, “What changed” shows the before and after and lets you see it on the map.

## Status

In the next build. Today the dialog shows that these steps will run; it does not run them.

## For engineers

  • Steps 3 and 4 use two different model families so that one model’s habit is not the other’s. Neither decides: step 5 does.
  • Without a model configured, CSV and Excel with hand-mapped columns are still accepted (read by code); PDFs need the model and say so.
Sources: pyrion-ops/FASE-3-ADD-SOURCE.md

What is rejected, and why

A proposed record is rejected, with its reason on screen, whenever code cannot place it in the source or the source does not say what the record claims.

In plain words: the program prefers to throw away a true value it cannot prove than to accept a false one.

  • The quote is not in the file, word for word. Rejected.
  • A number differs from the source. The numbers of a quote must appear exactly as written: 1.5 is not 15. A record whose value_original is not written in its quote is rejected.
  • The value is only in a figure or an image. Rejected; nothing is read off a plot.
  • A table value on a slide needs its context. The slide title, the header and the row label must appear in order on the same page; otherwise the record is kept only as insufficient evidence. (A real case: “1.5 mm/s” is the lunar-gravity PMMA spread rate on one slide of the LUCI deck and the 1 g SIBAL flame base on another.)
  • Gravity needs its own sentence. Each test’s gravity must have its own quote on the same page. A slide that sits in a 1 g section but only says “Results: PMMA” does not state its gravity.
  • Oxygen that falls during the burn is a result, not a condition. It is stored as an outcome and never widens a test’s oxygen range.
  • Different quantities stay apart. Flame base and flame tip spread rates are different variables. Ratios between tests (partial gravity over 1 g) are not records.
  • No platform as gravity, no inferred gravity. A flight on a rocket or a station says nothing about the gravity level by itself.
  • No wording that overstates. Superlatives, endorsements and absolute claims are never copied into a record.

## Status

In the next build as an automatic pipeline. The same rules were applied by hand, with separate checkers, to the LUCI golden set today.

## For engineers

  • These are the rules added to the validator after the audit by a separate AI reviewer agent on 14 November: numbers as written, value_original inside the quote, and trace against the original text layer. Still open: checking that the quote is on the cited page.
Sources: pyrion-ops/FASE-3-ADD-SOURCE.md; data/external/ntrs-20250010653/README.md

Added evidence is external, and looks it

Evidence you add is external: it is never mixed silently with the curated PSI base.

In plain words: added evidence has its own colour or mark on the map, its own label on the cards and a switch, “show added evidence”, so you can see the app with and without it.

  • Per visitor. What you add changes only your view. It lives in your browser and the engine recalculates there.
  • You can take it with you. The added records can be exported as CSV plus JSON with their receipts. A button will explain how to propose them to the repository as a pull request on GitHub.
  • Limits. A maximum number of pages per source, a cap per visitor and per day, and the extraction model has the same budget as the rest of the app.

## The example: LUCI

LUCI is the first external source and the exam case. Its lunar gravity is simulated partial gravity from a rotating vehicle, and every screen says so. In the planned video, the lunar-gravity card changes from “none in PSI” to “1 external flight with simulated gravity, far from your condition”. It is never shown as applicable unless the engine says so.

## Status

In the next build. The first version is planned as: an NTRS number box with LUCI as a recorded run of the process, labelled as recorded, with a receipt per record; the external-evidence switch and before-and-after per scenario; CSV and Excel upload with hand-mapped columns and no model; and live PDF extraction only behind an “experimental” option if time allows.

## For engineers

  • Golden data: data/external/ntrs-20250010653/conditions.csv with accession NTRS-20250010653; the citation check requires the id in data/manifest/external_sources.json.
  • A cache by SHA-256 makes the LUCI demo cost nothing and avoids model rate limits; a global daily cap works as a switch.
Sources: pyrion-ops/FASE-3-ADD-SOURCE.md; nasa/ntrs-20250010653/ASGSR 2025-LUCI-Ferkul-Presentation-v2-20250010653.pdf

The precision exam

How do we know “Add a source” is precise? By an exam with a known answer key.

In plain words: the same program that will read a new document is run on documents whose correct records are already known, and its output is compared with the answer key. The result is reported as raw counts, for example “13 of 15 found, 0 incorrect accepted”, never as a percentage that hides the size.

## The answer key

The LUCI golden set was extracted by hand with the usual rigour (an extractor, a separate verificador, then the validator): 42 records in 4 tests, 37 usable and 5 insufficient_evidence, in data/external/ntrs-20250010653/. It exists today.

## The exam

  • Precision: of the values the process accepts, how many are correct.
  • Coverage: how many of the golden-set values it finds.
  • Zero invented values accepted: every value the code cannot locate must be rejected.
  • Free extra test: run the process on documents already curated in data/conditions/, where the answer is known.
  • Negative controls: numbers deliberately altered, a false quote injected, and a value that exists only in a figure. All must be rejected.
  • Aim: every accepted value correct, because the validator rejects what it doubts, and coverage of at least 80 %. If the aim is not met, the real number is published on the page.
  • The judge battery gains an “add-source” section that runs this exam.

## Status

In the next build. The golden set and the validator changes it needed exist today; the exam itself runs once the pipeline exists.

## For engineers

  • python -I validation/run_all.py --conditions data/external/ntrs-20250010653 validates the golden set (0 BLOCKER).
  • The judge battery lives in validation/judge_battery/.
Sources: pyrion-ops/FASE-3-ADD-SOURCE.md; data/external/ntrs-20250010653/README.md

Help center

Every page, button and number explained. Loading the topics… Press the ? menu, then Help mode, to point at anything.

Pick a topic on the left, or search.