If you landed here, you’re probably trying to answer one of a few simple questions: What does PillarShield actually do? Where do I find the thing I need? Why did something get blocked?
This page is a short orientation. It explains what PillarShield is responsible for, how the documentation is organized, and where to go if the docs don’t cover your situation.
What PillarShield does (in plain terms)
PillarShield is a content governance service that runs at the save and publish boundary. When content is submitted, PillarShield evaluates it against your configured rules and returns a decision: Allow, Warn, or Block.
Every decision is recorded in an immutable audit log. That log exists so you can understand what happened, explain it to stakeholders, and retain evidence for compliance, investigations, or internal review.
The goal is simple: catch risk before content reaches production, without disrupting normal authoring workflows.
How the documentation is organized
The documentation menu on the left is task-oriented. Use it based on what you’re trying to do right now:
Installing or integrating PillarShield
If you’re using Drupal, start with Installation. It covers enabling the module, adding your API key, and verifying that PillarShield is connected.
If you’re integrating PillarShield into a custom application, CMS, or pipeline, go to Enterprise Integration.
Understanding decisions and investigations
If content was blocked or warned and you need to know why, see Audit Logs. This explains what information is recorded, how to read a log entry, and how to trace a decision back to a specific rule or request.
Adjusting rules and governance behavior
Configuration and policy tuning lives under Portal Settings. Those documents focus on what each setting does and when you might change it.
API reference
If you already know what you’re building and just need endpoints and payloads, jump straight to the API documentation.
If the docs don’t answer your question
If you can’t find what you need here, reach out through Contact. PillarShield support works best when you include a little context up front:
- What you were trying to do
- What happened instead
- Your CMS or integration type
- The approximate time of the event
- An audit log or request ID, if available
That’s usually enough to get you a clear answer without a long back-and-forth.