Glossary

The same definitions the information buttons show on the screens.

Actor type: A person is a persona the interface can select, or a staff user added in Administration. An agent is a service identity that holds an agent role, such as the intake agent. Everything else, including a record with no actor, is the system. The server takes the type from its identity records and ignores the text of an audit row.
Application checks: Application checks are the deterministic rules run against the application itself, for example a setback or a required document. They are separate from the extraction checks, which only test what Muse returned.
Application status: The status says where the application stands with the City. "Action needed" means the City is waiting for something from you; the request is shown on the application.
Approval policy: Single administrator: one City Administrator can take a rule or fee change from draft to published, including the administrator who wrote it. The author confirms the approval and gives a reason, and the record says it was approved by the author. Independent approval: the author of a version cannot approve or publish it, and a different administrator must do both. The city sets this in config/approval_policy.json, and the ACME_APPROVAL_POLICY environment variable overrides it for one run.
Assigned approver: The accountable owner of the domain the version belongs to. It names who is responsible for approving. Whether the version was approved is a separate fact, recorded as an event with an approver and a date.
Awaiting approval: A version is awaiting approval only after it has been submitted for review. A draft has not entered the approval workflow, so it is never described as awaiting approval.
Case record status: Record status says where a case stands in its own workflow, such as submitted, under review or approved. The status of a credential is a separate fact.
Cases that cannot be priced: A case with no usable valuation, or with no fee schedule in force on its date, cannot be given a fee. It is left out of both totals and listed here with the reason.
Cases that change: A case changes when its rule result, its recommendation or its intake route differs between the baseline and the scenario. Cases are counted once, however many measures moved.
Confirmed values: A confirmed value is a suggested field that the Data Steward accepted or corrected. Only confirmed values are treated as part of the application record.
Counts by outcome: How many cases the adjudication agent would recommend approving, approving with conditions, holding for a person or denying, under today's published rules (baseline) and under the what-if (scenario). The same cases are counted both times. A person decides every case.
Credential status: Credential status says whether a license or registration shown for a contractor or business is valid on the date that matters. It is checked separately from the record status of a case.
Data issue: A discrepancy that a steward still has to resolve, such as two sources disagreeing. It is shown only when an open issue exists.
Date basis: The rule or fee version that applies to an application is chosen on its initial submission time. A later revision of the application does not switch the schedule, and publishing a new version never changes a decision or an assessment that was already made.
Dates: Submitted is when the first application arrived. Waiting since is when the current revision arrived. Updated is the newest recorded event. The review target appears only for a permit type that has one and never on an issued case.
Direction: Relaxed means the case got a more permissive result under the scenario, for example a denial that becomes an approval. Tightened means the opposite, for example an approval that becomes a hold. The direction is worked out from the recommendation, then the rule result, then the intake route.
Distance from the property line: How far the structure stands from the edge of the lot, measured on the ground in feet. For a deck, the distance from the rear property line is checked against the deck rear setback rule (DF-3, ACME Code §14-308); the form shows the limit beside the field. For a fence the distance is recorded for the reviewer and no rule checks it.
Document content hash: A short code calculated from the contents of a stored document. If even one character of the file changes, the code changes, so it shows that the document the model read is the document on file.
Evidence before score: The agreements and conflicts the matcher found are the evidence. A score only orders the candidates; it is an uncalibrated heuristic that does not state the chance that two records are the same.
Extraction checks: Extraction checks test the shape of what Muse returned: the fields are present, the values have the right type and every value cites a place in a document. They say nothing about whether the application meets a rule.
Follow-up after issuance: A permit that is issued stays issued. An item listed as follow-up was not cleared when the permit was recorded as issued and needs attention now. The record does not state when it arose.
Hypothetical assessed fees: What the published fee schedule arithmetic would assess for the cases in the population, rounded the way real assessments are. No money is collected and none is forecast. Cases without a usable valuation cannot be priced and are listed apart.
Issue: The issue is the main thing holding the case, in plain words. The exact code that the system recorded is one click away under Exact code. The next-party column names a steward only after the issue has really been sent to one.
License or registration status: Whether the license or registration held by the person or organization is valid. An active organization can hold an expired registration; both can be correct.
Muse label: Every Muse result has a label that says where it came from. "Replay" means the stored answer of an earlier run was shown again and no model was called now. "Live" means the model was called for this result. "Cached" means an identical earlier request was answered from the stored result. "Builtin" means the City's own deterministic logic ran and no model was called; the agent screens show it as "Built in logic" and a run's provenance reads "builtin-rules-1 (builtin)". The label is never hidden.
Muse run: One recorded execution of the model task for a case. A run proposes values; it never writes a record. A steward accepts or corrects the proposal and the reviewer decides.
Needs information: Cases the intake router sends back to early resolution because something required is missing. The count is of cases at intake and says nothing about time.
Not applicable: A check is not applicable when there is nothing it can inspect. The seeded history, such as the approval and permit that the demonstration data inserts without a decision or issuance audit event, is reported as not applicable (historical seed). It is never counted as a pass and no event is made up for it.
Person or organization record status: Whether the person or organization record itself is active in the master data. It says nothing about any license or registration the record holds.
Population: The set of cases a what-if is scored on. A synthetic year is a generated sample of a year of cases and is always labelled so. A retrospective re-scoring takes stored cases and scores them again under the rules in force now; it does not rebuild the decisions made at the time.
Prompt version: The version of the instructions given to the model for this task. Two runs with the same prompt version were given the same instructions.
Property context: The parcel, the official address with its unit, the project description, the site documents, the related applications and the rule versions in force for one application. It is read from the stored records. The text the applicant typed is never the only source.
Readable reference: The readable reference of an application is the number the City gave it. The internal identifier is another name for the same case. Two records appear as one only when the stored relationship says they are one.
Reason code: A reason code is a short typed label for why a case was returned, denied, waived, sent back for revisions or archived. The codes are a fixed list; the free text beside a code adds detail but never replaces it.
Receipt settlement, allocation and account link: Receipt settlement says whether the money has settled in the finance records. Payment allocation says whether it was allocated to an assessment. The account identity link says whether the payer account is linked to a canonical party. The outstanding balance says what is still owed. They are four separate facts, and the permit status is a fifth.
Recommendation holds: Cases the agent would hold for a person instead of recommending an outcome. A hold cleared is a case the agent would no longer hold. Identity, parcel, credential, finance and missing-input safeguards and the decision itself stay with the people and checks that own them. The count is of cases and says nothing about time.
Review decision: The Permit Reviewer records the decision of record. An agent recommendation only proposes an outcome and is never the decision. Fee assessment, payment and permit issuance are separate steps after the decision.
Safety signals: Every case that stops failing a rule is listed with the rule, the value it had and the limit before and after, so a person can judge the risk. A case that stops failing a rule still needs a person to look at it.
Service targets: The number of days a permit type is configured to be handled in. The what-if shows the configured figures before and after. No processing time is worked out from them.
Source freshness: Freshness is the last time the source reported a change and the last time the demonstration received or checked a record. The number of open issues is a separate fact. When no time is recorded the screen says that the freshness information is unavailable instead of showing zero.
Source last changed: The time the source system says it last changed the record. It is separate from the time this application last received or checked it.
Steward assistant: The assistant the Data Steward works with on the Data issues queue. It reads the task, gathers the evidence the City already holds and proposes a decision, with a confidence and a one line reason. The steward wakes it, reads every proposal and decides each one: the assistant never decides and never writes a record of its own.
Suggested fields: Suggested fields are values Muse read from the documents. They are proposals only. A value becomes a confirmed value once a steward accepts it; until then it is not a record and nothing was reviewed.
Three different requests: Asking the applicant for information sends the case back with a message. Correcting the application record changes the submitted facts as a new revision. Requesting a source correction refers a master-data problem, such as an address or identity link, to the steward who owns it.
What this action will do: A preview of the records an action would link or leave unlinked, the application relationship that would change, which source values are kept and whether an issue would remain. Nothing is written until you press the action.
What-if run content hash: A short code calculated from everything the run used: the scenario revision, the full baseline and proposed configuration, the cases, the population definition, the analysis moment and the engine and generator versions. It does not include ids or times, so the same inputs always give the same hash.