Here’s a familiar problem: You’re shipping code, and somewhere in your head, a checklist runs on loop. Did we handle PII properly? Are we logging the right things? Does this touch payment processing? Did someone review this for security?
Most teams solve this with checklists. Shared documents. Reminders in Slack. Prayers. What if instead, your tooling enforced compliance automatically? Not as nagging or friction, but as part of your natural workflow. As part of the commit process. As something Claude Code could verify in seconds.
That’s what we’re building here: compliance check skills—reusable, automation-friendly specifications that verify your code and configuration against regulatory requirements before it ships. Think of them as executable policy documents that guard against the mistakes humans make when they’re tired, rushing, or working across a large distributed codebase.
We’ll walk through the full picture: how to design a compliance skill, what the SKILL.md looks like, how to wire it up to pre-commit and pre-push hooks, how to generate structured reports with evidence, and real examples for SOC2, HIPAA, and GDPR. By the end, you’ll have a system that scales compliance checking from “everyone reads the policy” to “the tooling enforces it.”
Understanding Compliance as Automation
Before we write any code, let’s reframe what compliance actually is. Compliance isn’t a document. It’s not a checklist that someone reviews once during onboarding. Compliance is a set of verifiable requirements that apply to every change, every deploy, every interaction with sensitive data. The best compliance systems treat it not as a burden but as a feature of the platform—something that makes shipping faster because you never have to wonder if you’re breaking a rule.
Most compliance work is repetitive and predictable. Does this code access customer data? If yes, log every access. Are we rotating secrets properly? Check that rotation is configured. Is this database encrypted? Verify encryption settings. Did someone review this change? Require approval before merge. Does this touch payment cards? Flag for PCI-DSS review. Is PII being transmitted over secure channels? Scan for hardcoded URLs, unencrypted data. Are we following our naming conventions for sensitive data structures? Prevent accidental exposures. Is there proper error handling for authentication failures? Avoid information leakage.
These checks have three things in common: they’re deterministic (same input always gives the same result), they’re repetitive (we check every single commit), and they’re machine-verifiable (a tool can check them without human judgment). That makes them perfect for automation.
A compliance check skill isn’t a replacement for human judgment. It’s an automated filter that catches obvious violations before they reach code review, surfaces gray areas that do need human judgment, and provides evidence trails that satisfy auditors. The beauty of this approach is that it democratizes compliance knowledge. A junior developer doesn’t need to memorize HIPAA regulations. They commit code, and the tooling tells them exactly what’s wrong and how to fix it. This is how you scale from a small startup to an enterprise without your compliance burden growing linearly.
Designing Your First Compliance Skill
Let’s build a real example: a SOC2 audit trail skill. This is a practical, concrete problem that every company handling customer data faces.
SOC2 requires that we log every access to production systems. Each log entry should include timestamp, user, resource accessed, and action taken. Logs must be retained for the compliance period. Logs should be tamper-evident (ideally immutable). Related actions should be traceable through session IDs.
Our skill will check that any code touching production either goes through a centralized logging service, OR logs to a verified audit table with immutability enabled. It’s practical because it’s specific, measurable, and enforceable.
Problem Definition: We ship code without verifying it includes proper logging. We might accidentally log to stdout which disappears, or forget logging entirely. This creates audit gaps and compliance risk. Additionally, scattered logging implementations mean our audit trails are inconsistent, making forensic analysis difficult.
Success Criteria: Every code change that touches production data or auth gets flagged for logging verification. The tool provides specific remediation steps. False positives should be rare. False negatives are critical—missing a logging requirement is worse than being overly cautious.
Input & Output: Input is a code change: files changed, diff, file paths. Output is a report with PASS, FAIL, or REVIEW status. Each item includes file path, line number, the concerning code, and remediation steps.
Scope Boundaries: We check code files but skip test files and documentation. We flag any connection to production systems, PII, or auth. We understand third-party logging frameworks that handle logging transparently.
Edge Cases to Consider: Logging in middleware versus endpoint-level logging—what counts as sufficient? Async logging that might lose messages during crashes—when is it acceptable? Development-only credentials versus production secrets—how strict should we be? Library code versus application code—different standards?
The Compliance Skill SKILL.md
Here’s the complete SOC2 audit logging skill structure. The frontmatter defines metadata: name, description, trigger phrases, integrations it plugs into, requirements like file-reader and git-diff-parser, and output artifacts. The body describes the purpose, when to use it, and the process phases.
The process has four phases: Scan (identify which files touch production), Analyze (check for logging), Report (generate structured evidence), and Remediate (provide code examples). Each phase is concrete with specific patterns and decision trees.
The scan phase identifies files touching production using pattern matching. It looks for database queries, API calls, environment variable access, file operations, password/API key references, email/phone/SSN patterns, auth-related code.
The analysis phase builds a decision tree. Does the file touch production? No → pass. Yes → does it include logging? No → FAIL (missing logging). Yes → is logging going to an approved system? If not → REVIEW. If yes → is log complete? If no → REVIEW. If yes → PASS.
The report phase generates structured findings. Each finding has file, line, issue, severity, requirement, and remediation steps. The report can be JSON for machines or markdown for humans.
The remediation phase provides code examples showing how to fix violations. It shows before and after code, highlighting the differences.
Wiring into Hooks
Once you have the skill defined, integrate it into your workflow via pre-commit and pre-push hooks. Pre-commit runs locally before staging, catching issues early. Pre-push runs before pushing to remote, providing a final gate.
Pre-commit hooks identify changed files, dispatch the compliance skill, and abort commit if FAIL status is returned. Pre-push hooks check commits not yet on main, run comprehensive compliance checks, and require PASS status before allowing the push.
If pre-commit is too slow, run it in the background with a deadline. If false positives are blocking legitimate commits, adjust patterns in config. If developers bypass hooks with –no-verify, configure CI to not allow it.
Real-World: HIPAA Compliance
Let’s extend this to HIPAA for healthcare apps. HIPAA requires access logs for all PHI, encryption in transit and at rest, user authentication and authorization, regular security reviews, and breach notification procedures.
A HIPAA compliance skill would flag files touching PHI (patient, medicalRecord, diagnosis, treatment, prescription, medication, SSN, MRN, etc.). For each PHI access, it checks encryption in transit (HTTPS/TLS required), encryption at rest (database encryption, field-level encryption), access logging (audit trail), authentication enforcement, and authorization checking.
The report would show critical issues for unencrypted transmission or storage, high issues for missing logging or weak auth, and medium issues for other gaps. Each finding links to specific HIPAA requirements (like HIPAA 164.312(a)(2)(i) for encryption in transit).
Real-World: GDPR Compliance
GDPR focuses on data subject rights and consent. It requires tracking where data comes from, implementing right to access, implementing right to deletion, data minimization, and purpose limitation.
A GDPR compliance skill checks: Is there a consent record? Can users export their data? Can users request deletion? Is purpose tracked? Is data minimized? The report flags missing consent tracking, missing data export endpoints, missing deletion endpoints, collection of unnecessary data, and data used for purposes not explicitly consented to.
Structuring Reports for Evidence
When a compliance check runs, it produces evidence—something you can show to auditors, regulators, or your compliance team.
A good report includes metadata (skill name, run time, branch, commit, who ran it), summary (status, files analyzed, issues found, critical/high/medium/low counts), and detailed findings. Each finding has ID, file, line, severity, category, requirement, description, evidence, and remediation.
Save this to JSON. It’s machine-readable, auditable, and ties every finding to specific code location and regulatory requirement. This is your evidence trail when auditors ask “How do you ensure compliance?”
Advanced: Building a Multi-Compliance Skill Suite
In practice, you’ll build a suite covering all your regulatory requirements. A master compliance orchestrator runs SOC2, HIPAA, GDPR, and PCI-DSS checks in parallel. It aggregates findings, prioritizes critical issues, and generates consolidated reports.
This shows overallStatus (FAIL if any framework fails), critical/high/medium/low counts, framework results, action required items, and approval gates. A single report tells teams what needs fixing and who needs to approve before merge.
Testing Your Compliance Skills
Before deploying a skill to production, test it thoroughly. Create test branches with positive cases (code that should PASS), negative cases (code that should FAIL), and edge cases (code that should REVIEW).
Only once all test cases pass should you enable the skill in pre-commit hooks. Testing prevents false positives from frustrating developers and false negatives from missing real issues.
Handling False Positives and Edge Cases
No tool is perfect. Compliance skills will sometimes flag code that actually is compliant. Handle this by excluding test files from scanning, excluding development-only code, whitelisting approved frameworks that handle logging transparently, and configuring severity levels.
Configure these patterns in your skill’s configuration, and false positives drop dramatically. The key is being explicit: what counts as compliant and what patterns are acceptable workarounds?
CI/CD Integration
Wire compliance skills into your CI/CD pipeline. When code is submitted via pull request, run compliance checks automatically. Comment on the PR with results. Block merge if compliance fails. This ensures no code reaches production without passing.
The compliance workflow becomes part of your development process, not a separate concern. Developers get immediate feedback on compliance issues during development when they’re easiest to fix.
Making Compliance Scalable
Compliance doesn’t scale if every developer memorizes every rule. What scales is automation, clear remediation, integration into workflow, gradual rollout, and evidence trails.
With Claude Code compliance skills, you get all five. As your company grows from 10 developers to 100, your compliance burden doesn’t grow linearly because the tooling handles it.
Updating Skills Over Time
Compliance requirements change. Your skill definitions should too. Use semantic versioning for your skills. Document what changed in each version. Test all test cases again. Consider backward compatibility. Announce changes to your team.
This way, compliance checking stays current as regulations evolve and you learn new patterns.
The Auditor’s Perspective
When auditors evaluate your compliance practices, they want to see three things: documented policies, evidence that you follow those policies, and a mechanism that ensures consistent compliance.
Compliance check skills directly address all three. Your policies are encoded in the skill definitions—they’re documented. Your evidence is generated by every commit—the reports show exactly what was checked and why it passed or failed. Your mechanism ensures consistency—the same checks run for every commit, every time.
From an auditor’s perspective, this is ideal. Instead of reviewing a few cherry-picked releases and hoping you’re representative, auditors can see complete records for every single commit. They can see that you actually catch violations before they ship. They can see your remediation process in action.
This is so much more convincing than a manual certification process. “We have a checklist that people follow” is weak. “We have automated tools that enforce compliance and log every check” is strong.
Scaling Compliance Across Teams
As your organization grows, compliance becomes harder. You have more developers, more codebases, more potential for inconsistency. Manual enforcement breaks down. Policies get forgotten or misinterpreted.
Compliance check skills scale perfectly because they automate and standardize the enforcement. A junior developer, a senior engineer, and a contractor all run the exact same compliance checks. There’s no ambiguity, no interpretation. Either the code passes or it doesn’t.
This means you can hire aggressively without worrying that new employees don’t understand your compliance requirements. The tools enforce them. You onboard faster. You maintain consistent standards across all teams.
Building a Compliance Culture
Over time, as developers see compliance checks working reliably and helping them write better code, something shifts in the culture. Compliance becomes less of an imposed burden and more of a shared value. Developers start asking “does this pass compliance checks?” proactively rather than waiting to be told.
This cultural shift is valuable because it means compliance becomes intrinsic rather than extrinsic. You’re not compliant because you have to be—you’re compliant because you want to be, because you see the value in it.
Claude Code facilitates this cultural shift by making compliance frictionless. When compliance checks are automated and provide clear remediation paths, developers feel supported rather than constrained.
From Compliance to Competitive Advantage
Here’s the interesting observation: companies with strong compliance practices often have better engineering practices overall. Compliance requires careful design, thorough testing, clear documentation, and attention to edge cases. These are the exact characteristics of well-built systems.
So while compliance might feel like a regulatory burden, it’s actually forcing you to build better systems. And better systems are more reliable, more secure, more performant. They become competitive advantages.
Your ability to say “we’re SOC2 compliant” might win you enterprise customers. Your ability to say “we’re HIPAA compliant” opens healthcare markets. Your ability to say “we’re GDPR compliant” enables EU expansion.
Compliance check skills make all of this possible at scale. You’re not just checking boxes for auditors—you’re building systematic excellence that differentiates your product.
Advanced Customization
While we’ve shown standard frameworks like SOC2, HIPAA, and GDPR, you can build compliance skills for anything:
- Internal standards – Your company’s security baseline, code style requirements, API design principles
- Industry-specific – If you’re in fintech, regulations specific to fintech. If you’re in government, regulations specific to government contracting.
- Customer requirements – Some customers require specific compliance practices. Build skills that verify you’re meeting them.
- Performance standards – Not regulatory, but critical: “this change doesn’t degrade performance by more than 5%”
The same framework works for all of these. Define what needs checking, implement the checking logic, integrate with hooks, generate reports.
Real-World Impact on Development Velocity
Something unexpected happens when you implement compliance check skills: development actually speeds up. This seems counterintuitive—”adding safety checks should slow us down, right?”
But in practice, safety checks remove friction from the development process. Instead of a developer wondering “is this compliant?”, the tool tells them exactly. Instead of code review including a compliance discussion, the tool has already verified compliance. Instead of deployment being delayed waiting for compliance sign-off, it’s already checked.
Moreover, because compliance violations are caught early and clearly remediated, developers ship code with confidence. They don’t ship, then get rejected by compliance, then have to rework. They work right the first time. When you remove uncertainty—”will this pass compliance?”—you remove friction. Developers can focus on writing features instead of worrying about regulatory gaps.
This is sometimes called “shifting left”—moving quality checks earlier in the development process. The earlier you catch problems, the cheaper they are to fix. Compliance check skills are shift-left on steroids. A compliance violation caught at pre-commit costs 5 minutes to fix. The same violation caught at code review costs 30 minutes. Caught at production, it might cost hours of firefighting or worse, result in a regulatory violation that damages your business.
Developer Experience and Self-Service Compliance
The best compliance systems don’t require developers to understand all the regulations. They require developers to understand what the tool is telling them. “This code needs audit logging” is something developers can fix. “This code violates HIPAA 164.312(a)(2)(ii)” is something that requires a compliance expert to interpret.
Claude Code skills bridge this gap. They translate regulatory requirements into developer-actionable feedback. The skill says “this file touches PHI but doesn’t have encryption configured, here’s how to fix it.” The developer fixes it. The tool verifies it. No regulatory expertise required.
This self-service model scales beautifully. As your organization grows, you don’t need to hire more compliance officers to scale compliance checking. You invest once in building good compliance skills, then every developer benefits. It’s leverage.
Integration with Development Workflows
Compliance skills integrate at multiple points in your development workflow:
- Local development: Pre-commit hooks catch issues before code is even staged
- Pull requests: Compliance checks run automatically, providing feedback before review
- Code review: Reviewers see compliance status, reducing time spent on compliance discussions
- CI/CD: Compliance gates prevent non-compliant code from reaching production
- Deployment: Final verification ensures compliance before production deployment
Each integration point provides a safety net. If one layer is bypassed or fails, another catches it. This defense-in-depth approach ensures compliance.
Measuring Compliance
As with any system, you should measure compliance metrics:
- Coverage – What percentage of code changes are being checked by compliance skills?
- Failure rate – What percentage of changes fail compliance checks initially?
- Time to remediation – How long does it take developers to fix compliance violations?
- Audit pass rate – What percentage of your compliance audits pass on first attempt?
These metrics help you understand the effectiveness of your compliance system. If failure rate is too high, maybe your requirements are too strict. If remediation time is too long, maybe your error messages need to be more helpful. If audit pass rate is low, maybe you’re missing something important.
Claude Code can track these metrics automatically and flag trends worth investigating.
Building Compliance Into Product Development
The most sophisticated teams integrate compliance thinking into product development from the start, not just code changes. Before you design a new feature, ask: “what compliance implications does this have?” Before you store data, ask: “what regulations apply?”
Claude Code can help here too. It can generate compliance checklists for new features, highlight regulatory implications during design reviews, and verify compliance throughout implementation.
This prevents the scenario where you ship a feature that technically works but creates regulatory problems. It shifts compliance from “something we deal with after implementation” to “something we consider during planning.”
Summary
A compliance check skill is a reusable automation that verifies code against regulatory requirements before it ship. We’ve built examples for SOC2, HIPAA, and GDPR—but the same pattern works for PCI-DSS, FedRAMP, ISO 27001, or any custom policy.
The key elements are skill definition, scan phase, analysis phase, report phase, remediation phase, hook integration, testing, false positive handling, CI/CD integration, and continuous updates.
What you get: Compliance runs automatically, not manually. Every violation includes a remediation path. Evidence is auditable and tied to requirements. False positives are rare. False negatives are extremely rare. Your team ships faster because compliance is built in. Auditors see a complete evidence trail.
Beyond just meeting regulatory requirements, compliance check skills help you build better systems, scale your team without losing consistency, create competitive advantages, and develop a culture where compliance is valued as part of excellence.
Continuous Compliance Monitoring
Compliance isn’t a point-in-time check at commit time. It’s an ongoing responsibility. Code deployed weeks ago should still be compliant. Dependencies should still be patched. Security configurations should still be correct.
Claude Code can implement continuous compliance monitoring that runs on a schedule, checking everything already deployed. This catches cases where configuration has drifted, where a dependency has been patched but you haven’t upgraded yet, or where infrastructure has been modified outside of your standard processes.
When monitoring detects issues, it can alert you, trigger remediation, or require manual approval depending on severity. This continuous lens catches problems that discrete point-in-time checks would miss.
Compliance as a Competitive Feature
Here’s a subtle but important shift: compliance as competitive advantage rather than regulatory burden. Companies with strong, visible compliance practices often win more customers, especially in regulated industries.
Your ability to say “we’re SOC2 compliant” might win enterprise customers. Your ability to say “we’re HIPAA compliant” opens healthcare markets. Your ability to say “we’re GDPR compliant” enables EU expansion. These aren’t just regulatory checkboxes—they’re customer-winning features.
When your compliance is automated and visible (you can show audit logs, evidence trails, automated checks), it becomes easier to market and easier to defend. “Our compliance is automated and logged, not manual and error-prone” is a powerful differentiator.
Training and Onboarding with Compliance
New team members learn your compliance requirements by experiencing them in action. They commit code, the compliance skill runs, they see violations and how to fix them. No need for hour-long compliance training—they learn by doing.
Over time, they internalize the standards. What seemed like friction at first becomes natural. They proactively check that their code would pass before even committing.
This learning-by-doing approach is more effective than document reading or training videos. It’s experiential, immediate, and directly tied to their work.
Building Composable Compliance
Rather than a monolithic compliance check, build composable pieces that combine. A “data protection” skill might check encryption. A “logging” skill might check audit trails. A “authentication” skill might check access controls. Each is independently testable and deployable.
As new requirements emerge, you add new skills without modifying existing ones. Your skill suite grows to cover more requirements over time. This composition pattern makes your compliance system scale and evolve. When you discover you need to add a new compliance requirement, you create a new skill rather than modifying everything else. This keeps complexity manageable and prevents regression in existing areas.
From Compliance to Excellence
The most important shift is seeing compliance not as a burden but as a forcing function toward excellence. Compliance requirements like “implement audit logging” force you to think about observability and understanding system behavior. Requirements like “encrypt sensitive data” force you to think about cryptography and key management. Requirements like “implement role-based access control” force you to think about authorization and security boundaries.
Companies that embrace compliance end up with better-engineered systems than companies that resist it. The security practices required by compliance just happen to overlap significantly with the practices that make systems more reliable, more maintainable, and more performant. Audit logging helps with debugging. Encryption protects data and prevents breaches. Access control prevents accidental damage and insider threats. These practices serve your business interests even without regulatory requirements.
Claude Code compliance skills make this shift possible. They turn what could be a burden into an enabler of good engineering practices. Your compliance checking becomes indistinguishable from your quality checking. They’re the same thing. When you can’t tell the difference between “compliance best practices” and “engineering best practices,” you’ve succeeded. You’re not maintaining two separate standards—you’re maintaining one standard that satisfies both business and regulatory requirements.
The Path Forward
Building compliance check skills takes initial investment. You need to understand your regulatory requirements, translate them into executable checks, integrate them into your workflow, and maintain them as requirements evolve. But once built, they provide ongoing leverage.
Every commit is automatically checked. Every developer benefits without having to understand the regulations. Your audit trail is automatically created. Your risk profile is continuously monitored. You’ve converted a regulatory burden into automated infrastructure that makes your entire organization safer, more compliant, and more capable.
Start with one framework—SOC2 if you serve enterprises, HIPAA if you’re healthcare, GDPR if you have EU users. Build one skill. Integrate it into your workflow. See the value. Then expand to other frameworks. Over time, you build a comprehensive compliance automation suite that covers all your regulatory requirements.
Your organization will be more confident in deployments. Your auditors will be more satisfied with your evidence trails. Your customers will trust you more knowing you have automated compliance checking. And your developers will be happier not worrying about regulatory compliance—the system has their back.
Compliance as Risk Management
Behind every compliance requirement is a risk that regulations are designed to mitigate. Understanding the risk helps you understand why the requirement exists and how to implement it intelligently.
SOC2’s audit logging requirement exists because auditors need to understand what happened when. Without logs, you can’t investigate incidents or prove you followed policies. The requirement isn’t “log everything”—it’s “log enough that you can reconstruct what happened when needed.”
HIPAA’s encryption requirement exists because unencrypted data is trivially exposed if systems are compromised. The requirement isn’t “use AES-256″—it’s “use encryption strong enough that eavesdropping is impractical.”
GDPR’s right to deletion requirement exists because individuals should control their personal data. The requirement isn’t “delete immediately”—it’s “delete within a reasonable timeframe and with reasonable effort.”
When you understand the risk, you can implement compliance in ways that actually reduce risk instead of just checking boxes. Compliance check skills should encode this understanding, not just pattern-matching against regulations.
Scaling Compliance Across Your Organization
As your organization grows, compliance becomes more complex. You have multiple teams, multiple codebases, multiple deployment targets. Enforcing compliance consistently becomes harder.
Compliance check skills scale because they’re automated and standardized. Every developer, every codebase, every deployment uses the same checks. This consistency is powerful because it means:
- You don’t rely on people remembering policies
- You don’t have to train every new developer on compliance
- You don’t have gaps where one team is compliant and another isn’t
- You can change policies globally by updating the skill definition
This is especially important as you scale to 100+ developers across multiple teams. Manual enforcement breaks down at scale. Automation scales infinitely.
Building a Compliance Culture
Over time, as developers experience compliance checking working reliably and helping them write better code, something shifts in the culture. Compliance becomes less of an imposed burden and more of a shared value.
Developers start asking “does this pass compliance checks?” proactively. They begin to understand why compliance matters, not just that it’s required. They recognize that compliance requirements often align with good engineering practices.
This cultural shift is valuable because it means compliance becomes intrinsic rather than extrinsic. You’re compliant because you want to be, because you see the value, because you understand the risks being mitigated.
Claude Code facilitates this shift by making compliance frictionless. When compliance checks are automated, provide clear remediation paths, and educate developers about why requirements exist, compliance becomes a feature of your platform, not a burden imposed from outside.
Advanced: Custom Compliance Frameworks
While we’ve covered standard frameworks (SOC2, HIPAA, GDPR), many organizations need custom frameworks:
- Industry-specific: Fintech has unique requirements around financial data handling. Healthcare has privacy requirements beyond HIPAA. Government contractors have FedRAMP and FISMA requirements.
- Company-specific: Your company might require that all production deployments have a specific approval process. Or that all customer-facing code goes through security review.
- Customer-specific: Your enterprise customers might require specific compliance practices. Build a skill that verifies you’re meeting their requirements.
The same framework we’ve described works for all of these. Define what needs checking, implement the checking logic, integrate with hooks, generate reports. The pattern is universal.
Measuring Compliance Effectiveness
As with any system, you should measure how well your compliance checking works:
- Coverage: What percentage of code changes are being checked?
- Failure rate: What percentage of changes fail checks initially?
- Time to remediation: How long does it take developers to fix violations?
- Audit results: When auditors review your compliance, do you pass with flying colors?
- Developer satisfaction: Are developers happy with the compliance system or frustrated by it?
Track these metrics over time. Use them to guide improvements to your compliance skills. If failure rate is too high, maybe requirements are too strict. If remediation time is too long, maybe your error messages need to be more helpful.
The Long-Term Vision
The long-term vision for compliance check skills is making compliance invisible. It’s not something developers think about or worry about—the system handles it automatically. They write code, the system verifies compliance, they ship with confidence knowing they’re compliant.
This vision is achievable. It requires investment in building good skills, integrating them properly into your workflow, and maintaining them as requirements evolve. But once you achieve it, you have a tremendous competitive advantage: your organization can move fast without sacrificing compliance.
You’re not slowed down by compliance. You’re enabled by it. Your developers can focus on writing features instead of worrying about regulatory gaps. Your auditors get complete evidence trails automatically. Your customers trust that you’re serious about compliance.
That’s the promise of compliance check skills. Not compliance as friction, but compliance as enablement.
-iNet