How Compliance Decisions Are Made
This document explains how Flask Track evaluates compliance during real laboratory execution.
Every time a user attempts to perform an operational action — such as creating, running, approving, exporting, or finalizing work — the compliance engine evaluates the full operational context before allowing the action to proceed.
Compliance decisions are:
- Deterministic
- Framework-driven
- Context-aware
- Runtime-evaluated
- Fully traceable
- Historically auditable
Compliance is not manually assigned to workflows or batches.
It is derived dynamically from the actual biological materials, workflows, protocols, tools, plasmids, regulatory tags, framework rules, approvals, and user authorization state involved in the operation.
High-Level Decision Flow
Whenever an action is attempted, Flask Track evaluates the following sequence:
START
↓
1. What operational entities and materials are involved?
↓
2. What regulatory tags apply?
↓
3. What compliance levels do active frameworks derive?
↓
4. What enforcement rules apply?
↓
5. Are approvals required and present?
↓
6. Are certifications required and valid?
↓
FINAL DECISION:
✓ Compliant
⚠ Requires Approval
✖ Blocked
This evaluation happens continuously at runtime.
Why the System Works This Way
Traditional compliance systems often rely on:
- Static labels
- Manual spreadsheets
- Informal review
- Retrospective audits
- Human interpretation
These approaches create risk because compliance state can become:
- Outdated
- Inconsistent
- Incomplete
- Difficult to audit
- Detached from actual execution
Flask Track instead derives compliance directly from operational relationships and execution context every time an action occurs.
Step 1 — Determine the Regulatory Surface
The first step is determining the full regulatory surface of the operational entity being evaluated.
A regulatory surface is the complete set of regulatory context associated with the entity.
The system evaluates all related biological, procedural, and operational components.
Workflow Evaluation
When evaluating a workflow, Flask Track examines:
- Associated species
- All protocols
- Protocol steps
- Ingredients
- Plasmids
- Tools
- Direct regulatory tags
The resulting regulatory surface represents the combined compliance implications of the workflow.
Batch Evaluation
When evaluating a batch, Flask Track examines:
- The batch species
- The workflow being executed
- All nested protocols and protocol steps
- Ingredients
- Plasmids
- Tools
- Derived regulatory tags
Batches inherit compliance context from the workflows they instantiate.
Sample Evaluation
When evaluating a sample, Flask Track examines:
- The sample species
- Associated batches
- Workflows
- Direct sample-level tags
- Related execution history
This allows sample-level compliance evaluation to remain biologically and operationally aware.
Example Regulatory Surface
A transformation workflow may produce a regulatory surface such as:
- GMO
- Recombinant DNA
- BSL-2
- Plant Pathogen
- Restricted Material
This surface becomes the basis for all downstream enforcement decisions.
Step 2 — Map Regulatory Tags to Compliance Levels
Regulatory tags alone do not determine operational behavior.
Each active compliance framework interprets those tags according to its own severity and enforcement model.
Framework Interpretation
Different frameworks may interpret the same regulatory tag differently.
Example:
| Regulatory Tag | Framework | Derived Compliance Level |
|---|---|---|
bsl2 |
Biosafety Framework | Level 2 |
gmo |
Recombinant DNA Framework | Level 2 |
plant_pathogen |
USDA Framework | Level 3 |
This allows organizations to apply multiple governance models simultaneously.
Compliance Levels
Frameworks typically derive operational severity or compliance levels such as:
- Informational
- Low
- Medium
- High
- Critical
or:
- Level 1
- Level 2
- Level 3
These levels determine how aggressively the system enforces compliance requirements.
Step 3 — Apply Authorization Rules
Once compliance levels are derived, Flask Track evaluates authorization and enforcement rules.
Authorization rules define:
- Which actions are permitted
- Which actions require approval
- Which actions are restricted
- Which actions are completely blocked
Rules are evaluated against:
- Entity type
- Requested action
- Derived compliance level
- Active framework configuration
This creates deterministic runtime enforcement behavior.
Example Authorization Rules
| Compliance Level | Entity Type | Action | Result |
|---|---|---|---|
| Level 2 | Workflow | Run | Requires Approval |
| Level 3 | Batch | Export | Blocked |
| Level 1 | Sample | Archive | Allowed |
Rules may vary significantly between frameworks.
Runtime Enforcement
Enforcement occurs before and during execution.
Examples include:
- Blocking workflow progression
- Requiring approvals
- Restricting exports
- Preventing unauthorized execution
- Requiring checklist completion
- Escalating operational review
This allows Flask Track to proactively reduce operational and regulatory risk.
Step 4 — Approval Validation
Some compliance rules require explicit approval before execution may continue.
If approval is required, Flask Track checks:
- Whether the entity has already been approved
- Which framework granted approval
- Which compliance level was approved
- Whether the approval remains valid
If approval is missing:
⚠ Requires Approval
The action is paused until authorization is granted.
Approval Records
Approval records are stored per:
- Entity
- Compliance framework
- Compliance level
This preserves precise operational traceability.
Examples include:
- Workflow approvals
- Batch approvals
- GMO authorization
- Restricted material authorization
Step 5 — Certification Validation
Organizations may optionally enforce certification-aware authorization systems.
If enabled, Flask Track validates whether the acting user holds the required certification level.
Examples include:
- Biosafety certifications
- Equipment training
- GMO authorization
- Restricted material handling authorization
If certification requirements are not satisfied:
✖ Blocked
The action cannot proceed.
Final Decision Outcomes
Every evaluation results in one of three final states.
✓ Compliant
The action is allowed to proceed.
Requirements satisfied include:
- No blocking rules apply
- Required approvals exist
- Required certifications are valid
- Checklist requirements are satisfied
The operational action continues normally.
⚠ Requires Approval
The framework requires approval before the action may proceed.
Examples:
- GMO workflow execution
- Restricted export operations
- Higher biosafety procedures
The entity must be formally approved before execution can continue.
✖ Blocked
The action is explicitly prohibited under current conditions.
Examples include:
- Missing required certification
- Restricted workflow without authorization
- Framework-level operational block
- Prohibited export conditions
Blocked actions cannot proceed until the underlying issue is resolved.
What Determines Compliance?
Compliance decisions are derived entirely from operational and regulatory context.
This includes:
- Biological materials involved
- Tools and containment systems
- Plasmids and strains
- Workflow composition
- Active compliance frameworks
- Framework severity mappings
- Authorization rules
- Existing approvals
- User certifications
- Runtime operational state
Nothing is manually “marked compliant.”
What Gets Evaluated?
Different entity types derive compliance from different operational sources.
| Entity Type | Derived From |
|---|---|
| Species | Direct regulatory tags |
| Protocol | Protocol-level tags and materials |
| Workflow | Species + Protocols + Steps |
| Batch | Workflow + Species + Runtime Context |
| Sample | Batch + Workflow + Species + History |
This creates highly contextual operational evaluation.
What Is Not Stored
Flask Track intentionally does not permanently store static compliance status.
Instead, compliance is recalculated dynamically every time an action is evaluated.
The system reevaluates:
- Current regulatory tags
- Active frameworks
- Severity mappings
- Authorization rules
- Approvals
- User certifications
- Runtime operational state
This prevents:
- Stale compliance state
- Silent configuration drift
- Hidden operational inconsistency
- Outdated authorization assumptions
Why Dynamic Evaluation Matters
Dynamic evaluation ensures compliance decisions always reflect the current operational and regulatory environment.
Benefits include:
- Continuous accuracy
- Runtime awareness
- Improved audit defensibility
- Reduced manual administration
- Stronger operational traceability
The system always evaluates current reality rather than relying on historical assumptions.
Relationship to Checklists
Checklist applicability is evaluated as part of compliance enforcement.
Based on the derived compliance surface and active framework rules, Flask Track may:
- Activate checklists
- Require evidence uploads
- Restrict progression until completion
- Trigger approval requirements
Checklist applicability is dynamic and context-sensitive.
Relationship to Compliance Events
Operational incidents may also affect compliance decisions.
Examples include:
- Active contamination events
- Open deviations
- Missing corrective actions
- Equipment failures
Compliance Events become part of the broader operational context considered during evaluation.
Runtime Operational Awareness
Compliance decisions are aware of:
- Workflow execution state
- Batch lifecycle state
- Sample history
- Current user authorization
- Active operational incidents
- Existing approvals
- Current framework configuration
This creates execution-aware compliance rather than static classification.
Auditability
Every compliance evaluation is traceable through:
- Regulatory tags
- Derived compliance surfaces
- Framework rules
- Authorization logic
- Approval records
- Certification checks
- Runtime decisions
- Immutable audit logs
This allows organizations to reconstruct why a decision was made at any point in time.
Practical Guidance for Users
Before running regulated work:
- Review the regulatory surface
- Confirm derived compliance levels
- Ensure approvals are present
- Verify certifications remain valid
If the system reports:
⚠ Requires Approval
submit the entity for review under the applicable framework.
If the system reports:
✖ Blocked
review:
- Regulatory tags
- Active framework rules
- Missing approvals
- Certification requirements
- Operational restrictions
Design Principles
The compliance engine is designed to be:
- Deterministic
- Runtime-evaluated
- Framework-driven
- Fully traceable
- Context-aware
- Historically auditable
Every compliance decision is explainable and reconstructable.
Summary
Flask Track determines compliance dynamically from the real operational composition of laboratory work.
The system continuously evaluates:
- What materials and workflows are involved
- Which regulatory tags apply
- How active frameworks interpret those tags
- Which enforcement rules apply
- Whether approvals are present
- Whether users are authorized and certified
The resulting decisions are:
- Runtime-enforced
- Historically traceable
- Operationally contextual
- Framework-driven
- Fully auditable
Compliance is not manually assigned.
It is continuously derived from real laboratory execution.