Product
Technical Content Delivery Portal
Authoring platforms end at an export. We start there.
Your content is written where it should be: a CCMS, a CSDB, Word, a publishing pipeline. What most programs lack is what comes after, a controlled place where every publication is current, findable, and scoped to who may see it. That is the Content Portal, built by the same team that converts, authors, and teaches the standards behind it.
The Delivery Layer
Shakewell Content Portal
One authoritative, addressable home for every publication, instead of copies in inboxes.
Most technical content still reaches its readers as a PDF attached to an email or a file on a share drive. From that moment it is a copy: nobody can withdraw it, search inside it across a library, or tell whether anyone opened it.
The portal replaces the copy. It delivers the published output of whatever you author in, including the PDFs you already have, with every version retained and superseded rather than silently replaced, access scoped by organization and role, and an honest record of what gets used. It does not replace your authoring platform; it works with it.
Built on
Search that respects permissions
Results are scoped to what each signed-in user may open, so search never advertises a document someone cannot see.
Runs where your data must live
Hosted, in your own cloud account, or self-hosted down to air-gapped networks, and the same software in each, so moving later is a hosting change, not a migration.
Ready for grounded AI
Structured, page-addressable, permission-scoped content behind an API: the foundation an assistant needs to cite what it says. No bolted-on chatbot, and we say so.
Why Shakewell
Software and the People Behind It
One team, from conversion to delivery
The people who convert and author your content also run the portal it lands on. When something breaks between the two, there is one accountable team, not a software vendor and an implementation partner pointing at each other.
We teach, so you don't depend on us
Engagements can include training and coaching in the standard itself, on your own content. The measure of success is a team that runs its program without us, not a support contract it cannot leave.
Neutral about your authoring platform
We work across the authoring platforms programs already own, including those of the vendors we partner with. Platform selection is part of our strategy work, and we recommend what fits your program, including tools we do not sell.
Plain about what things do
Our product pages say what the portal does not do as plainly as what it does, and our standards references and free tools are open for anyone to check. We would rather you trust the detail than the adjectives.
Weighing us against a platform vendor? Our side-by-side comparison with RWS is sourced to their own material, and says where they are the better fit.
Choosing a System
How to Evaluate a Technical Publications System
We are asked to compare authoring platforms, content management systems, and delivery portals more often than we are asked to sell one. These are the questions that separate the systems that survive contact with a real program from the ones that demo well: whichever vendor you end up with.
Native standard support
Is the standard native, or bolted on?
A system that stores your content as the standard's own data model behaves very differently from one that stores something else and exports to it. Ask which issues and revisions are supported natively (S1000D 4.x versus 5.x versus 6, MIL-STD-40051, iSpec 2200), and what happens on the day the specification revises.
Source management
Where does the source actually live?
S1000D expects a Common Source Database; DITA expects a component content management system. Either way you need check-in and check-out, versioning, branching for concurrent revisions, and a single authoritative copy of every module. A folder of XML files on a share drive is not a CSDB, however well organized.
Applicability and effectivity
How does it handle multiple aircraft from one source?
This is where small teams running mixed fleets get hurt. One procedure that differs across three tail numbers should be one module with applicability expressions, not three near-identical copies that drift apart. Ask to see applicability resolved at publish time against a real configuration, not described on a slide.
Business rules enforcement
When does non-compliant content get caught?
Validation against the governing DTDs, schemas, and business rules should happen while the author is writing, not in a delivery review three weeks before the drop. Ask whether BREX and equivalent rule sets are enforced at authoring time and what the author sees when a rule fails.
OEM and supplier data ingestion
What happens to data you did not author?
Operators rarely control the format their OEMs deliver in. A centralized documentation operation lives or dies on how well it absorbs mixed supplier data (different standards, different issues, different levels of compliance) without hand-rebuilding each drop. Ask what the ingestion path looks like for a supplier who sends you legacy PDF.
Illustration pipeline
How are graphics managed and reused?
Technical illustrations carry their own control numbers, revisions, and hotspot data linked to parts. Ask how illustrations are stored, how ICNs are allocated, whether hotspots survive a revision, and what happens when one graphic is reused across many modules.
Output channels
Can one source produce every deliverable you owe?
Most programs owe more than one format: page-based PDF for the contract deliverable, an IETM for the maintainer, a portal or EFB view for daily use, and something that works with no connectivity in a hangar. All of it should come from the same source without a parallel production process per channel.
Security and export control
Does the deployment model match your obligations?
Distribution statements, export-controlled content, and customer security requirements constrain where content can be hosted and who can see it. Ask about deployment options (cloud, on-premise, air-gapped) and whether access control is granular enough to scope permissions by customer, team, and individual document.
Migration in, and migration out
How do you get your content back?
The migration into a platform is quoted and planned. The migration out usually is not, and it is the question that tells you how much leverage you are giving up. Ask what a full export looks like, in what format, and whether it round-trips into another compliant system.
Working through this list is exactly what our analysis and strategy engagements do: platform selection and build-versus-buy evaluation against the standards your program actually owes. Most of them end with a recommendation for a platform we do not sell.
FAQ
Choosing a Platform
What should a small maintenance team look for in a technical publications system?
Applicability handling first. A small team running several aircraft types gets hurt most by duplicated content that drifts, so the ability to hold one procedure with applicability expressions across tail numbers matters more than feature breadth. After that: native support for the standard you actually owe, validation at authoring time rather than at delivery, and an honest migration path out.
How do authoring platforms differ from content delivery portals?
An authoring platform is where technical content is written, validated, and managed against a standard. A delivery portal is how that content reaches the people who use it (maintainers, customers, dealers) with search, access control, and usage analytics. They solve different problems and many operations need both. The Shakewell Content Portal is a delivery portal; we work with whichever authoring platform a program already runs.
Can one system manage documentation from several different OEMs?
Yes, but the ingestion path is the thing to examine rather than the claim. Suppliers deliver in different standards, different issues, and different levels of compliance. A centralized operation works when there is a repeatable pipeline that normalizes incoming data, including legacy PDF and unstructured content, into your own source of truth, rather than a manual rebuild on every drop.
Does Shakewell only recommend its own products?
No. Platform selection and build-versus-buy evaluation are part of our Analysis & Strategy practice, and most engagements conclude with a recommendation for a platform we do not sell. We build the Content Portal for delivery, and we author natively in S1000D, MIL-STD-40051, MIL-STD-3001, iSpec 2200, and DITA across whatever toolchain a program already owns.
See It in Action
Let's Talk
Walkthroughs and demonstrations of the Content Portal are available on request. Tell us about your content and we will show you what it looks like inside the platform.