TL;DR: Pandorian introduces the first enforceable engineering standards library, built from patterns already proven inside large-scale, production-grade codebases. Over 1,000 guidelines across more than 100 packages, spanning 12 dimensions of engineering governance, and growing. Every guideline is statically enforceable, not theoretical best practice. Enable a package, and it runs on every pull request and repository scan immediately.

World-class engineering organizations already govern their codebases through Pandorian, across dozens of repositories, multiple languages, and pull request volume no internal guideline document was ever built to survive.

The Package Library takes that same standard and makes it available on day one: over 1,000 guidelines across more than 100 packages, each one scored for focus, clarity, and enforceability before it shipped.

These are not best practices that sounded reasonable in a meeting. They are standards proven at the scale where engineering governance actually gets tested, now enforceable from day one.

Built From What World-Class Teams Already Enforce

Every guideline in the library started as something already enforced inside demanding, large-scale codebases: a security check senior engineers repeated in every review, an architecture rule that only survived because someone remembered to bring it up. The library turns that operating knowledge into guidelines any organization can enable, whether or not they have engineers left who remember why the rule exists.

That matters more as AI writes more of the code entering production. According to Veracode’s 2026 GenAI Code Security Report, AI tools now generate roughly half of all newly committed code in organizations that use them, and only 56 percent of that code passes security testing. A guideline library that was only ever theoretical was never going to catch that. One proven at enterprise scale has a better shot.

Twelve Dimensions of Engineering Governance

The library spans twelve dimensions, each one a distinct axis of how software organizations govern their codebases:

• Architecture, Quality, Reliability & Observability
• Security
• Language Best Practices
• Regulatory Regimes
• Industry Best Practices
• Compliance Frameworks
• Infrastructure as Code
• Data & Storage
• General Baselines
• Event Driven
• Cloud Platforms
• API Design

Every guideline is assigned to exactly one of eight enforcement categories: Security, Reliability & Resilience, Observability, Data & Storage, Architecture, Performance & Scalability, Code Quality & Maintainability, and Infrastructure & Environments. Violations roll up by category, package, and dimension, so leadership can see where the codebase stands at whatever level the question is being asked.

This is a living library. Packages are added and refined continuously as standards evolve, frameworks change, and new regulations land.

Enforceable at Scale, Not Just on Paper

Code review was never built to hold a thousand standards in a reviewer’s head, and it was never built to express what organizational leadership decided matters, either. Code review tools are built for developers: they use an opinionated AI to catch bugs a reviewer might miss, not to enforce the specific standards a CTO or VP of Engineering set for the organization. SAST tools are similarly opinionated, covering known vulnerability patterns only, often at the cost of noise. Linters catch syntax, nothing deeper.

None of those tools were built to close the gap CircleCI’s 2026 State of Software Delivery report just measured across more than 28 million CI workflow runs: as feature-branch throughput grew 59 percent year over year, main-branch success rates fell to 70.8 percent. More code is entering the pipeline. Less of it is reaching production cleanly.

Pandorian is built for that gap specifically: leadership’s own standards, enforced through deep semantic analysis, on every pull request and every repository scan, the same way whether the code came from a senior engineer or an autonomous agent.

A Short Taste of What Pandorian’s Packages Contain

Packages hold specific, enforceable rules rather than themes. Below are three guidelines from each of two separate packages, a small sample of what each one contains and a fraction of what Pandorian enforces across an engineering organization at scale.

Import Boundary Discipline

This package governs how modules are allowed to depend on each other, the architecture that erodes quietly until nobody can change one thing without breaking another. Three of its guidelines:

• Never import an outer layer from an inner layer. Always keep imports flowing inward, so that domain code imports nothing from application, and application imports nothing from infrastructure or presentation. Never import a controller, HTTP framework type, ORM entity, or SDK client from domain code.
• Never import a test utility or fixture into production code. Never import a test helper, fixture, mock, stub, factory, or testing library from a non-test source file. Always keep test-only code in test directories or test-scoped packages.
• Never import a module solely for its side effects. Always import modules for the symbols they export and perform initialization through an explicitly called function. Never write a bare import whose only purpose is to execute module-level registration, patching, or configuration.

The rest of the package covers circular imports, undeclared transitive dependencies, wildcard imports, dynamic import paths, and more.

Public API Design Best Practices

A separate package, governing the contracts you cannot quietly take back once someone is depending on them. Three of its guidelines:

• Never remove or repurpose a field within a published API version. Never remove a field, rename a field, narrow a field’s type, or change the meaning of an existing field or enumeration value in a published API version. Always introduce such changes as additive fields or as a new API version.
• Never include exception detail in an API error response. Never place an exception message, stack trace, SQL statement, framework diagnostic, or internal hostname or path into an API error response body. Always return a generic message with a correlation identifier and record the detail in server-side logs.
• Maintain a committed API specification that matches the implemented routes. Always maintain an OpenAPI or equivalent machine-readable specification in the repository that declares every public route, its request and response types, and its error responses, and always generate it from or validate it against the implemented handlers. Never publish an endpoint that is absent from the specification.

The rest of the package covers versioning, status code semantics, cursor pagination, request validation, rate limiting, and more.

Worth noting what sits inside that second package: guidelines assigned to Security alongside guidelines assigned to Architecture. Packages are organized around a real engineering concern, not around a reporting category, because that is how the concern actually shows up in code.

Proven at Scale. Enforceable on Day One.

The Package Library is not a guess at what good engineering looks like. It is a growing body of guidelines built from patterns already proven at enterprise scale, organized so you can turn them on today.

Enforceable was never the hard part. Having standards worth enforcing was.

Common Questions

Written by Daniel Avital, CEO & Co-Founder at Pandorian

Related Reading

• Introducing Guidelines as Code
• Any Depth, Any Language, Any Pattern: Any Engineering Standard Imaginable
• Configuration Guidelines Are Live: Including 2,500+ Best Practices
• Explore the Pandorian Platform