Resources
This section used to hold a hundred and forty pages. A hundred and eighteen of them documented one configuration setting each, in an identical seven-heading template, on the marketing site rather than in the documentation. They are gone, and what is left is the material that was actually written to be read: six pieces on the problems that decide whether a governed AI system survives contact with a security review.
The articles
Each one is the long version of an argument a platform page makes in a paragraph, and each links back to the page that owns the subject.
Why it cannot be patched at the model layer, what an indirect payload hidden in a document actually looks like, and why the containment boundary has to sit outside the thing being attacked.
Read on prompt injectionRegular expressions find the personal data that looks like personal data. 'Maria in room 4B' identifies a patient and matches nothing. Where each approach fails, and why the two belong in sequence.
Read on PII detectionMirrored registries, in-cluster inference on open weights, a retrieval stack that never leaves the perimeter, and the hardening that makes the isolation provable rather than asserted.
Read on air-gapped deploymentRelevance bands, freshness decay, document limits and snippet sizing. The upstream decisions that set the ceiling on accuracy, and why tuning them one at a time does not work.
Read on retrieval groundingFour engineering questions that decide whether a clinical project clears review — what reaches the model, what record exists, what the system can see at all, and how any of it is shown.
Read on healthcare reviewsThe hardest question is not what the system did but what it was configured to do on the day in question. Four properties that make that answerable, including the one most systems lack.
Read on audit trailsEach article ends by pointing at the platform or solutions page that owns its subject, rather than at a settings reference. If you want the settings themselves, the documentation portal is the place and it is kept current.
Where the rest went
Each of them exists; none of them belongs here, and saying so is more useful than quietly dropping them.
Every configuration setting, parameter and node is documented at documentation.neuralseek.com, which is maintained against the product and updated on a real cadence. Duplicating a subset of it as marketing pages helped nobody: the copies drifted, and a reader looking for a setting found the stale version first.
There is no cadence here and none is promised. The previous section carried a monthly changelog whose most recent entry was over a year old and closed with an invitation to check back next month. An article with nothing behind it is a liability; six that are still true is a resource.
The old section carried two head-to-head model comparisons, both of which opened by promising original test data and then published none. If the underlying results can be produced they deserve a page of their own with the numbers in it. Until then, comparing models against your own material during evaluation will tell you more than either article did.
None of them is an article, and all three were hard to place anywhere else.
There is a NeuralSeek training programme — official certifications delivered with a training partner, hands-on certificates earned through the labs and the community, and a structured student internship. It is at /resources/training/. It was previously at a URL that read as compliance certification and sat under the Trust pillar, which sent security reviewers to a course catalogue and prospective students to nowhere at all.
Once a month: upcoming events, partner news and the monthly webinar. Subscribe at /resources/newsletter/ — one email a month, and you can unsubscribe from any of them.
Probably a configuration reference — those moved to documentation.neuralseek.com, where they were always supposed to live and where they are maintained. If it was one of the articles, it was cut for a reason recorded in this repository rather than by accident, and the reasons are mostly the same one: it made a claim about a named customer, or published a result it did not show. Ask and you will get the specific answer.
Talk to a NeuralSeek expert about how it fits your stack, where your data has to live, and the governance your auditors already expect.
