Developers
How it reads and writes your source
The parts a developer actually wants to know before authorizing anything: what the parser does, how bindings survive refactors, what a write would look like, and what happens to text in your repository that looks like an instruction.
The read path
A webhook or a manual sync produces a repository snapshot or a changed-file set. Parser adapters run over the supported formats, discover source models, extract content, and match each extracted value to an existing asset by its stable source binding.
Matching by binding rather than by value is what lets an asset keep its identity, its history and its relationships when the words change. Matching by value would create a new asset every time somebody fixed a typo.
A source binding
The record that makes safe write-back possible. Every field is required; a partial binding is not usable for writing.
{
"repository": "northwind-group/northwind-web",
"branch": "main",
"file": "apps/storefront/src/content/features.ts",
"export": "features",
"object": "feature[slug=scan]",
"field": "headline"
}Why the AST and not a regular expression
This is the single most consequential implementation decision in the product.
- Nested objects, arrays and template literals do not survive pattern matching reliably
- A binding resolved through the tree is stable when unrelated code above it changes
- Comments and formatting can be preserved by the serializer, or the write can be refused
- A structure the serializer cannot change deterministically stays read-only rather than being attempted hopefully
The write path
An approved change loads the latest source revision, verifies that the binding still resolves, applies the change through the structured serializer, runs validation, generates a diff, creates a branch, commits and opens a pull request mapped back to the Narraxio change request.
If the source changed after the draft was created, the write stops. The binding is re-resolved, the conflict is shown, and a safe rebase is attempted only where it is deterministic. Overwriting somebody else's change is never the automatic outcome.
Repository content is untrusted data
Narraxio ingests arbitrary source text by design, which makes this a first-order security property rather than a hardening detail.
- Text extracted from a repository is data in a context packet, never system instruction
- Content that reads like "ignore previous instructions" cannot change the AI layer's authority or which tools it may call
- Tool permissions are bound to the task mode and the actor, not to anything the retrieved content says
- Ask holds no write permission at all, so the worst case for a poisoned document is a wrong answer rather than a wrong action
Webhook events
- content.created, content.updated, content.approved, content.published
- fact.changed — the one that lets your systems react to a product truth moving
- health.issue.created
- source.sync.completed, release.published
What Narraxio does not do to your application
- No SDK to install and no runtime dependency in Git-connected mode
- No API call on your rendering path
- No reformatting of files as a side effect of reading them
- No direct pushes to protected or default branches, ever
Keep reading
The rest of the documentation
Give your content a memory. Give your AI the full picture.
Connect a repository read-only and see what has been sitting inside it — every headline, claim and near-duplicate paragraph, with the file and field each one came from.
Keep Git and your existing stack Read-only to start Narraxio runs on Narraxio