This page explains the range of disciplines where governed admissibility directly applies and why testers in those disciplines should test outputs before they become claims, actions, records, or decisions.
What is this output, artifact, instruction, transition, or claim allowed to become?
generated or proposed output → declared intent → domain context → authority / evidence / replay / consequence checks → admissibility decision → allowed next state
| Discipline | Why governed admissibility applies | Typical test object |
|---|---|---|
| AI / LLM systems | Outputs can become claims, tool calls, agent actions, or automation inputs. | Model response, tool call, agent plan |
| Mathematics / formal methods | Proof attempts and derivations require posture before becoming claims. | Lemma, derivation, solver artifact |
| Software engineering | Suggestions can become code, workflows, deployments, or scheduled actions. | Pull request, script, workflow |
| Cybersecurity / identity | Access and identity transitions require explicit authority and consequence posture. | Token use, permission change, identity assertion |
| Data governance | Data movement changes privacy, provenance, and evidence posture. | Dataset, export, record merge |
| Legal / policy | Text can affect rights, obligations, compliance, or institutional posture. | Policy draft, legal summary, compliance claim |
| Medicine / health | Outputs can be treated as advice, risk classification, or care direction. | Health explanation, triage note, care instruction |
| Finance / markets | Claims can influence allocation, payment, risk, or investment behavior. | Financial summary, risk statement, transaction proposal |
| Education / learning | Outputs can shape curriculum, assessment, tutoring, or claims of competence. | Lesson, assessment, grading rationale |
| Science / research | Findings require source posture and reproducibility posture before publication. | Hypothesis, analysis result, citation map |
| Engineering / infrastructure | Recommendations may affect physical systems, uptime, maintenance, or safety. | Design decision, inspection note, operational change |
| Robotics / autonomy | Plans may become physical-world actions or safety overrides. | Motion plan, task instruction, autonomous action |
| Journalism / public information | Outputs may become public claims, source summaries, timelines, or narratives. | Article draft, timeline event, public claim |
| Government / civic systems | Outputs may affect eligibility, services, authority, or public trust. | Decision memo, eligibility rule, service action |
| Organizational governance | Approvals and overrides require authority, quorum, evidence, and consequence posture. | Approval chain, exception, board action |
| Archives / records / history | Claims require provenance, source posture, and review posture. | Timeline event, source annotation, historical claim |
The discipline registry identifies where admissibility applies. The test matrix identifies which test pages a tester should run first for their discipline. The demo now accepts dynamic tester packets so these classifications can be exercised live.
discipline → recommended test route → dynamic tester packet → authority / evidence / replay / consequence checks → admissibility decision → result packet
Discipline: Test object: Recommended route: Declared intent: Authority source: Evidence posture: Replay posture: Consequence level: Decision: Allowed next state: Required follow-up: Claim limit:
Tester packets give outside reviewers a common shape for returning admissibility classifications without claiming domain certification.
tester-output.template.json → dynamic demo input → admissibility result packet → review / receipt / registry posture