Engineering Standard • Compliance Governor • All Features & Changes
MyRxWallet North America Corporation
Engineering Compliance Governor
Applies to All Features Required Before Merge No Exceptions Rev. April 2026
Regulatory Scope Language Style Guide Developer Console
Standing Order
No feature ships unless it can be explained to a regulator in plain English.
This is not a bureaucratic requirement. It is the minimum bar for knowing what you built. If you cannot explain the regulatory surface of a feature, you do not yet understand the feature. Build the explanation before you build the feature.
Three Required Questions — Answer Before Every Merge

Every ticket, pull request, and deployment must produce written answers to these three questions. Answers live in the PR description. If answers cannot be written, the feature is not ready.

Q1
Which regulator or authority would care about this change?

Name the specific regulatory body or legal framework this feature touches. If you believe none apply, state that explicitly and explain why. "None" is a valid answer only when it is documented and reasoned, not assumed.

  • Does this feature handle, reference, or route health data? → HHS, ONC, HIPAA
  • Does this feature involve tokens, attributions, or value transfer? → SEC, FinCEN, state money transmitter laws
  • Does this feature display scores, metrics, or rankings? → FTC, CFPB (if financial framing is possible)
  • Does this feature integrate with clinical workflows or EHR systems? → FDA SaMD, ONC certification rules
  • Does this feature store, process, or transmit personal data? → CCPA, GDPR (if EU users), HIPAA
▲
If the answer is "I don't know" — stop. Find out before proceeding. Ignorance of regulatory surface is not a green light.
Q2
What behavior does this feature make impossible by design?

Every feature must reinforce, not erode, our non-scope boundaries. Identify which prohibited behaviors this feature structurally prevents. If the feature introduces new surface area that could be misused, name it — and name the specific constraint that closes it.

  • Does the new API endpoint expose any path to asset custody or key management?
  • Could the new data model store PHI, even indirectly or by inference?
  • Does any new UI element display price, yield, or return language?
  • Could the new function be called in a way that constitutes a financial transaction?
  • Does the new feature make any implicit claims about clinical efficacy or diagnostic utility?
▲
If you cannot name what this feature prevents — you have only described what it does, not how it fits the architecture. That is incomplete.
Q3
How would this look during an audit?

Describe exactly what a regulator, auditor, or counsel would see if they examined this feature. What logs are produced? What data is retained? What decisions are made, and are they explainable? Assume the auditor is adversarial and competent.

  • What does the audit log record for each invocation of this feature?
  • Can every access decision be replayed and explained from stored data alone?
  • Is there any state change that occurs without a corresponding, inspectable record?
  • What would a subpoena of our database reveal about user behavior through this feature?
  • Is the feature's behavior consistent with what our public compliance page states?
▲
If any state change is unlogged, or any decision is unexplainable from stored data, the feature is not audit-ready. Fix that first.
Absolute Stop Conditions

These conditions halt any feature, regardless of how far development has progressed. If someone says "we'll explain it later" — that phrase is itself a stop condition.

■
"We'll explain the compliance angle later."
Later never comes. Compliance framing that cannot be written before merge will not be written after deploy. Stop the feature.
■
The feature introduces a path to prohibited behavior.
Any code path that — even indirectly — enables asset custody, PHI storage, price display, or financial transaction processing must be removed before merge. No exceptions for "edge cases."
■
The feature cannot be described in the language of the Style Guide.
If you cannot describe the new feature using approved terms from trinh.io/style-guide, the feature either violates scope or was not designed with compliance in mind. Redesign before shipping.
■
The three required questions have no written answers.
Verbal answers in a standup are not answers. Written answers in the PR are the only acceptable form. No written answers = feature does not merge.
■
The feature contradicts the live Regulatory Scope page.
trinh.io/compliance is a public declaration. Any feature that makes a statement on that page false — even implicitly — must either be redesigned or the page must be updated first, with full review.
Regulatory Review Categories

Use this to quickly identify which review lens applies to a given feature. A feature may fall under more than one category.

Securities & Financial
  • Any token, attribution, or distribution logic
  • Any feature touching MRxRoyalty flows
  • Any UI referencing value, return, or earnings
  • Any integration with external financial APIs
Healthcare & HIPAA
  • Any feature handling health records or EHR data
  • FHIR resource reads, writes, or transforms
  • Drug provenance or supply chain features
  • Any clinical workflow integration
Identity & Privacy
  • Any feature reading or writing MRxID data
  • Credential attestation or verification logic
  • MRxScore calculation or display changes
  • Any new user data collection point
Operations & Audit
  • Any change to logging or audit trail structure
  • New API endpoints with external access
  • Authentication or authorization flow changes
  • Database schema changes touching user records
MRxDAO Governance & Sentinel AI
  • Any change to DAO governance logic or proposal structure
  • Any feature affecting Platinum Grade classification criteria
  • Any change to AML/KYC screening rules or Sentinel AI thresholds
  • Any feature granting or revoking privileged credentials or licenses
  • Any modification to fraud detection patterns or anomaly rules
  • Any new participant onboarding flow (individual or entity)
  • Any change to MRxDAO voting, staking, or treasury logic
  • Any feature that Sentinel AI would monitor — before it ships
Sign-Off Requirements by Feature Type
Standard feature
Written answers to all three questions in the PR description. Self-reviewed against stop conditions.
Touches MRxRoyalty or any distribution logic
Written answers + explicit securities law non-applicability statement. No merge without documented Howey test analysis.
Touches health data, FHIR, or EHR integration
Written answers + explicit PHI non-storage confirmation + HIPAA covered entity non-applicability statement.
Changes the public Regulatory Scope page
Requires full review of all downstream documents: Style Guide, Diligence Pack, Orientation. All must be updated simultaneously.
New external API endpoint
Written answers + rate limiting confirmed + authentication verified + audit log entry confirmed for every invocation.
Touches MRxDAO governance or Platinum Grade logic
Written answers + explicit statement that change aligns with Wyoming SF0038 DAO LLC structure + confirmation that federal and state law alignment is preserved. MRxDAO governance is the highest review tier — no merge without DAO-level sign-off.
Touches Sentinel AI rules, AML/KYC logic, or fraud detection thresholds
Written answers + confirmation that Sentinel AI remains in a monitoring/flagging role only (not autonomous enforcement) + FinCEN/BSA alignment statement + MRxDAO governance review of any threshold changes.
Issues, modifies, or revokes a privileged credential or Platinum Grade classification
Written answers + full MRxDAO governance review + documentation that the classification change is not a financial designation + audit log entry with issuing governance action recorded on-chain.

Compliance is not a department. It is an engineering discipline.

A feature that passes this checklist is a feature we can defend — to a regulator, to counsel, to a partner, to MRxDAO, and to ourselves.

🛡 MRxDAO Governed • Sentinel AI Monitored • No Feature Ships Without Answers
MyRxWallet North America Corporation — trinh.io/engineering-governor Internal engineering standard. Also published as a signal of institutional discipline.