One platform.
Your boundaries.

Our default for a marketing site is generated static pages: no database, no plugins and no admin login on the public site, so there is nothing on it to break into and nothing to patch every week. Pages are served over TLS 1.3. Private files are blocked at the edge, and that block is checked by planting a file and requesting it, not by reading the configuration. Analytics are self-hosted and cookie-free, so visitor data is not handed to an ad network. The contact form stores each enquiry before notifying anyone, so a mail outage cannot lose a lead.

React and TypeScript in the browser, PostgreSQL or MySQL underneath, Python or Node services in between. Each application gets its own database or schema, reached through its own restricted login. Where an application runs on Supabase, permissions are enforced by the database with row-level security: a screen cannot show a row the signed-in person may not read, even if the screen's own code is wrong. Our public demonstration apps run with outbound traffic limited to a single named host, so even a compromised demo cannot reach anything else.

The model is Claude, from Anthropic. It writes language and decides which question to ask. It does not do arithmetic and it does not browse your records: figures come from code, through a fixed set of tools the bot may call, each with a fixed shape. In the project manager assistant no tool even has a field for another project manager, so a request for somebody else's jobs has nowhere to go, and a guard refuses any figure in a reply that a tool did not produce that turn. Bots run under spending caps, so a loop cannot run up a bill.

One front door for every workflow. It verifies that an incoming message is genuinely from where it claims to be, rejects duplicates so a retried delivery cannot fire an action twice, and routes what is left to the right bot for the right tenant. It is the layer that makes the other two safe to reason about: nothing reaches a bot that has not been checked and attributed first.

A bot owns one job and holds the rules for it: what it may do on its own, what it must prepare and hand to a person, what counts as an exception, and what it does when a field it needs is missing. Club Coordinator, an existing product, currently paused, holds one set of those rules, for member services; the PM assistant holds another, answering a project manager's questions about their own jobs and nobody else's, and it is the one of the two answering questions today. They share the platform and its plumbing; they do not share your data. Adding a second bot does not widen the first one's access.

Your records live in a Postgres schema of your own, and a connection scoped to your tenant cannot address another one. This is the difference between isolation that is enforced by the database and isolation that depends on every query remembering to say "where tenant_id = …". The first survives a mistake in application code. The second is one forgotten clause away from a leak.

Your records sit in a database schema of your own, and a bot connected for your tenant cannot address another schema. The database answers only on the server itself, never on the internet; the only public ports are web traffic and administrator access. What this option asks of you is trust in CoreShift's administrators, who can reach the server. If that is the part you are not comfortable with, option B exists for exactly that reason.

A bot sends Claude the fields one step needs: this invoice's number, amount and due date, not your ledger. It goes over TLS to Anthropic's commercial API. Anthropic's published terms say retained data is never used to train a model without your express permission; that conversation content is not retained by default, except for a newest tier of models that requires 30-day retention; and that zero data retention can be arranged. The models our bots use today are outside that tier.

Every night the databases are dumped and the credentials are bundled with AES-256 encryption. Two weeks are kept on the server and a copy goes to a private, versioned, encrypted S3 bucket off the server. A snapshot of the whole server is taken daily and copied to a second AWS region. Plainly: the recovery point is up to 24 hours, there is no live standby, so losing the server means a restore measured in hours, and the server's disk is not yet encrypted at rest. The backups are.

Nobody outside your account. The database, the bots and the logs live in your AWS account, on a private network that accepts no connection from the internet. CoreShift has no standing access: we deploy a release through a role you create, which you can time-limit, watch in your own CloudTrail, and revoke in one click. Your financial system is reached with a read-only account wherever the workflow only needs to read.

Nothing leaves your account to reach the model. Claude runs on Amazon Bedrock in your account and region, reached over a private endpoint. AWS states that model providers, Anthropic included, have no access to the accounts where models run, so they never see your prompts or replies. Bedrock offers zero data retention for models that support it; the newest Claude tier instead requires up to 30 days of retention inside AWS for AWS review, not shared with Anthropic. We choose the model with you, knowing which applies.

The database, disks and backups are encrypted with a key you own. Managed backups give point-in-time restore, measured in minutes rather than a day. Backups go to a versioned bucket with a deletion lock, so even an administrator, or a stolen administrator login, cannot erase them before their retention ends. A standby in a second availability zone is an option if downtime matters more than cost.

Pass the draft, or hold it with a list of findings, each pointing at the field or sentence it questions. That is all. It has no tools that write, send or change anything, and it cannot edit the draft into something that passes. A held draft goes to a person with the findings attached; it is never retried silently until it gets through.

That every number, date, name and account in the draft appears in the records it came from; that the action is one your scope allows, for an amount under your threshold, to a recipient on your list; that nothing from another customer or another person's records has crept in; that missing information was reported as missing rather than filled in; and that the tone and wording follow your rules.

A model asked to check its own work tends to agree with itself. The reviewer starts cold, from different instructions, and is set up to look for a reason to refuse. It is not a guarantee: two models can share a blind spot, and it adds time and cost to every step. That is why it sits in front of the human approval and the code checks, never in place of them.