What shipped

• No separate Boundary package. Boundary traffic counts toward the same workspace plan allowances as every other deployment and workflow. We price on the AI systems you register — not seats, not tokens.
• Where your limits are. GET /entitlements returns your plan's limits and current usage; the dashboard's Usage page shows where you stand.
• Removed from the page. The Starter and Team numbers and a note on an operator setting that no longer changes any limit.

• Billing country. Choose it before paying. Prices are list prices in each currency and never converted: EU and EEA countries pay in euros, and other countries see the currency they'll be billed in before they pay.
• Business details. Stripe's checkout page now asks for your business name and billing address, and lets you add a tax ID (for example an EU VAT number). They appear on your invoices.
• Terms of use. If you haven't accepted the current Terms of use, the checkout page asks you to, and records it with your purchase.
• No codes or discounts. Online purchases are at list price.

• What happened: an ID such as 8c430a3d-680a-46cf-8451-779151472826, whose last groups happen to be all digits, reached the tool as 8c430a3d-680a-46cf-[REDACTED:credit_card].
• Now: IDs in that format are left alone wherever they appear in the arguments.
• Still redacted: card numbers in any layout, phone numbers and email addresses, including next to an ID. Credentials such as Bearer tokens still block the call.

• Optional fields: a contract field that isn't required can go unused without raising the badge.
• No traffic yet: a new deployment shows no drift until requests arrive.
• Real drift: a missing required field or an unknown field still shows the badge. Contract enforcement is unchanged.

• One command. ./install.sh --license ./license.json --version <version> from the release's selfhost folder. Add --domain for HTTPS with an automatic certificate, --no-internet for installs without internet access, or --tls-internal for HTTPS on an IP address.
• Secrets stay put. It fills only values that are missing, empty or change-me, keeps a copy of .env before any edit, and never changes an encryption key, JWT secret or database password that is already set. Secrets and licence links are never printed or logged.
• Signed images. Each image's signature is checked with cosign before anything starts; a signature that doesn't verify stops the install.
• Upgrades and renewals. --upgrade --version <new> backs up the database first; --license new-license.json renews a running install.
• HTTPS that switches on. Setting a domain in NORCASTER_SITE now turns on HTTPS as documented: the Caddy container never received the setting before, so it kept serving plain HTTP.
• Boot checks without an account. qa/boot-qa.sh --no-signup checks the install, including whether the licence lets inference through, without creating any account.

• Replies: shown as a bubble sized to the text, with one line under it: "Allowed by policies", time, tokens, Run details and View trace.
• Message box: starts at one line and grows as you type. Enter sends; you can type the next message while a reply is on its way.
• Header: says whether the deployment remembers the conversation. New conversation appears once there are messages.
• Getting started: an empty test box offers a first message and, when the personal-data policy is on, a message that should be blocked.

• While waiting: "Passed the policies. Queued for the model…", then "The model is running…".
• Still running after two minutes: a neutral card, "Allowed by policies · reply pending", with View trace. The reply and the policy check on it appear in the trace.
• Blocked after queueing: a reply stopped by the deployment's output checks now shows as "Blocked by policy" with the reason, not as a failed request.

• Deploy page. When you reach your plan's deployment limit, the notice shows the limit you hit (for example "Deployment limit reached (1/1)") instead of a fixed sentence about the free plan, and the button says "Upgrade to Growth".
• Test console. The monthly request-limit notice's button says "Upgrade to Growth"; its link goes to pricing.
• Boundary runs. When a run stops at a plan limit, "Review plans & limits" opens pricing and "Talk to us for higher limits" opens the contact page.

• What's in it:

- the sources connected and the inventory uploads used;

- each system with its source, when it was first and last seen, its state and the state's own evidenced or attested tag, and its linked deployment;

- the Art. 26 register entries of linked deployments;

- the obligations the applied packs' records speak to for your frameworks in scope, each tagged evidenced, attested, or both;

- the coverage statement for the last 24 hours;

- what Discovery doesn't see.

• Honest about scope. It prints "Discovery lists the systems its named sources report. A system none of them sees is not on the list." Classifications print as drafts declared by a named person, for your counsel to confirm. Mappings are Norcaster's own.
• A working document. The signed, verifiable record is still the audit bundle. Each file's SHA-256 is shown next to it in the portal, never inside the file. Sample and demo deployments are left out.
• Access: people who can export the register and view obligations. It is on every plan, including the trial.
• API: POST /orgs/{org_id}/ai-register/exports accepts kind: "discovery_report". Exports now report kind and content_sha256, and the export list takes ?kind=; it defaults to register exports, so existing clients are unchanged.

• Eight steps: set up the starter; connect a provider; send a governed request; watch decisions in monitor mode; block what the pack finds; export an audit bundle; invite a reviewer; and the reviewer has the bundle.
• Read from your records. Each step's state is worked out from your deployments, runs, decisions, bundles, share links and invitations every time the checklist is read. Nothing is ticked off by hand. Sample deployments don't count towards the request or bundle steps.
• Dates and people. The monitor step shows the date blocking starts. Once blocking is on, the checklist says whether the monitor period ended, a stricter organisation or project policy applies, or a named person switched it.
• Reviewer steps. A reviewer has the bundle once a share link for it is downloaded or a reviewer account exports it. Your reviewer can check the bundle offline with verify_audit_bundle.py; Norcaster doesn't see that check, so the checklist never says the bundle was verified.
• Dismissing. Owners and admins can dismiss the dashboard card for the organisation. The dismissal is recorded in the audit log, and the checklist stays on the onboarding page.
• API. GET /orgs/{org_id}/onboarding/starter adds checklist, checklist_dismissed and can_dismiss_checklist. New: POST /orgs/{org_id}/onboarding/starter/checklist/dismiss (scope governance:write).

• Insurance, EU: the EU insurance profile, and the "AI supplier to an EU insurer" supplier preset. Tick "The app assesses risk or sets prices for individuals' life or health insurance" to add the AI Act life and health pricing set.
• Insurance, US: the US insurance profile (NAIC AI Model Bulletin, NYDFS Circular Letter No. 7, Colorado).
• Insurance packs: the GDPR Pack is applied and starts in monitor mode; the Healthcare Pack is suggested alongside it.
• HR and workforce: the EU employment profile and the "AI supplier to employers" preset in the EU; New York City, California, Illinois and Colorado profiles in the US.
• Register drafts: a life or health pricing system gets an "Other high-risk" draft with the Annex III, point 5(c) note; an HR system gets "Employment". Both are drafts for your counsel to confirm.
• What isn't stored: Norcaster doesn't compute or store fairness or bias metrics, and the summary says so for both sectors.

• Choosing High-Risk Decision Evidence for insurance with the option "The app assesses risk or sets prices for individuals' life or health insurance" drafts the AI register entry under the register's own category for Annex III point 5(c).
• The category is still a draft for your counsel to confirm.

• What sets the price. We price on the AI systems you register — not seats, not tokens. Then hosting mode (self-hosting is a Strategic deployment mode; a hybrid data plane is agreed per deal), SLA and support tier, identity needs (SAML single sign-on and SCIM on Enterprise and Strategic) and approval gates on agent actions (Enterprise and Strategic).
• Volume. Each package includes request, deployment and retention allowances sized for its systems; we price on the systems, not the volume.
• Boundary. Boundary is part of the same plans: its traffic counts toward the same workspace allowances as every other deployment and workflow. The page no longer names the retired Starter and Team plans.

• New category. "Life and health insurance risk assessment and pricing (Annex III 5(c))" is in the category picker on the register entry and in the completion wizard. Like the other Annex III categories, it sets the risk tier to high risk unless you record an override reason.
• Exports carry the value Insurance_Pricing, as they carry every other category's value.
• API. annex_iii_category on PATCH /deployments/{id} accepts Insurance_Pricing. Unknown values are still refused.
• Whether a system falls under point 5(c) is your counsel's call.

• One sample per sector. Banking and payments: Northgate Bank (sample), a credit assistant. Insurance: Harbourline Mutual (sample), life cover pricing. Healthcare: a sample clinic's patient-message summariser. HR and workforce: Acme Hire (sample), CV screening. Each has its sector's pack, a register entry whose Annex III category is a draft for your counsel to confirm, and sample decisions that were allowed, redacted and blocked.
• Agent Action Control samples also show three tool calls, each decided by the action policy engine: one allowed, one blocked by a rule, and an unknown tool blocked by default.
• Labelled everywhere. The sample's deployment page and register entry say "Sample data — fictional company". The deployments list marks it "Sample", and decision views mark its rows as sample.
• Kept apart from your evidence. Samples don't count toward your plan's deployments and are left out of audit bundles and register exports. Their decisions are never added to your organisation's signed trace chain. One sample at a time: loading another sector's sample replaces it, and "Remove sample data" removes it.
• API. New: POST /onboarding/sector-sample (sector, optional starter; scopes governance:write and deployments:write).

• Self-hosted deployments: the message is sent without streaming, queued like any other /run request, and the reply appears when the run completes. Policies apply exactly as before.
• Provider chat models: unchanged; replies still stream in as text.

• Four starting points: Governed AI Coding, Agent Action Control, High-Risk Decision Evidence and Supplier AI Evidence Pack.
• Sector and region: banking and payments, insurance, healthcare, HR and workforce, or other; the EU, the US or elsewhere. Insurance and HR say plainly which parts are still being added.
• Before you set it up: the summary shows the protection pack, the date it starts blocking (packs that support a monitor period start by recording what they would block), the framework views, regional profiles and supplier sets. A classification you choose is a draft for your counsel to confirm.
• What happens: your framework views are saved, a starter deployment is created and the pack is applied, through the same checks as doing each step yourself. If your plan doesn't include a pack, you see that instead of an error.
• Your own environment: choose it to get the self-hosted setup guide and a link that carries your choice to your install.
• The role-based paths are still there under "Choose by role instead".

• EU insurance: DORA, EIOPA's Opinion on AI governance and risk management, the AI Act's life and health pricing category (from 2 December 2027), Solvency II and the Insurance Distribution Directive.
• EU employment: the AI Act's employment category (from 2 December 2027), the ban on inferring emotions at the workplace (since 2 February 2025), and GDPR on automated decisions and employment.
• US insurance: the NAIC Model Bulletin on insurers' use of AI, NYDFS Insurance Circular Letter No. 7 and Colorado's governance regulation for external consumer data and algorithms.
• New status "Supervisory guidance" for opinions, bulletins and circular letters that explain how a supervisor reads existing law rather than adding rules.
• New York City and Illinois: the employment profiles' instruments are now checked against their primary sources, with corrected notes.
• Fairness and bias testing stay outside the stored evidence, and each profile says so. Applicability is always your counsel's call.

• EIOPA Opinion on AI governance and risk management (EIOPA-BoS-25-360, 6 August 2025): one row per heading of Section 3, for an insurer's AI that is neither prohibited nor high-risk under the AI Act. The Opinion is addressed to national supervisors and sets out no new requirements. Fairness metrics and redress are outside the pack.
• EU AI Act, life and health insurance pricing (Annex III, point 5(c)): the high-risk duties that apply from 2 December 2027, including informing the people a decision concerns, the right to an explanation, and the fundamental rights impact assessment.
• EU AI Act, employment and workers' management (Annex III, point 4): the same duties for recruitment, work decisions, task allocation and monitoring, plus informing workers and their representatives, and the workplace emotion-recognition ban in force since 2 February 2025.
• Presets in the bundle dialog are now grouped: EU financial services, EU insurance (with an option for life and health pricing) and Employment and HR.
• Every mapping is Norcaster's own; the publishers have not reviewed it.

• SR 26-2 / OCC Bulletin 2026-13 replaces SR 11-7 / OCC Bulletin 2011-12 in the US financial services profile, shown as supervisory guidance from 17 April 2026 and checked against the Federal Reserve's and OCC's own pages.
• The note says what changed: SR 26-2 supersedes SR 11-7 and SR 21-8, sets out no enforceable standards, and places generative and agentic AI models outside its scope. For agents, its model risk concepts are a principles-based reference, not a compliance claim.
• The duties and the evidence they point to are unchanged. Applicability is always your counsel's call.

• When it starts: when you verify your email, or when you sign up with Google, GitHub or Microsoft. Each account has one trial; teammates you invite during it share it, ending on the same date.
• In the dashboard: a banner shows the days left and the end date, with Buy Growth and Export evidence. In the last 7 days it turns amber.
• Emails: a reminder 7 days and 1 day before the end, and a note when it has ended.
• After the trial: your workspace moves to Builder. Records from the trial keep Growth's 180-day retention, counted from the trial's end, and their trace-chain proofs and verification keep working. A signed export of the trial period stays available while they are kept.

• Gateway setup creates a key bound to the deployment you picked, and its example request leaves out X-Norcaster-Deployment-Id. The version with the header is still shown, for keys used with several deployments.
• Connect panel: members get "Create my key for this deployment", a personal key bound to it. Owners and admins still create a service-account key for an app.
• Onboarding's "Connect your application" step now creates a key for your deployment and shows code without the header.
• Settings → API keys shows which deployments each key is bound to.
• The gateway and coding-assistant docs lead with the minimal setup: the base URL and the key. The header is needed only for keys used with several deployments, unbound keys and portal sessions.

• What counts: each deployment in the AI register that isn't a demo and whose lifecycle stage is production or not set. Development, staging, deprecated and retired deployments don't count.
• Plan panel: "AI systems: 3 of 5" links to the AI register, filtered to the systems that count. From 80% of what your plan includes, a notice says so; nothing is blocked.
• AI register: each deployment shows Counts toward your plan or why it doesn't. To stop counting a system, mark it as development, staging, deprecated or retired in its register entry.
• Email: owners and admins get one email when the count reaches 80% of what the plan includes, and one when it reaches all of it, at most once each a month. Not on Builder.

• Builder tokens: 500,000 a month. Only /run and Slack count toward it; gateway traffic doesn't.
• Evidence after a plan change: proofs, verification, the chain head, keys and anchors stay available for records made under your earlier plan while they are kept. Anchoring finishes what was recorded before the change. New records are only added to the chain on plans that include it, and the integrity view shows the chain as paused until then.
• The trace-chain upgrade message now says the chain is included from Growth up.

• Share link on a ready PDF or CSV bundle: choose 1, 3, 7 or 14 days, copy the link once, revoke it whenever you like. Each download is recorded in your access log.
• The recipient opens the link, sees the bundle's organization, scope, period and content digest, downloads it, and runs python verify_audit_bundle.py bundle.json --offline in the unzipped folder.
• The token stays private: it sits after the # in the link, which browsers never send to a server, so it doesn't appear in logs or in chat link previews.
• A link stops working when it expires, is revoked or used up, when its bundle expires, when the person who made it leaves or loses access, or when an owner or admin switches share links off in Settings → Governance.

• POST /auth/api-keys takes allowed_deployment_ids: up to 20 deployments you can run. Binding only narrows a key: it can't reach other deployments, and a header naming another deployment is refused.
• One deployment, no header: chat completions, messages, responses and embeddings resolve the deployment from the key, and each run records deployment_id_source: api_key_binding. A key bound to several deployments still needs the header.
• GET /auth/me now shows the key a request used (api_key: scopes, binding, service account), so tools can tell whether to send the header. It is null for portal sessions.
• Existing keys are unchanged. Key lists and new keys show their binding; rotating a key keeps it.

• Pinned commands: "Run in your network" gives uvx norcaster-discover==0.2.0 connect … && uvx norcaster-discover==0.2.0 sync --repo ., the CI hint names norcaster/discover@v0.2.0, and "Scan without pushing" uses the same version.
• Navigation: the Discovery entry shows to people who can list its systems (owners, admins, governance, leaders and external reviewers).
• Settings: the provider usage reconciliation switch changes only on the Discovery page (PUT /orgs/{org_id}/estate-discovery/settings), which checks the value and records who changed it. PATCH /orgs/{org_id} now refuses a change to org_settings.coverage; sending the stored value back unchanged still works.
• Self-hosted installs can choose which Discovery sources new connections may use, and can turn off the copied uvx command where PyPI isn't reachable (DISCOVERY_SOURCE_KINDS_ENABLED, NORCASTER_DISCOVER_PUBLISHED_VERSION).

• Free and seatless: reviewers are left out of the seat count, the seat limit and seat billing. Builder includes 3 reviewers; Growth and the other paid plans 10; Enterprise and Strategic have no limit.
• Scoped and time-boxed, as before: one deployment, one project or the whole organization, ending within a year (30 days by default). Reviewers still can't deploy, change policies, or see API keys, provider secrets or billing.
• Invite from audit bundles: "Invite a reviewer" opens the invitation for the whole organization, ending in 30 days. A risk or compliance colleague can be a reviewer as well as an auditor.
• The role is now called Reviewer (it was External Reviewer). Invite rosters still accept the old name.
• Fixed: accepting an invitation could be refused as "seat limit reached" when the organization's seats were taken by pending invitations, because the invitation being accepted was counted twice.

• Versioned legal pages: the Terms of use, the Privacy notice and the standard DPA show "Version … · effective …", with every version at /legal/<document>/versions. Each version carries the SHA-256 of its text.
• Sign-up: a checkbox to agree to the Terms of use in the version shown and confirm you have read the Privacy notice. If you sign up with Google, GitHub or Microsoft, you accept on one screen before the dashboard opens.
• Agreements: under your account menu, see what you accepted, which version, when, and a certificate with the document's fingerprint.
• Drafts are marked: the DPA template, the DORA ICT services addendum and other documents still in legal review show a draft banner and can't be accepted online yet.
• Existing accounts are not interrupted.

• The setup token: set SELFHOST_SETUP_TOKEN in .env (openssl rand -hex 24). The sign-up page asks for it for the first account only.
• Who can sign up (SELFHOST_SIGNUP_MODE):

- first_owner, the default: nobody once the first account exists;

- allowed_domains: addresses at your domains, with email verification on;

- open: anyone who reaches the URL, as before.

• Upgrading: an existing install moves to first_owner. Your accounts keep working; new teammates need an invitation, or set SELFHOST_SIGNUP_MODE=open to keep the old behaviour.
• Not affected: invitations, SSO just-in-time provisioning, SCIM, and existing users signing in with Google, GitHub or Microsoft.
• Audit: refused sign-ups are recorded as auth.signup.refused, and the first account as auth.install.first_owner_created. The token itself is never logged, returned or stored.

• Checkout: "Choose Growth" while signed out takes you through sign-up to a checkout page that names the plan, its price and the organization it's for, then on to Stripe.
• Who can buy: the organization's billing owner, its first owner. Other owners and members are told so instead of being charged for a plan that wouldn't apply to the organization.
• Plan & usage: the overview panel shows when your subscription renews or ends, whether the last invoice was paid, and a notice while a payment is being retried.
• Retention after a downgrade: if a plan ends or is downgraded, runs and enforcement events recorded under it are still kept for that plan's full retention period. Your organization's own retention settings still take precedence.

• What you'll notice: Certifications in the Trust Center menu, with a progress bar per standard and ten steps from scope to the Stage 2 audit, each marked Planned, Next, In progress or Done for ISO 27001 and ISO 42001.
• Posture: the ISO 27001 and ISO 42001 cards on /trust, the /security checklist and the posture list on the homepage now say In progress, with a link to follow progress.
• A step is marked Done only with a note saying what exists and where a reviewer can see it. A certificate is linked on the page once one is issued.

• What you'll notice: a SOC 2 Type II section on /trust/certifications with a progress bar and nine steps, each marked Planned, Next, In progress or Done. A SOC 2 report is an attestation by an independent CPA firm, so the section links to the report request under NDA rather than to a certificate.
• Posture: the SOC 2 Type II card on /trust and the /security checklist link to the section. The status still reads "Window opens Nov 2026".
• A step is marked Done only with a note saying what exists and where.

• What you see: Dashboard → Integrity shows your active signing key, the sequence it started at and a Signed / Unsigned status for each range. Verification results, proof bundles, audit bundles and signed exports now include the signature checks, and the offline verifier checks them without a Norcaster account.
• What does not change: entries before the switch keep their hash chain and their anchors; they are reported as unsigned, never as invalid.
• Keys rotate monthly: each signing key lasts 30 days and is replaced automatically before it ends; owners can also rotate it on the Integrity page. Each rotation is an entry on your chain.
• Rekor: each anchored segment now carries your chain's public key. No organization name or ID is published, but segments signed with the same key can be linked to each other.
• Your own root: on Integrity → Custody root, an owner can make one of your data planes the root. It approves each new signing key over the data plane's normal sync, and the key never leaves your network.
• This applies to plans that include the trace chain (Growth, Enterprise, Design Partner and Strategic).

• Hidden: values under secret names (api_key, token, password, secret, credentials, private_key and their variants) on both sides of the diff, for pending and decided changes.
• Still visible: that a secret changes. An unchanged secret has no row in the diff; a changed one reads [REDACTED] → [REDACTED: changed]; an added or removed one shows against —.
• Approval unchanged: approving still binds to the hash of the stored proposal and applies the stored config, so the secrets the proposal sets are the ones applied.

• Kept on save: where a saved config sends "[REDACTED]" back for a secret, the value already stored is kept. To change it, send the new value; to remove it, leave the key out.
• Refused: a config holding "[REDACTED]" for a secret with no stored value (for example when creating a deployment) now answers 400 and names the key.
• Shown as stored: tool names under action_policies.tool_outcomes, parameter_constraints and risk_overrides, guardrail rule names under guardrails, and schema field names under properties. Values under those names that are secrets stay hidden.
• If you saved an affected deployment before: a secret or tool outcome replaced by "[REDACTED]" stays that way until you set it again. A tool outcome can be read from the deployment's earlier revisions; a secret has to be entered again.

• Before: a rollback proposal kept today's webhook tokens and other secret values, not the revision's, and kept settings added after that revision, such as newer action policies.
• Now: the proposal is the revision's stored config, unchanged. Approval works as before: the same reviewer rules, and the approval still names the config hash you reviewed.
• API: POST /deployments/{deployment_id}/proposals also accepts {"revision_number": N} in place of proposed_config; the response adds rollback_revision. Requests that send a full config are unchanged.
• A rollback proposal changes the config only. The served model and artifact stay as they are, as with any config proposal.

• What to do: generate a key once with openssl rand -base64 32 | tr '+/' '-_', add it to .env as CREDENTIALS_ENCRYPTION_KEY, and run docker compose up -d. ./qa/boot-qa.sh now fails until it is set.
• Keep it safe: back it up with your database backups. Losing or changing it makes every stored credential unreadable. Setting it for the first time on an existing install does not affect authenticator apps that are already set up.
• Without internet access: signup and password changes check the password against Have I Been Pwned and refuse it when that check can't run. Set HIBP_CHECK_ENABLED=false in .env on installs without internet access. Both settings now reach the API; the defaults are unchanged.
• Unchanged: without the key, the API still starts.

• What changed: each authenticator secret is encrypted with its own random value and checked for tampering. Existing secrets are converted when the server starts.
• What you need to do: nothing. Your authenticator app and recovery codes keep working.
• Self-hosted installs: after this update, don't go back to an older version. It can't read the converted secrets, so users would need their recovery codes. Restore the backup you took before the update instead.

• Signing in: your authenticator's codes can't be checked when the key that protects them has changed. A recovery code now signs you in instead of an error.
• Setting it up again: on the MFA page, enter a recovery code to turn two-factor authentication off, then set up your authenticator again. This works only while your authenticator can't be checked. Otherwise turning it off still needs a code from your authenticator.
• Self-hosted installs: setting CREDENTIALS_ENCRYPTION_KEY for the first time no longer affects authenticators that are already set up. The next time someone signs in with an authenticator code, their secret is stored under the new key.

• Before: after a renewal, your agents' Shared Record calls were blocked until someone noticed and an owner or admin requested a new key document by hand.
• Now: the version appears under Your identity as waiting for approval, and each owner gets an email linking to it. Approving it works as before: a key in your own KMS signs it at once; a Sync Agent root signs it on its next poll. Calls are allowed again once it is registered.
• What is left to you: an owner still approves every version. If an owner denies the one opened for a key, Norcaster does not open it again; request one yourself when you are ready. Agents that are no longer active are left out of the new version.
• Norcaster's platform audit log records the request as made by the system, not by a person.
• Shared Record is in development · pilot pairs by application. A pilot version is built and in testing. It is not in production or available to customers; this applies where Shared Record is turned on for a pilot.

• Datasets tab: lists the workspace's datasets only.
• Evals overview: the Datasets count is the workspace's.
• New suite form: its dataset picker already followed the organization chosen in the form; unchanged.

• Traces & runs: the list, the "last 24 hours" counts and the deployment filter show the workspace's runs: runs of that organization on its project deployments, plus its runs without a deployment.
• Evals: the runs list, the suites and the compare-runs picker show the workspace's eval runs and suites.
• Signals: the trace and eval counts in the AI register and Evidence, and the total on Latency & cost, count the workspace's runs.
• API: GET /observability/runs?org_id= lists runs of that organization whose deployment, if any, is in one of its projects. Runs of a personal deployment, which the gateway files under its owner's first organization, are no longer included. A malformed org_id returns 422.

• Overview: the fleet panel and the "N ready" line at the top count the selected workspace's deployments.
• Pickers: choosing a deployment for a policy, a test, an eval suite, an incident or an audit bundle offers only the workspace's deployments. A new eval suite follows the organization chosen in its form.
• Unchanged on purpose: plan limits still count every deployment you own. Workflow pickers still offer members' personal deployments, which workflows may use. Traces and eval run lists still show all your runs.

• Behaviour change: a capped tool called without its amount, or with one that isn't a non-negative number, is now blocked (action_amount_missing_or_invalid). Before, it ran.
• Escalate instead of block: set over_amount_outcome or missing_amount_outcome to "escalate" under parameter_constraints.<tool>. An escalation only pauses a call the policy would otherwise run. It never replaces a block, and a cap set at the organization or project level without these keys still blocks for every deployment under it.
• Reviewers: a paused create_refund shows its amount (converted from minor units), the masked payment intent, and "Full remaining amount of the charge" when no amount was given.
• Setting the keys: the portal form does not edit parameter_constraints. Use the API call in the docs, "Amount caps that pause a call".

• Why this decision was made: one sentence per reason, with its code underneath, followed by any violations as before. Examples: "The amount is over the cap, or missing, so a person must approve." and "A high-risk tool with no rule allowing it is stopped by default: blocked, or held for approval." A code the portal does not know yet is shown as it is.
• Policy match: shows the decision's error code, such as action_tool_denied or action_amount_requires_approval, alongside any violation codes.
• Audit bundle: each action row now has reasons and error_code.
• Trace chain: a new tool call's chain entry includes its reasons and error code, so the explanation is tamper-evident. Existing entries are unchanged and still verify.
• Earlier tool calls have no reasons stored. They show the same text as before, and the API returns null for both fields.
• Only codes are stored, never argument values. Database migration 077 adds two nullable columns.

• Risk: the same chips as the approval queue: level, irreversible, moves money, writes data.
• Arguments: "3 arguments: amount, currency, customer_id", with a small table giving each argument's type and size (characters, items or keys). Arguments whose names look like secrets or personal data are marked sensitive. A call with no arguments says "No arguments".
• Result: "object with keys id, status, amount", "list of 4 items" or "text, 120 characters". A blocked call, or one waiting for approval, says "Not executed".
• Added latency: shown when it was recorded.
• What is stored has not changed: names, types and sizes, never the values. No hashes of arguments or results are stored.

• Switching workspace reloads the list and the "ready" summary for the new workspace.
• Personal deployments (created without a project, such as the demo environment) belong to no workspace and are no longer listed. Open them by link, or move them into a project to see them in its workspace.
• API: GET /usage/fleet-overview accepts an optional org_id, as GET /deployments already did. It only narrows what you can already see; without it, nothing changes.

• Deployments list: the row title is the deployment name. The purpose moved to the grey line under it, and search still matches it.
• Deployment page: the header and breadcrumb show the name. The purpose is still shown and edited under Details.
• Everywhere else: eval suites, comparisons, runs and external tests, Playground, Traces, AI register, Incidents, Evidence, Access, Reviewers, Workflows and the audit-bundle dialog list deployments by name.

• Message box: type a message and press Enter. Replies stream in as text, with "Allowed by policies" and a trace link under each. The decision path, timings and budget are under Details.
• Conversations: provider-backed deployments, and any whose contract requires messages (Agent Runtime, Developer tools), receive the whole conversation, so a follow-up like "Yes, go ahead" reaches the agent with its context. Self-hosted deployments and prompt-only contracts (Finance, Healthcare, GDPR packs) receive each message on its own. New conversation starts over.
• Contracts from the project or organization: if the contract wants the other request shape, the box resends the message once in that shape. Blocks for personal data or other policies are never retried.
• Blocked messages: show the reason and a suggested rephrasing, e.g. "Payment-card or financial account data was detected in the message."
• Raw JSON: still available under Advanced, sent exactly as typed, for testing a contract.
• Not yet: tool calls. The test box calls /run, which does not forward tools; agents' tool calls go through the gateway.

• What to do: if your page loads https://cdn.norcaster.com/chat/v1.js, change the src to https://www.norcaster.com/chat/v1.js. Keep the other attributes (data-deployment, data-api-key and the rest) as they are.
• What doesn't change: messages still go to the API in data-api-url (default https://api.norcaster.com). Only the script's address moves.
• npm packages: @norcaster/chat-react, -vue and -svelte don't load this script and aren't affected.

• What you'll notice: the assistant button no longer appears in the bottom-right corner of the dashboard. It had not loaded since late August.
• Why it matters: a script loaded into the dashboard runs with your signed-in session. The address it came from could have been claimed by anyone, so it is gone, and nothing outside Norcaster runs in the dashboard any more.
• Framing: the portal sends X-Frame-Options: DENY and frame-ancestors 'none', so another site can't overlay it to trick you into clicking. If you showed portal pages inside an iframe, open them in their own tab instead.
• Self-hosted: the same headers come with the portal image from the next release.

• Which deployments count: deployments in one of your organization's projects, and personal deployments of its current members, such as the ones the New deployment button creates. A deployment of a member whose access has expired no longer counts.
• When you save: creating a workflow, saving a new version or activating one returns 400 when a step's deployment_id is not one of your organization's. The message names the step, and is the same whatever the id is.
• When you run: POST /workflows/{id}/execute returns 400, and starts nothing, when its deployment_id or a step's is not one of the organization in org_id. A step that reaches such a deployment in a run that started earlier fails as not found and is not retried.
• Catalog workflows run from your organization use your deployments: leave their steps' deployment empty and choose one when you run.
• **parent_run_id:** execute returns 400 when the request sets it. Every execution records its own run and returns its id as parent_run_id, as before. No Norcaster client sent the field.

• What is checked: every deployment the run can reach: the deployment_id you run with, and each step's deployment_id.
• The answer: 403 with {"detail": {"code": "credential_not_bound_to_deployment", ...}}, the same as POST /run and the gateway. Nothing is started. A deployment of another organization still gets the 400 it got before.
• Approve and unblock check the key that acts, because the run continues under it. Reject and cancel are not limited.
• Eval suites: POST /eval-suites/{id}/run checks a workflow target's steps and a deployment target. Scheduled eval runs are not limited.
• A step that reaches a deployment outside the key's binding in a run that started another way fails with "cannot be used with this API key" and is not retried.
• Not limited: portal sessions and keys with no deployment binding work as before, and saving a workflow does not check the binding.

• Who was affected: self-hosted portals served from anywhere but localhost. On Norcaster Cloud the line was right and is unchanged.
• What was sent: each Claude Code hook event, tool inputs and outputs included, went to api.norcaster.com. The request was refused for the unknown key and nothing was stored.
• If you set up the hook before this release: check NORCASTER_API_URL in your shell profile. If it says https://api.norcaster.com, replace it with the line the page shows now.

• Verify an image (cosign 2.6 or later):

cosign verify ghcr.io/norcaster/api:<version> --certificate-oidc-issuer https://token.actions.githubusercontent.com --certificate-identity-regexp '^https://github\.com/norcaster/norcaster/\.github/workflows/release-selfhost\.yml@refs/tags/v'

• Verify the SBOM attestation: the same command with cosign verify-attestation --type cyclonedx.
• No key to trust: the signature is made keyless under the release workflow's identity and recorded in the public Rekor transparency log. Norcaster holds no signing key that could leak or need rotating.
• Unchanged: the CycloneDX SBOMs attached to each release, BuildKit's SPDX SBOM and SLSA provenance in each image index, and the signed update manifest that names every image by digest.

• Signed in when you accept: you join, then set up your authenticator app straight away.
• No change for invitations into organizations that don't require MFA, or for members, viewers and reviewers.

• If your organization used Basic OIDC sign-in: set up OIDC or SAML under SSO & SCIM. Settings → Security shows a notice while the old settings are stored; remove them there once the new provider works.
• Its "Enforce SSO" checkbox only blocked a password sign-in that named your organization on the login form; leaving that field empty still signed members in with their password. It no longer applies at all. To make SSO the only way in for members, turn on Require SSO under SSO & SCIM.
• Chat sign-in: add the chat app's callback URL (https://<chat host>/api/oauth/callback) to your OIDC provider's allowed redirect URIs. SAML-only organizations sign in through the portal.
• API: GET /auth/sso/authorize-url and POST /auth/sso/exchange answer 410 Gone. PATCH /orgs/{id} refuses new org_settings.sso values; "sso": null removes old ones.
• Self-hosted: set up OIDC or SAML under SSO & SCIM before upgrading if you used Basic OIDC sign-in.

• If it wasn't you: the email says what to do. Reset your password, which also signs out every session, and contact your organization's owner and support@norcaster.com.
• Setup at sign-in: the email is also sent when an owner or administrator sets up an authenticator during sign-in because their organization requires two-factor authentication.
• Self-hosted: sending needs Sweego or SMTP configured. Without it, no email is sent, and the change is still recorded in the audit log.

• Settings page: nothing changes. Setup was already hidden while two-factor authentication is on; the API now enforces the same rule.
• Through the API: POST /mfa/setup and POST /mfa/verify-setup answer 409 while two-factor authentication is on. Each refused attempt is recorded in the audit log, with the IP address and how the caller signed in.
• Setup at sign-in: unchanged. When your organization requires two-factor authentication, setup during sign-in still only adds an authenticator to an account that has none.

• Who isn't ready: a line under the option counts the owners and administrators without an authenticator app, with a link to Access, where the MFA column shows who they are. Invitations and access that has ended aren't counted.
• What saving does: they set up their authenticator app at their next sign-in, and sessions they already have open can't reach the organization until they do.
• If you don't have one: you're told first, with a link to set yours up, because your own session loses access to the organization as soon as you save.
• No change to the setting itself: you can still turn it on while some owners and administrators don't have an authenticator app.

• New owners and administrators: if you accept an invitation and create your account, or sign in with your password, Google, GitHub, Microsoft, your organization's SSO or the email link, you set up your authenticator app straight away. Then you save your recovery codes, and you're in.
• One attempt: a wrong code means signing in again and scanning a new QR code. The setup link lasts ten minutes.
• No change for members, viewers and reviewers, for accounts that already use an authenticator app, or for organizations that don't require two-factor authentication.

• Existing accounts: sign in another way (your password, Google, GitHub or your organization's SSO), open Settings → Security, and choose Link Microsoft under Your Microsoft account. Until you do, Continue with Microsoft tells you to link first.
• No password yet? If you only ever signed in with Microsoft, use Forgot password? on the login page to set one, then link. Accounts your organization's identity provider manages sign in through it instead.
• New accounts: Continue with Microsoft creates one only when Microsoft confirms the email belongs to you: a personal Microsoft account, or a work account whose organization verified its email domain. Otherwise, sign up with your email and link Microsoft afterwards.
• Unlink at any time from the same place. Linking needs you signed in to the portal; an API key can't add a way to sign in.
• Self-hosted: set MICROSOFT_OAUTH_TENANT to your tenant id to admit only your organization's accounts. For work accounts, add the optional ID-token claim xms_edov to your app registration.
• Chat: Continue with Microsoft in the chat app follows the same rules.

• Removal sticks: before, the next SSO sign-in quietly re-added a removed member with your identity provider's default role. Now it's refused, and the refusal is recorded in the audit log.
• Invitations bring people back: a pending invitation lets the person in at their next SSO sign-in, with the role, scope and end date you chose, recorded as added by whoever invited them. For someone joining for the first time through SSO, a pending invitation now sets their role too.
• SCIM: a SCIM sync no longer re-adds a removed member, and shows them as inactive until you invite them again.
• Ended access: a member whose access has ended (for example, deprovisioned by SCIM) can no longer sign in through SSO, and is told to ask an admin.

• After Google, GitHub, Microsoft or SSO: the sign-in goes on to the code step on the login page. The session that follows is named after the method you used, so Settings and the audit log show how you signed in.
• Invitations: if your account uses two-factor authentication, sign in first, then open the invitation link again to accept it. Accepting while signed in keeps your current session.
• No change if your account doesn't use an authenticator app.
• Chat: the same applies to the chat app's sign-in.

• No change if your account doesn't use an authenticator app: the link signs you in as before.

• Who is affected: only Anthropic providers with a base URL set. Without one, calls go to api.anthropic.com as before.
• Residency evidence: a run's provider residency now matches where non-streaming calls actually went.
• Self-hosted: private-address and redirect checks (NORCASTER_PROVIDER_ALLOW_PRIVATE_HOSTS) now apply to these calls too.

• Rebuild older Dockerfile deployments: a deployment built before this change runs a tagged image from the old registry. Its next run is refused with "rebuild the deployment". Redeploy it once; the new build is pinned by digest.
• Your build steps: RUN steps can still download packages from the public internet (ports 80 and 443). Private network ranges and the cloud metadata address are blocked. A build that needs a private package mirror on an internal address won't reach it.
• Whose GitHub access: a redeploy with a new source builds with the GitHub connection of the member who started it, not the deployment creator's. If that member hasn't connected GitHub, the build fails with a message saying so.
• Limits: a build has 30 minutes, 2 CPUs, 4 GiB of memory and 20 GiB of disk.
• Unchanged: model-bundle deployments, and how you start a deploy from the portal or POST /deploy.

• Custom images: report the result over HTTP. A job gets RESULT_URL and RESULT_TOKEN. POST the result JSON (output_data, plus optional tokens_used, tokens_input, tokens_output and compute_seconds) with Authorization: Bearer $RESULT_TOKEN. The answer is 204. A job no longer receives REDIS_URL or storage keys, so an image that wrote to Redis fails until it is rebuilt.
• Model bundles: MODEL_BUNDLE_URL replaces the storage keys. Download the bundle from it, and don't log it: the link grants that one file.
• Network: a job can reach the public internet on port 443 (for example to download a model), its RESULT_URL and its bundle link, but no other Norcaster service, private address or the cloud metadata address.
• Limits: a job has 15 minutes, 2 CPUs and 4 GiB of memory. A failed job is not restarted on its own. The existing retry and fallback model settings still apply.
• Unchanged: Norcaster's default inference image, and how you run a deployment (/run, the gateway, workflows).

• Anthropic SDKs and Claude Code get the error body they expect, so error.type and error.message read as they do against Anthropic.
• Provider unreachable: the 502 is typed api_error, an Anthropic error type, instead of server_error.
• Body too large: the 413 is typed request_too_large, as Anthropic answers it.
• /v1/chat/completions, /v1/responses, /v1/embeddings and the other OpenAI-compatible routes are unchanged.

• The response: 502, type api_error, "The provider returned a response the gateway could not read". The run is recorded as failed.
• Error statuses with a non-JSON body keep their status; what their body says is covered by the provider-errors change of the same day.

• Upgrading: docker compose up -d runs a one-shot volume-permissions service first. It hands the api_data volume an earlier release created as root to uid 10001, then exits.
• Check your license file: the API reads license.json as uid 10001, so it must be readable (chmod 644 license.json). A file only its owner can read leaves the install without a license.
• Verify an image: gh attestation verify oci://ghcr.io/norcaster/api:<version> --owner norcaster. The SBOMs (sbom-api.cdx.json, sbom-portal.cdx.json, sbom-chat.cdx.json) are attached to the GitHub release, and BuildKit's SPDX SBOM and SLSA provenance are in each image index.
• Unchanged: portal and chat already ran as uid 1001. Postgres, Redis, MinIO and Caddy run as their images do.

• Requests you can fix (400, 404, 409, 413, 422) keep the provider's status, type, code, param and message, for example a context length exceeded. On /v1/chat/completions and /v1/embeddings these used to be 502, so SDKs retried them.
• Rate limits: a provider 429 reaches you as 429 with the provider's Retry-After. An exhausted provider quota says so (insufficient_quota).
• Credentials: a provider 401 or 403 is now 502 with code provider_auth_failed: the deployment's provider credential needs updating under Providers. It is no longer a 401 that looks like your own Norcaster key failed.
• Outages: 502 provider_error / provider_unreachable, 504 provider_timeout, 502 provider_circuit_open while Norcaster pauses calls to a failing provider.
• Policy refusals: a residency or model-policy refusal on /v1/chat/completions, /v1/embeddings, /run and Chat is a 403 again, not a 502.
• Retries: the gateway now retries a provider call on 429, 502, 503, 504 and timeouts as reported by the provider's status, not on words in the error message.
• **/run** keeps its 502 for provider failures; detail.error is now a plain description and detail.code names the class.

• The response: on /v1/* the OpenAI or Anthropic error shape with type rate_limit_error and code rate_limit_exceeded; on /run a 429 with detail.code: rate_limit_exceeded. Headers: Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. The OpenAI and Anthropic SDKs retry on 429 and honour Retry-After.
• What counts: every request by the same user (all their keys and sessions), or by the same service-account or agent key. A burst of up to 600 is allowed, then the allowance refills continuously. /v1/models is not limited.
• What's recorded: a refused request writes no run. The first refusal per caller per minute is a platform audit event, gateway.rate_limit.reached.
• Hitting it? Tell us. Today it is one platform-wide default, not a per-organization setting.
• Self-hosted: set NORCASTER_DEFAULT_RATE_LIMIT_PER_MINUTE (default 600; 0 turns it off). If Redis is unavailable, requests pass and the API logs one warning a minute.

• Invalid JSON (or nested too deeply to parse): 400, code invalid_request, "Request body must be valid JSON".
• Not an object (an array or a string): 400, "Request body must be a JSON object".
• Retries: OpenAI SDKs retry a 500, so a malformed request was sent three times before failing. A 400 is not retried.
• Valid embeddings requests are unchanged.

• Retry-After: clients and SDKs that back off on Retry-After now wait the time the API states, instead of retrying at once. Other headers raised with an error now arrive too (WWW-Authenticate on the data plane, Content-Range on a byte-range error).
• Your configured rate: a deployment with request_rate_per_minute: 60 now allows 60 requests a minute on /run, as on the gateway, not about 30.
• Retrying: a refused request no longer counts against the window, so you're back under the limit as soon as older requests age out.
• Service-account keys on /run: a 429 for a service account's own rate limit now includes budget_status and retry_after_seconds, like the deployment limit.

• Verify a domain: in SSO & SCIM → Domains, add the domain and publish the TXT record shown, then choose Verify now. The record's value is shown once. A domain can be verified by one organization at a time, public mail domains can't be claimed, and verifying needs the Enterprise plan.
• Kept current: verified domains are re-checked daily. If the TXT record is gone on two checks in a row, the domain lapses and SSO stops adopting new accounts there. Accounts it already signed in stay linked.
• Link your own account: Settings → Security → Your single sign-on lists the organizations whose identity provider you can link. Choose Link and sign in at the provider. It must sign you in with your Norcaster account's own email. Unlink removes the link; your membership stays.
• This lifts the earlier limit: a member of more than one organization whose SSO is required can now sign in through it, once their domain is verified or they have linked their account.
• API: GET/POST /orgs/{id}/identity/domains, POST /orgs/{id}/identity/domains/{domain}/verify and DELETE /orgs/{id}/identity/domains/{domain}. Linking: GET /auth/sso-links, DELETE /auth/sso-links/{id}, the OIDC link-url / link-callback routes and SAML link-start. SCIM POST /Users answers 201 for an existing account at a verified domain. Changes are audited as identity.domain.* and identity.link.*.
• Self-hosted: NORCASTER_UNCLAIMABLE_EMAIL_DOMAINS (comma-separated, optional) adds domains no organization may claim.

• Approval ids of 49 to 128 characters: the approval request and the approver's answer are recorded in Decision Audit with the full approval_id, and approving or rejecting the call works. The rows' request id is action-approval- followed by the id's first 31 characters and a 16-character hash, so it fits. Ids of up to 48 characters keep action-approval-<approval_id>.
• Over 128 characters: tools/call returns JSON-RPC error -32602, Invalid params: approval_id must contain 1–128 characters, and nothing is held. Such a call could never run: the execution ledger accepts 1 to 128 characters.
• Unchanged: approval ids the gateway generates, shorter client ids, the approval queue, the approve and reject routes and their responses. A held call is still never sent to the tool without an approval.

• Still allowed: keyword-style alternations such as \b(password|passwd|pwd)\b, long lists of codes, and patterns like (\d{4}[ -]|\d{4}){3}\d{4}. Alternatives that begin with different text (ab|ac) never count.
• Refused: alternatives that can match the same text, repeated or chained past 16 ways: (a|aa){22}c, ([a-z]|[0-9]){24}. Write the second as [a-z0-9]{24}, or use a keyword rule.
• Limit: the check is conservative. A pattern that is actually cheap can be refused when its alternatives begin with a class or an escape such as \d.

• The line: "Governed · 12 requests through Norcaster in 24 h", or "Linked · no requests through Norcaster in 24 h" when there were none. It appears under the state in Findings and in the tracking list on the discovery setup page. Hover over it to see what the count covers.
• What it counts: the requests to the linked deployment that Norcaster observed in the last 24 hours, whoever sent them, as for the Governed state. It doesn't show traffic that goes to the provider directly.
• When there is no line: a closed system that isn't linked, or is linked to a deployment you can't see.

• Findings: the status lines for Bypass closing ("closed on"), Verified quiet ("since", "last looked"), Seen again after closing ("closed on", "data up to") and Still seen outside Norcaster ("data up to", "linked on"), in Findings and in the tracking list on the discovery setup page. The "data up to" time now reads the same as Last seen on that row. The Re-issue dialog's closing time is local too.
• Sources: "Last read" for provider admin keys and cloud accounts, a collector's "Last push" and its pairing code's expiry, and GitHub scan times. A pairing code shown as "22:15Z" to someone in central Europe expired at 00:15 their time.
• Runs and uploads: the window in the "Discovery ran" message, a log file's period and an inventory's generated time in their upload previews. What is uploaded is unchanged.
• Provider keys: the "last used" date on the setup page's review table is your local date. A key's Last seen is its last use, so near midnight the two used to show different days.

• Per provider: a circuit belongs to one provider in Providers, with its own endpoint, key and quota. Another organization's failures, or another provider of yours, no longer affect it.
• What counts: HTTP 5xx, 408 and 429 answers, timeouts, and connections that fail. A provider that refuses a request (a wrong or revoked key, a bad tool schema, a prompt too long) answers each call with its own error, and the circuit stays closed.
• Unchanged: after 5 such failures in a row a provider's calls answer 502 circuit open for 30 seconds, or go to your fallback provider model if one is configured, recorded as a failover with reason circuit_open. Streaming responses, /v1/messages and /v1/responses don't use the circuit breaker.
• Covered: non-streaming /v1/chat/completions and /v1/embeddings, /run, /rag/run, workflows, Norcaster Chat, and knowledge ingestion and retrieval.
• Operators: an opening is logged as gateway circuit open, naming the provider, its type and organization, and the last error's class and HTTP status, and counted in norcaster_gateway_circuit_open_total.

• Claude Code is unaffected: its own tools carry no type and are always allowed, and web search is allowed by default.
• New setting names: web_fetch, text_editor and memory can be set to allow or block under action_policies.hosted_tools, alongside the existing families.
• To allow remote MCP servers on a deployment, set hosted_tools.mcp to allow. Their tool calls then run at Anthropic and do not pass the MCP action gateway.

• Self-hosted: the images no longer contain python-jose, ecdsa or rsa.
• Identity providers that issue ID tokens with exp, as the OIDC specification requires, are unaffected.

• Self-hosted: set NORCASTER_MAX_REQUEST_BODY_BYTES and NORCASTER_MAX_MULTIPART_BODY_BYTES to change the limits.
• Hybrid data planes: a gzip'd event batch may expand to at most 32 MiB; the Sync Agent's batches are far smaller.
• Chunked requests without a Content-Length are counted as they arrive and refused once they pass the limit.
• Not changed: request rate limits are still the per-deployment and per-service-account request_rate_per_minute budget, off unless you set it.

• Sign-in records: auth.login.success, auth.login.failure, auth.mfa.challenge, auth.mfa.failure, auth.mfa.enrollment_required and auth.password.changed carry the person's address in source_ip. So do the session record and the security alerts built on these events.
• API keys: a key's last-used address is the caller's, and access.api_key.used_from_new_ip is written when a key is really used from somewhere new. It was written thousands of times a day as requests alternated between two proxies.
• Login limit: the per-address limit (10 attempts per 15 minutes) now applies to sign-ins through the portal too. People signing in from one shared address share that limit.
• Self-hosted: the portal hands the API the browser's address only when both share PORTAL_CLIENT_IP_SECRET. Without it, nothing changes from before.
• Before this release: stored records keep the proxy's address; the real one can't be recovered.
• API: no request or response shape changed.

• Accounts already linked to your identity provider sign in as before, and so do new people: SSO creates their account.
• Someone who belongs to more than one organization and has not signed in through your SSO before keeps signing in with their usual method. Limit: if your organization requires SSO, such a member can't sign in until account linking ships; owners and admins keep the audited password break-glass.
• API: POST /orgs/{id}/members answers 409 for every address. Send an invitation with POST /orgs/{id}/invites; the person accepts it signed in to their own account.
• SCIM: creating a user whose email already has a Norcaster account that is not a member answers 409 with scimType: uniqueness. Invite that person; SCIM manages them once they have accepted.

• Refused on Norcaster Cloud: URLs whose host is loopback, private, link-local (cloud metadata included), cluster-internal or an unqualified name. An alert rule or identity provider answers 422; a policy config 422; legacy SSO settings 400.
• Already saved: a stored URL with such a host is not rejected on read or on the request path; Norcaster refuses to connect to it, as a failed delivery or a failed sign-in.
• Self-hosted: private hosts stay allowed, for an identity provider or webhook receiver on your own network.

• Run through the gateway sits beside Preview decision in the tab's tool-call section. Preview still evaluates the current draft and records nothing. Run sends the exact tools/call an agent sends to /v1/mcp/{deployment}, after a confirmation.
• Always the saved policy. Run is off while the tab has unsaved changes, and it never sends a draft or an override.
• You are the requester. A call that escalates waits in Action approvals with your name on it, so another person approves it; approving your own call is refused, as for any agent.
• The result says what happened: Ran, Ran with redaction (and whether personal data in the arguments was actually replaced), Blocked with the gateway's reason, Waiting for approval with a link to the queue, or Failed when the tool or its server failed. Every outcome is in Decision Audit.
• The tool's output is shown only in part (its first 400 characters, collapsed). A stopped deployment or an organization kill switch refuses the call with its usual message.
• Unchanged: who can call the governed endpoint (runs permission and deploy access on the deployment). No API endpoint or response changed.

• Applies to lists the organization's deployments, named by model ID, and its workflows. Before, any organization with a deployment you could see got a server error, and both lists read as empty.
• A failed load shows "Deployments and workflows could not be loaded." with Try again, which reloads the lists without closing the form. The fields say what saving does: a new rule applies to all deployments and workflows, and an edited rule keeps the ones it already had.
• Unchanged: rules scoped through the API, how rules are evaluated and how alerts are delivered. No API response changed shape.

• Overview → Runtime controls → Policy packs: lists the applied pack only. Before, after applying the Finance Pack it read "Student Privacy, Enterprise baseline, GDPR Pack, Finance Pack, Healthcare Pack · update available".
• Policies tab: only the applied pack is marked Applied. The other four no longer show "Update available" or an "Update to v…" button. Confirming that update applied the other pack, which replaced the pack in force and its tier actions.
• Deployments list, Policy column: names the applied pack. Before, every deployment on one of the five showed "Student Privacy".
• Workflow runs: new runs on a linked deployment record the applied pack as policy_version_id in their lineage. Runs recorded before keep what they recorded.
• Unchanged: what is enforced. Requests were always checked against the deployment's stored configuration.
• Still listed as all five: a deployment configured before packs recorded their contextual policy (apply the pack again to record which one it is), and a deployment that carries another pack's contextual policy on this shared contract.

• Preview: the page carries a Preview label and a notice describing what a customer-hosted data plane does today. The earlier note about revoked data planes serving from their last bundle is gone: no revoke action exists yet, and received bundles aren't applied.
• Table: each data plane shows where it runs (your own server, AWS or Azure), the bundle it has received and whether a newer one is published, when it last reported, and its health. Degraded and offline data planes say why, for example when the last report is old or the agent has dropped metadata events.
• Not connected yet: a data plane whose Sync Agent hasn't reported is shown as not connected yet, not offline, and isn't counted as behind on bundles.
• Row actions for admins and owners: issue a new enrollment token for a data plane that hasn't enrolled (earlier unused tokens stop working; the new one is shown once), download the install kit for an AWS or Azure data plane, and copy its ID.
• Names: a data plane on your own server can be named when you add it.
• Organization: the page shows and adds data planes for the organization selected in the sidebar, and so does the data plane list on the Integrity page. Admins and owners can add data planes and issue tokens; other members see the list. Without an organization the page offers to create one, and connection errors are reported as errors.

• What carried values: the database library's list of a statement's values, and what Postgres repeats in the error itself: the failing row of a NOT NULL or CHECK violation, and the key of a unique or foreign-key violation.
• Where they went: API and worker logs, tracebacks of unhandled errors, and the error text stored on jobs, runs, run errors and knowledge ingestion jobs, which the API returns.
• What an error looks like now: null value in column "…" of relation "runs" violates not-null constraint, DETAIL: Failing row contains (values hidden)., [SQL parameters hidden due to hide_parameters=True].
• For operators: to debug a failed write, reproduce it from the run or job id. No setting shows the values again.
• Not changed: database migrations hide statement values but can still print the failing row or key. Errors stored before you upgrade keep their text.

• Sign-in: password, Google, GitHub and Microsoft, SSO, invitations, the MFA step and email verification all answer "This account is deactivated. Contact support to restore access.", the message password sign-in already gave. Accepting an invitation no longer adds a deactivated account to your organization.
• Sessions and keys: a session the account still holds ends at its next request. Its personal API keys answer 401. Service-account keys it owns keep working, so your integrations don't stop when their owner leaves: revoke them or the service account when you offboard someone.
• Reactivation through SCIM restores sign-in and the person's personal keys.
• Audit: each refusal is recorded as auth.login.account_blocked, with the sign-in method. Before, password refusals left no record and the other methods recorded a normal sign-in.
• Erased accounts: signing in with the address of an erased account still creates a new, empty account, as signing up with it already did.
• API: the routes above answer 403 (sign-in) or 401 (session, API key) for a deactivated account. No request or response shape changed.

• Agent actions read Action allowed, Action redacted, Action blocked or Held for approval, in the colour of the matching model-call decision. A blocked call says it never reached the MCP server. A held call says nothing is sent unless an approver allows it, and that the approval decision is its own event.
• Approval rows for an agent action name the tool, for example wire_transfer, and say whether the approver allowed or rejected it. Before, they read "Policy decision recorded" and, for a rejection, "Blocked before model execution". A requested approval is labelled Approval requested, which stays true after the approver answers.
• The Awaiting approval tab is now Held for approval. It lists every escalated agent action, whatever the approver decided next. Calls that are still waiting are in Action approvals.
• Unchanged: the stored decision on each row (allow, redact, block, escalate), the Decision filter, exports, audit bundles and every API response.

• Agent tool calls: use the Agent actions tab. It lists the recorded agent tool calls from the MCP Action Gateway and from workflow action policies, whatever the decision.
• Approval decisions: use All events with Event kind Approval granted or Approval denied. Approval rows are separate events, so the Agent actions and Held for approval tabs don't list them.
• Unchanged: the API's event_kind filter, exports, audit bundles and every stored row.

• Redacted (?action=redact) lists model-call redactions and agent actions decided redact. The 24-hour PII redaction counts include agent redactions; on the AI register and Evidence they count the same rows as their View redaction records link.
• Held for approval (?action=escalate, alias requires_approval) is a new Decision option: agent actions held for human approval, the same rows as the Held for approval tab.
• Warned (?action=warned) no longer includes agent redactions or escalations. API and export callers who need every row stored as warned can filter with severity=warning.
• CSV export has a new last column, action_decision (allow, redact, block, escalate; empty for model calls). Existing columns keep their positions.
• Links with ?action=redact now show Redacted in the Decision filter instead of All decisions.
• Model-call redactions in Decision Audit read Redacted with the redaction sentence. Before, they read Allowed and "Request passed policy checks."
• Unchanged: stored rows, the list response shape, JSONL fields, the trace chain, webhooks, and the allowed, blocked and warned totals on Overview, where agent redactions and escalations still count as warned.

• Coverage: Assured, Governed calls, Ungoverned calls, Unknown systems and Untriaged in one row. Each figure keeps its tag (Evidenced, Attested, Proven or Not proven), with its meaning on hover. The calculation, the gap and any caveats are under How this is measured, and the page still says when no reconciliation source ran.
• Systems: each system shows its source with the provider and models, when it was last seen in your local time (first and last seen in UTC on hover), its calls, its state and its linked deployment.
• Next step: the step that matters most for a system (close the bypass, re-issue its controls, register and deploy, connect, or link it) is a button on its row; linking, marking registered, dismissing, unlinking and the suggested pack are in the row's menu. A dismissed system has no button.
• Sources & schedule has its own tab: what each source sees and when it last reported, the scheduled run, and the provider usage reconciliation switch.
• If the coverage figure can't be loaded, the page says so instead of leaving the space empty.
• Discovery's dialogs match the rest of the dashboard.

• What changed: scans and pull requests run in Norcaster's background worker, which signs in as the GitHub App. It needs the App's id and private key, but it also required the App's install-link name, which the worker didn't have. It now signs in with the id and key alone, and also receives the App's full settings.
• What you need to do: on a repository that showed the error, click Scan now. Your GitHub connection stays as it is.

• What you see: a pull request that is opening or open names the repository by its new name. Its link still works, because GitHub redirects the old address.
• Asked for before the rename: it opens in the renamed repository, on the same norcaster/<app> branch, with the same change. This works even when no scan has noticed the rename yet: opening follows it the way a scan does.
• Already open: merges and closes reach it again, from GitHub's notification or from the daily check. The daily check catches up after the next scan of the repository.
• Not followed: a repository that was renamed and then picked again before Discovery followed renames. Its pull requests still don't follow it.

• Step bar: a tick on each finished step (a source has listed something, systems are chosen, a policy is chosen, a system is linked, every linked system is governed), Back and Next on each step, and a short explanation when a step has nothing to show yet.
• Sources: one card each for Code (GitHub, collectors, inventory upload), Provider accounts (usage reconciliation, admin keys), Cloud accounts and Network logs, with what each source has listed and when it last reported. Connection details open inside the card.
• Projects: in an organization without projects, the deploy step creates a project named Default for the new deployments, as the New deployment window does (an organization admin is needed). With several projects you now choose one explicitly; the list no longer looks chosen when it isn't.
• Monitor period can be cleared and retyped (1 to 90 days). Packs, provider models, projects or deployments that can't be loaded are named, with Try again, instead of showing as missing.
• Removing a source asks first and says what happens: what Norcaster stored to connect is deleted, the systems it listed stay, a collector's key is revoked, and access you granted in GitHub or a cloud account stays until you remove it there.
• Pull requests: systems whose pull request wasn't opened are listed with the reason, and each approval link names its repository.
• The page no longer says nothing changes until you press a step's button: connecting a source, uploading and the reconciliation switch take effect at once, while deployments, links and packs are created only in the deploy step. Providers are named in words (OpenAI, Amazon Bedrock), and the provider usage reconciliation switch is visible when it is off, here and on the Discovery page.

• Refused: the organization policy-pack manifest and dry run, reporting a concern, and any viewer-level organization route added later unless it is opened to reviewers on purpose. The answer is "External reviewers can read only the obligations, evidence and audit bundles in their scope."
• Still read, with less in them: the organization now comes back with only its name, the frameworks in scope and the environment type. The access overview keeps the reviewer's own role and permissions and the active-reviewer count; the member, MFA, plan and seat figures are empty.
• Unchanged: for reviewers, Obligations, Evidence, Audit bundles, Incidents and the runtime-halt banner work as before. Every other role is unchanged.
• API: in GET /orgs/{org_id}/access-overview, the member counts, last access change, MFA figures, plan and seat fields can now be null, only when the caller is an external reviewer.
• Docs: the security page now lists what the external reviewer role is refused.

• Refused for external reviewers: the organization's saved templates (the built-in ones stay), Shared Record exchanges and key documents, and the trace chain's anchors, keys, breaks and custody pages. None of these appear on a reviewer's pages.
• Limited to the reviewer's deployments: the AI register summary and history, the trace chain's failure counts, and verifying a run or downloading its proof bundle. A reviewer scoped to a project or deployment no longer sees the chain's head, anchor history or key details in its status.
• Saving a template from a workflow needs an Owner, Admin or Engineer role, as building a workflow does. Viewers, Governance and Leaders get "Organization role does not allow building or running workflows", and still see the organization's templates.
• Project-scoped reviewers now reach their project's deployments in the register history and attestation history, where they were refused before.
• Expired access no longer counts toward the personal AI register summary.
• Unchanged: for reviewers, Obligations, Evidence (including Verify this trace and the proof bundle for their decisions) and Audit bundles work as before. No API response changed shape.

• Cache hits: exact and semantic hits on /v1/chat/completions return 200 with the cached answer. The run is marked completed with cache_hit in its response metadata, and its cost record shows zero cost with cache_hit true. /v1/embeddings hits were not affected.
• Completions with a NUL character on /v1/chat/completions (streamed or not) and /v1/messages are returned and recorded as usual, and stored in the semantic cache with the NUL written as the text \x00. A later semantic-cache answer returns it that way. The exact cache keeps the original text.
• Earlier runs: runs left "running" by this stay that way.

• Forwarded: OpenAI and Azure OpenAI get every chat parameter except the few below. Other providers get the ones their API documents: at least temperature, top_p, the token limit and stop. Anthropic gets the token limit and stop sequences; current Claude models refuse sampling parameters.
• Token limit: max_tokens and max_completion_tokens are sent under the name the provider expects. OpenAI's reasoning models refuse max_tokens, so OpenAI gets max_completion_tokens.
• Not forwarded: user, prediction, store, metadata, service_tier, logprobs, web search options and audio output. Your operator can set them on the provider.
• New error: n above 1 answers 400; the gateway returns one choice per request.
• Operator control: client_params on a provider's config limits which parameters it forwards; [] forwards none.
• Unchanged: policy reads your messages only, as before. /v1/messages and /v1/responses already forwarded your request body.

• **SSO links (external_identities):** for each link, the organization, the identity provider's name and type (SAML or OIDC), the subject Norcaster matches you on, the address the identity provider sent, and when the link was made and last used to sign in.
• **SCIM groups (scim_group_memberships):** for each group, the organization, the group's name and the identity provider's id for it, and when you were added.
• Organizations you have left: a sign-in link can outlive your membership, so the export lists it there too.
• API: GET /auth/gdpr/export has these two new keys. The existing keys are unchanged.
• Not changed: what erasing your account data removes, and the rest of the export.

• Now caught: an IBAN written without spaces, in groups of four, or in its national grouping, on every surface a pack applies to (input, output, tool arguments, retrieved content). For example, under the Finance Pack, "Please wire 250000 EUR to account NL91ABNA0417164300 now." used to be allowed and is now blocked.
• Redaction: packs that redact replace the whole IBAN. Before, "NL91 ABNA 0417 1643 00" was redacted as "[REDACTED: IBAN] 00".
• No longer matched: text that only looks like an IBAN. That covers a wrong check digit, the wrong length for the country, a country code that has no IBANs, and a truncated IBAN, for example a 16-character product code such as AB12CDEF34567890, which was blocked as an IBAN before.
• Not read: IBANs in lowercase, or with the country code and check digits written apart ("DE 89 …").
• Audit records: decisions carry detector ruleset 1.11.0, and each IBAN detection records its country. Pack revisions, pack actions and thresholds are unchanged.

• Who was affected: databases that never ran a Norcaster release from 9 March to 22 April 2026, which in practice means installs set up since 22 April. Databases that ran one of those releases already have the column.
• What failed: syncing a knowledge source into a knowledge base whose vector index uses pgvector. The ingestion job failed with column "embedding_vector" of relation "chunks" does not exist. Pinecone, Weaviate and Qdrant indexes were not affected.
• Retrieval: did not fail, but found nothing in these knowledge bases, because a failed sync keeps none of what it read.
• After upgrading: the API adds the column at its next start, with no migration to run. Sources that failed stay in Error until they sync again, so run a sync on each one.
• Unchanged: the startup log still warns "pgvector extension not available" when pgvector is installed. That warning is about a search index, not the column, and will be fixed separately.

• Names: the sidebar, the page title and every link to these pages now say Teams and Members & roles. The addresses are unchanged, so bookmarks keep working.
• SSO roles: the default role for people signing in through SSO for the first time, and the role a group mapping grants, are chosen from Owner, Admin, Engineer, Viewer, Governance and Leader, in that order. External Reviewer access needs a scope and an end date, so reviewers are invited from Reviewers.
• Identity audit: what each event changed reads as Organization, or the provider type and name, for example OIDC · Contoso.

• Recorded now: a forged, expired or reused sign-in link; an ID token that fails validation or lacks a subject or email; an identity provider that doesn't confirm the email address; and an email that belongs to an account SSO can't link.
• The reason is in the event's metadata.reason from the API: bad_state, state_expired_or_replayed, id_token_invalid, claims_missing, email_unverified or jit_conflict.
• Before this release: refused sign-ins were never stored, so they can't be shown.
• Still not recorded: a sign-in to an organization whose OIDC provider is missing or turned off, and a sign-in that fails because the identity provider can't be reached.
• Not changed: what a refused sign-in answers, and how successful sign-ins are recorded.
• API: GET /orgs/{org_id}/identity-audit now also returns these events. No request or response shape changed.

• API keys tab: a key for a service account or agent reads "For ci-deployer (service integration)" or "(agent)", with "Acts with owner@…'s access" under it. Members' own keys are shown as before.
• Revoke on such a key revokes it through the account, as the account's own Keys dialog does, so the revocation is recorded against the account. The confirmation says the integration can no longer call with that key and stops working until it gets a new one; the account and its other keys stay active.
• Other organizations: a key minted for another organization's service account no longer appears on this organization's tab, and can't be revoked from it. Before, it showed when its owner belonged to both organizations.
• API: GET /orgs/{org_id}/api-keys adds service_account_id, service_account_name and service_account_kind to each key; they are null for a member's own key. POST /orgs/{org_id}/api-keys/{key_id}/revoke answers 409 for a service account's key, naming the route that revokes it: POST /orgs/{org_id}/service-accounts/{sa_id}/keys/{key_id}/revoke.
• Unchanged: who can see and revoke keys (owners and admins), and every other field of the response.

• Requests (24h) and Block rate (24h): redacted requests count in both, so a block rate can be lower than before when the policy redacts some traffic. The blocked count is unchanged.
• Enforcement outcomes (7d): Allowed includes redacted requests. Agent tool calls the policy redacted or held for approval stay under Warned, as before.
• Detection claims: a claim disputes an earlier decision, so the chart no longer counts it as an allowed request.
• PII redactions tile: the number was already the last 24 hours. The link opened 7 days, so the Evidence page listed more rows than the tile counted.
• Unchanged: the fleet overview response keeps its fields. Exports, filters and stored rows are unchanged.

• Recorded now: a login with an unknown email or a wrong password (metadata.reason unknown_user or bad_password), a wrong MFA or recovery code, and a session that reached its absolute lifetime or idle timeout (metadata.reason absolute or idle).
• Unknown email: the record keeps what was typed only when it looks like an email address. Anything else, such as a password typed into the email field, is stored as email_malformed: true with no text.
• Before this release: these events were never stored, so they can't be shown.
• Not changed: what a refused login or an expired session answers, how successful logins and new sessions are recorded, and the alerts.
• API: no request or response shape changed.

• Where it shows: the history on the deployment's AI register page, GET /deployments/{id}/register-audit, and the change history in audit bundles. Changes made through a partner governance package are recorded too.
• Platform audit: the register update event now includes these fields. The legal owner's name and contact are masked there, as the accountable person's details already are; the register history keeps the full values.
• Unchanged: register completeness counts the same fields as before, and no API response changed.

• ISO/IEC 42001: A.6.2.7 (technical documentation) and A.8.2, A.8.5 (information for users and interested parties) show, for example, "3 of 4 systems have a generated sheet".
• RBI FREE-AI: once eval runs exist, the Rec. 16 model lifecycle row also says how many systems are documented with a generated sheet.
• Where sheets come from: the System information sheet panel on a deployment's AI register page. Open printable sheet, Download PDF and Download JSON each record a generated sheet.

• Connect, disconnect, bind, unbind and the channel picker need an active Owner or Admin in the organization. Other roles get "Only organization owners and admins can manage the Slack integration." The channel picker was open to every member; it lists the workspace's channels, private ones included, with the organization's bot token.
• Status and bindings: any active member except an external reviewer still sees whether Slack is connected and which channels are bound.
• Expired access is refused on every Slack integration call, and the organization's MFA requirement applies to owners and admins.
• Organization choice: a request that names an organization the caller does not belong to is refused. It used to be answered from the caller's first organization.
• Binding: binding a channel to a deployment failed with a server error for everyone. It works again for owners and admins.
• Unchanged: API keys still need the admin scope. No API response changed shape.

• Default role and group roles: choosing External Reviewer on the SSO & SCIM page is refused with a message that says why. Invite reviewers from the Reviewers page, where you set their scope and end date.
• Saved before: a provider that already has External Reviewer as its default role signs new members in as Viewer. Choose another default role the next time you save it. Members already created keep their role; check them on the Reviewers page.
• Invited reviewers who sign in through SSO keep the scope and end date of their invite.
• Secure storage unavailable: saving a client secret or signing certificate, or rotating the SCIM token, answers 503 with what wasn't saved. Nothing is changed. Before, it failed with "Internal server error".
• API: PUT /orgs/{org_id}/identity/providers/{type} and PUT /orgs/{org_id}/identity/role-mappings answer 422 for external_reviewer. No request or response shape changed.

• OIDC and SAML sign-in on a plan without SSO answer 402 with the upgrade message, before any account or membership is created. Each refusal is recorded in the identity audit. The sign-in page shows "SSO / SAML is available on Enterprise." Before, a refusal from the older SSO sign-in showed "[object Object]".
• SCIM can't add members or reactivate them on such a plan: POST /Users with active: true, and PUT or PATCH that set active: true on a deactivated member, answer 403 with a SCIM error. Reads, deactivation, DELETE and Groups keep working, so your identity provider can always take access away. Each refusal is recorded in the identity audit.
• Require SSO on: members keep signing in through SSO and SCIM keeps working, also after a downgrade. Require SSO can only be turned on with SSO on the plan. If you turn it off on a plan without SSO, SSO sign-in stops, and you can't turn Require SSO back on until you upgrade. The page now says this before you turn it off.
• The older SSO sign-in (the Settings page's SSO configuration) follows the same rule. With Require SSO on it keeps working after a downgrade, and on self-hosted installs without a license. Before, it refused, and members other than owners couldn't sign in at all.
• Self-hosted: the license's plan decides, as before.
• Unchanged: setting up providers, SCIM and group mapping on any plan; the SAML metadata URL; Require SSO's own rules. No request or response shape changed.

• Approve, reject and cancel need an Owner, Admin or Engineer role in the run's organization, the same as starting a run. Viewers, Governance and Leaders get "Organization role does not allow building or running workflows". Unblocking a run still needs an owner or admin.
• External reviewers are limited to the obligations, evidence and audit bundles in their scope. A workflow run can reach several deployments, so they no longer see workflow definitions, executions, traces, approvals or tools. A run's detail page no longer shows them its workflow execution.
• Expired access: a member whose access has ended no longer lists or opens the organization's workflow definitions. Executions and every change were already refused.
• Unchanged: owners, admins and engineers work as before. Viewers, Governance and Leaders still see workflows, executions, traces, approvals and tools. No API response changed shape.

• Edit changes an account's name, description, deployments, scopes for new keys, and its request and daily-token budget. Scope changes apply to keys minted afterwards; existing keys keep theirs. A change of deployments also applies to the account's active keys, and a budget change applies at once. Before, an account could not be changed after it was registered.
• Deployments are chosen from your organization's list by name, or left open to any deployment the owner may run.
• Scopes are chosen per resource with Read and Write, where Write includes Read, plus Coverage ingest, Discovery push and Admin, each with a short description.
• Keys lists an account's keys with their scopes, expiry, last use and status. A new key can be given an expiry in your time zone, and is shown once with a Copy button. Revoking a key, or the whole account, asks first and says how many keys stop working.
• Discovery collectors are marked as such, and editing or revoking one warns that the collector depends on it.
• Members other than owners and admins see that only owners and admins can view these accounts. Before, they saw an empty list, whatever was registered.

• Kept on save: editing a deployment's request rate, compute per request, retry ceiling, warning threshold or breach action keeps its other budget settings, such as a monthly token cap. Saving organization defaults changes only the budget defaults.
• Plan caps: tokens, compute and GPU used this period against your plan's caps, with what is left, a forecast and daily usage charts. The caps come from your plan, and a link compares plans.
• Deployment limits sit in one table grouped by project: tokens used (against the deployment's monthly token cap when it has one), compute, rate limit, compute per request, retry ceiling and breach action. None means the deployment has no limit of its own; your plan's caps still apply. Members who can deploy set, edit or remove a deployment's limits from its row. A deployment in immutable production mode explains that its limits change through a config proposal.
• Breach action: Block is the only breach action the runtime enforces today. Choosing another one says that requests over a limit are still blocked.
• Organization defaults hold the warning threshold, used for charts, forecasts and deployments that don't set their own, and the breach action a deployment starts with when someone sets its first limits. Monthly compute, request limit and retry cap had no effect and are no longer offered here.
• Recent budget events say why a request was refused, such as the request rate limit, the monthly token cap or compute left this period, and where alerts go.
• When the organization chosen in the sidebar isn't your primary organization, the page says that it shows your account's caps and your primary organization's deployments.

• What changes: a redirect from the Norcaster API URL ends the command with exit code 1 and a message naming the redirect's host. Set NORCASTER_API_URL (or connect --api) to the API's own address.
• Exposure: the collector key can only push Discovery data; it can't read anything or call the gateway. If you think a key went somewhere else, remove the collector on the Discovery setup page and pair again.
• Unchanged: the four routes the collector calls, and the https-only rule (plain HTTP only to localhost).

• What changes: memory stays about the same whatever the log's size, so multi-gigabyte exports scan on an ordinary laptop or CI runner.
• Very long lines: a single line over 1 MiB is counted as unparsed instead of being read.
• Unchanged: every other log gives the same rows, hosts and counts as before, and nothing beyond AI hosts, counts and hourly windows leaves your network.

• Refused and listed: a path that leaves the repository through .., an absolute path or a symbolic link goes under "Needs a human". An unexpected system id goes under "Not patched" with "scan again".
• Unchanged: inventories the scanner wrote patch exactly as before. sync --open-prs and Discovery's hosted pull requests build their own inventory, so they were not affected.

• Hosted pull requests change only the client lines, as for any other file.
• Mixed line endings: a file that mixes CRLF and LF isn't patched. It is listed with "mixes line endings; change by hand."
• Unchanged: LF files get exactly the same patches as before.

• What changes: each line of a row the CSV reader can't read counts towards the "unparsed" number the scan prints, like a row without a host or time. The rows around it are read as usual.
• Clear stops: a header row that can't be read, or an --egress path that isn't a file, now ends the command with a message and exit code 2 instead of a Python error.
• Unchanged: logs without such rows scan exactly as before, and nothing beyond AI hosts, counts and hourly windows leaves your network.

• Where: in the Discovery table under the state, and in the setup page's review list.
• Which scans: a GitHub scan, an inventory you upload and a collector push. Each counts as a full read of the repositories it reports, and a GitHub scan counts even when it finds nothing.
• Nothing is removed: the app keeps its triage state, link and policy pack, and stays in the counts until you dismiss or register it. If a later scan finds it again, the note goes away.
• Uploads are complete for their repositories: if you trim apps out of an inventory before uploading it, those apps are marked as not in the latest scan.

• What is read:

- openai-go and anthropic-sdk-go: option.WithBaseURL;

- go-openai: cfg.BaseURL after DefaultConfig;

- openai-java and anthropic-java: the builder's .baseUrl(...) or fromEnv();

- OpenAI .NET: Endpoint in OpenAIClientOptions;

- Anthropic .NET: BaseUrl.

A URL in an environment variable is looked up in the service's .env, YAML or TOML files, with the code's fallback value.

• Your own gateway: a client whose base URL is on a host you pass with --norcaster-host now shows as governed.
• Other gateways and unknown hosts: a client sent through Portkey, Helicone, Cloudflare AI Gateway, OpenRouter or Vercel AI Gateway, or to a host Discovery doesn't know, is listed under "Not patched" with the reason, and gets no automatic change.
• Self-hosted servers: a client sent to a vLLM, Ollama or other self-hosted server gets its own system, and the plan adds a provider for that server. A local patch still points it at Norcaster, but Discovery no longer offers a GitHub pull request for it, as for Python clients.
• Earlier GitHub scans are redone once, at the next daily scan.

• Evidenced: a GitHub scan, uploaded inventory or collector push of the app's repository, made after you closed it, counts as a look. That applies when the scan shows the app going through Norcaster, or doesn't find it at all.
• Deny lists keep these hosts: closing is your decision, so Norcaster doesn't take an app's hosts off the list itself. A new warning counts the closed apps the latest scan no longer has. Dismiss them or mark them registered to take them out.
• Unchanged: other sources, the quiet period, and apps the latest scan still reports.

• Why: these SDKs can't send the deployment header, so the scan recognised them only by api.norcaster.com in their code. It now also recognises NORCASTER_BASE_URL, the variable every Discovery patch reads the gateway URL from, in the code that creates the client.
• Your own code: a client that reads its base URL from NORCASTER_BASE_URL counts as governed. A comment or another line mentioning it does not.
• Earlier GitHub scans are redone once, at the next daily scan, so a system already patched shows as governed without a new commit.
• Unchanged: Norcaster's cloud gateway, and every other SDK, which already sent the deployment header.

• Which hosts: api.norcaster.com, your install's own address, and api.<base domain> of each data plane your organization registered. These are the same hosts the egress block lists never block.
• Every language: Python, JavaScript and TypeScript, Go, Java and Kotlin, and .NET clients.
• Earlier GitHub scans are redone once, at the next daily scan. A repository is also scanned again when you register or revoke a data plane.
• Earlier entries: if an earlier scan listed such a client as an unknown host, that entry is now marked "not in the latest scan" (see the next change).

• What counts after the line that creates the client: setting its base URL or endpoint (base_url, baseURL, BaseURL, api_base, endpoint), also over several lines. Calls such as client.chat.completions.create(…), and other settings, don't count.
• Chains: only a Java or Kotlin builder() chain is read, up to .build(). A request chained on the client, as in OpenAI().chat.completions.create(…), doesn't count.
• What you may see: a client that only seemed governed now shows as not governed, and gets a patch or pull request.
• Unchanged: clients rewritten by Discovery's patches still scan as governed, on api.norcaster.com and on your own gateway.

• What counts: the client's base URL on a Norcaster gateway, or the X-Norcaster-Deployment-Id header, NORCASTER_DEPLOYMENT_ID or api.norcaster.com in the code that creates it. That includes its builder chain or initializer, and for go-openai the cfg.BaseURL = … lines after it. Comments, other strings and other clients in the file don't count.
• What you may see: a service with a gateway client and a direct client now shows as partially governed, and the direct client gets a patch or pull request.
• Narrower: a header set in a helper function or a shared variable isn't followed. Such a client shows as not governed unless its base URL points at Norcaster.
• Earlier hosted scans are redone once, at the next daily scan, even when the repository has no new commit. From now on a GitHub scan skips a commit only if the same scanner already scanned it, so later scanner fixes reach your repositories the same way.
• Unchanged: clients rewritten by Discovery's patches still scan as governed. One exception: the .NET Responses client, which the patch already leaves for you to change.

• GitHub scans count the files they skipped. A repository with any skipped file adds and updates the apps found, but marks nothing as gone.
• Uploads and collector pushes say which repositories were read in full. norcaster-discover takes them from the inventory: those with no skipped files. The portal also leaves out the repository of any app it can't upload.
• Bypass verification: a closed app counts as checked only when a later full read of its repository no longer lists it as ungoverned.
• **Uploads from older norcaster-discover versions** don't say which repositories were read in full, so they add and update apps but mark none as gone.

• Scans: a scan still running after an hour is marked failed: "The scan was interrupted when its worker restarted. The next scan of this repository runs it again." That happens the next time the repository is queued (Scan now, a push or the daily rescan), and that same scan is queued at once. The daily check also clears them.
• Pull requests: one still opening after an hour is marked failed, and you can ask for it again. If its branch was already made on GitHub, Norcaster says so and leaves it.
• Within the hour nothing changes: a scan or pull request that may still be running is waited for.

• Which time counts: the time in the inventory (generated_at), not when you uploaded it.
• What you see: the upload result lists such apps as skipped, with the reason "older than stored". The rest of the upload applies.
• Unchanged: uploads in order, and uploading the same inventory again.

• What you see: the repository shows under its new name, and its scans work again without picking it again. Picking it again under the new name works too.
• Apps under the old name: the scanner names apps after their repository, so after a rename the same apps are found again under the new name, in triage. Once the repository has been read in full, the entries under the old name show "not in the latest scan". That includes entries recorded before Discovery kept repositories with the same name apart.
• Not followed: a repository moved out of the GitHub App's installation still fails until it is added again.

• What you see: "not in the latest scan of owner/name" names the repository in full.
• Existing apps from GitHub scans move to their repository at its next scan, keeping their triage state, links and pull requests. That includes apps the repository no longer has: once the scan has read every file, they show as not in the latest scan. Norcaster tells an app's repository by the scan that last recorded it or, for an app the scan finds, by the name when only one connected repository has it. Other apps, such as one last recorded by an upload, stay as they are.
• Pull requests open for each repository's own apps, on the same norcaster/<app> branch as before.
• Uploads and collector pushes keep their own entries, by repository name. A repository scanned on GitHub and also uploaded from a checkout shows up twice.

• Builds and runs: a deployment's build or a run no longer waits while Discovery scans a repository or prepares a pull request.
• Time limit: a scan or pull request that takes longer than 15 minutes is stopped. It shows "The scan took longer than 15 minutes and was stopped."
• Unchanged: a scan reads the same files and keeps the same summary, with no file content. The scanner's process gets none of the platform's credentials.
• Self-hosted installs get the change with the next self-hosted release.

• By stage: counts for Production, Staging, Development and deployments with no stage recorded, then each deployment grouped by stage with its project, purpose and status. Deprecated and retired deployments are listed when there are any.
• Project filter when the organization has more than one project.
• A deployment's stage is part of its register entry and appears in AI register exports, the AI-BOM and Article 26 and 30 documents. It is set on the deployment's page; each row links there.
• Environment type in Settings is described as a label for the organization that doesn't change enforcement or how new deployments start. The Environments page no longer shows it.
• The roadmap note about dedicated environments is gone, and the page says when deployments can't be loaded.

• Use as root sends the data plane you pick, so the request reaches it. Before, every attempt was refused with "data plane not found for this organization". While the data plane is answering, the page names it instead of showing "…".
• Rotate key with a data-plane root now says the request was sent and that the current key keeps signing until the data plane certifies the new one on its next sync. Before, it said the new key was already active.
• Summary: Integrity shows the result of the hourly check and the position it covered, Anchoring shows whether every entry is covered by an anchor, Signing shows the active key, and Custody shows who holds the root. Where anchoring is not enabled, Anchoring reads Off instead of a "Pending anchor" warning that never cleared.
• A compromised chain shows the reason the hourly check recorded for the break.
• Owners rotate the key, register or revoke a root, and approve or deny a new signing key, each confirmed first. Other roles see the same information and a note that only owners can change keys and roots.
• Bring your own AWS KMS key lists what the grant lets Norcaster do and what it can't do, next to the key policy to copy.
• The Signed badge's tooltip on Traces, Evidence and Settings no longer says custody stays with Norcaster "until customer-held keys ship". It says Norcaster generates and holds each signing key, and Integrity shows who holds the root that certifies it.

• Syncs: a sync into a Pinecone index failed after the chunks were embedded. The job showed the message "renamed from pinecone-client to pinecone", and the source showed Error. Nothing was written to the index or the knowledge base, but your embedding provider had already been called for that sync. Re-sync the source to index it.
• Retrieval: /retrieval/query answered 500, /rag/run ended the run as retrieval_failed, and a workflow's retrieval step failed. They now return matches from the index.
• Unchanged: the vector index config (index_name, api_key, and an optional namespace; without one, each knowledge base uses its own namespace). pgvector, Weaviate and Qdrant indexes were not affected.
• Self-hosted installs get the fix with the next self-hosted release.

• Refused changes: a project policy change that would alter a live deployment needing approval or release assurance shows the reason and the deployment. Where approval is possible, Send for approval sends the same change to Change approvals; nothing changes until it is approved.
• Custom rules: turning contextual policy off removes the project's custom rules. The policy window now says how many will go, and asks you to confirm before saving.
• Table: each project shows its deployments with links, the policy it adds on top of the organization's (an enforcement pack and its mode, a contextual pack, custom rules, or Organization defaults) and when it was created.
• Actions: rename a project, edit its policy or view its pack contents from the row menu, each in its own window. Organization admins create and rename projects; changing a project's policy needs an admin with the manage-policies permission, and other roles see who can.
• The page follows the organization chosen in the sidebar, says when projects can't be loaded, and catches two projects with the same name.
• API: GET /deployments list items now include project_id, null when the deployment has no project.
• Warnings in the contextual policy settings (monitor mode, unrecognised packs) are readable in the light theme, here, in organization settings and on a deployment's policy.

• Turning it on without SSO sign-in on your plan answers 402, and without an enabled provider 409. The message says what is missing.
• The last enabled provider can't be disabled or removed while Require SSO is on (409). Turn Require SSO off first, or enable another provider. A disabled provider can still be saved and removed.
• Turning it off always works, so an organization whose members can't sign in can recover. Owners can still sign in with their password to do that, and the identity audit records it.
• Already on: organizations that have Require SSO on keep it.

• What a provider needs: OIDC, the issuer URL, client ID and client secret. SAML, the IdP entity ID, SSO URL and signing certificate; the metadata URL is optional.
• Saving: an enabled provider with a setting missing is refused, and the message names what is missing. You can still save it disabled while you set it up. A secret you leave out of an update keeps the stored one.
• Require SSO and the last provider: Require SSO turns on only with a complete, enabled provider. While it is on, the last complete provider can't be disabled or removed. An incomplete one can be.
• Already on: organizations that have Require SSO on with only an incomplete provider keep it. Complete the provider, or turn Require SSO off, which always works.

• Exchanges list when each call happened, whether you sent or received it, the partner, the deployment, whether the boundary allowed, redacted or blocked it, and its acknowledgement. While an acknowledgement is outstanding it shows how long is left, or that the deadline has passed. The partner's name is the one it publishes in its own key document; partners that have published none show a short ID.
• Export for a dispute opens a window for the exchanges you selected. You choose whether to reveal the content of each one where it is still held, see until when it is kept, and are told when readable content will be in the file. The export proves what was sent and acknowledged and can be checked offline with norcaster-verify.
• Your identity shows the date the current key document stops being valid, and warns in its last 30 days. Versions requested from the page are valid for a year. Requesting a new version, and approving, denying or cancelling one, each opens a window first. Approving says whether the version is registered on the log, is waiting for your Sync Agent, or failed and why.
• Who can act: owners and admins request versions and export evidence, and owners approve, deny or cancel. Other roles see the same information without those buttons. Before, everyone saw them and was refused when they tried.
• The page has three tabs, Exchanges, Your identity and Shared log, and opens on Your identity until a key document is registered.

• Require SSO can be turned on only with an enabled provider on a plan that includes SSO sign-in; otherwise the page says what is missing. Before it turns on, a window names the provider members will use and explains that owners can still sign in with their password for recovery, which is recorded in the identity audit. The last enabled provider can't be disabled or removed while Require SSO is on.
• Plan: SSO sign-in is part of the Enterprise plan. On other plans, the page says that providers, SCIM and group mapping can be set up, but members can't sign in through SSO until you upgrade.
• Setup values to copy into your identity provider: the OIDC redirect URI, the SAML entity ID and ACS URL, the SCIM base URL, and the sign-in link for members once a provider is enabled.
• Providers are set up and edited in their own window. An enabled provider needs its issuer, client ID and secret (OIDC) or its entity ID, SSO URL and signing certificate (SAML) before it saves. Choosing Owner or Admin as the default role for new SSO members shows a warning. A provider can be removed.
• SCIM: generating or rotating the token asks first, says that it turns SCIM on and that rotation stops the old token, then shows the new token once with a Copy button. The page shows when SCIM last synced.
• Group mapping shows roles by name and explains how a member's role is chosen: the most privileged role among their mapped groups, Viewer when none of their groups is mapped or the role is blocked for segregation of duties, and the provider's default role when there are no mappings.
• The page has Sign-in, Provisioning, Group mapping and Audit tabs, and the audit names each event and outcome in words.

• Members can be searched and filtered by role, with the number of members in each role. The MFA column shows whether each member has turned MFA on, and marks Off when your organization requires it. Members whose access end has passed read Access ended.
• The header counts members, open invitations, seats used on your plan and members with MFA. When every seat is in use, owners and admins see a notice.
• Member details show role, status, when they joined, scope, access end, MFA, identity and effective permissions, and owners can turn the blocked-message forwarding exception on or off there.
• Change role asks for the new role in its own window and warns when it grants control over policies, budgets and enforcement. Removing a member, revoking an invitation and revoking a member's API key each ask first.
• External Reviewer is no longer offered when changing a role. Before, changing someone to it left them with access to the whole organization and no end date. Invite reviewers from Reviewers, where you set both.
• Resending a reviewer's invitation whose access end had already passed now sets a new end date 30 days ahead; before, it resent the past date.
• Inviting a reviewer lists only your organization's deployments.
• The members CSV names its last column Added, which is what it holds; before, it was headed Last active.
• The audit log has its own tab, with the time of the last access change. Errors loading members, the audit log or API keys are shown instead of empty tables.
• The member details no longer say that MFA policy and login sessions are coming in a future release. MFA can be required under Settings, Security.

• Teams are listed beside the selected team's members. Each member shows their team role and their organization role, and someone who has left the organization is marked as no longer a member.
• Who can act: organization owners and admins create, edit and delete teams. They and a team's team admins add members and change team roles. Anyone can leave a team they are on.
• Add member offers only people who have accepted their invitation and whose access has not ended.
• Every action opens its own window first: new team, edit, delete, add member, change team role, remove from team and leave team. Creating a team makes you its team admin. Deleting a team or removing someone from it doesn't change anyone's organization role or access.
• Viewers, governance, leaders and external reviewers see that teams are visible to engineers, admins and owners. Before, they saw "No teams yet", whatever teams existed.
• Messages meant for developers, such as a hint to restart the API, no longer appear. The page uses the organization chosen in the sidebar instead of its own selector.

• Silence fix: after you silenced a rule or cleared a silence, the page forgot the rule's deployments, workflows, policies and comparison. If you then edited and saved the rule, it was saved that way and alerted on all of your deployments. The page now keeps the rule as it is. If you silenced and then edited a rule before this change, check that it still applies to the deployments you meant.
• Rules shows each rule's severity, whether it is on, off or silenced, and a summary such as "Policy violation · > 0.9 · 3 events in 15 min · Slack · 3 deployments". Send test and a menu with Edit, Silence, Turn off and Delete sit on each rule. Recent deliveries show whether each alert was delivered, queued, suppressed or undeliverable.
• Delete asks before it removes a rule. If turning a rule off or deleting it fails, the reason is shown on the rule; before, nothing happened.
• Delivery & security explains retries, shows how to check the signature on webhook deliveries, and previews the payload for each event. Rotating the signing secret asks first.

• Period fix: the start and end you pick are converted to UTC before they are sent, and the time zone is shown next to them. Bundles generated before this change covered a window shifted by your offset from UTC; check the period in a bundle's manifest if that matters for a review.
• Signed enforcement export: the button asked for CSV, which the signed export does not support, so every download failed. It now downloads the signed JSONL file it names, for its own period.
• Bundles lists each bundle with its framework, supplier requirement sets and customer case, format, status, number of deployments and manifest digest, which you can copy. Download and Verify sit on each ready bundle.
• Generate bundle asks for the period, framework, optional supplier requirement sets, customer case and deployments, then downloads the bundle when it is ready.
• Other exports holds the signed enforcement log and the register export with its recent history. Management review holds the review pack.
• The line naming append-only storage, hash chaining and Rekor was removed: it appeared for every organization, while anchoring to Rekor depends on your plan.

• One queue for deployment, organization and project changes, each labelled, with who proposed it and when. Changes that need a second reviewer, and organization or project changes made out of date by a later edit, are marked.
• What changes lists each setting with its current and proposed value; the full configuration is one click away. Organization and project changes also list the deployments they would alter and why each needs approval.
• Approve and Reject ask first and take an optional note that is recorded with your decision. An approval applies only the configuration you reviewed: if it has changed since, the approval is refused. A change made out of date can't be approved, and neither can your own change when it needs a second reviewer.
• Decided shows recently approved and rejected changes, who decided and their note.

• Legal owner now shows for each deployment, with the contact when you point at it. Before, the column was always empty, and a subprocessor count of 0 appeared even when subprocessors were recorded.
• Preview shows the system's purpose, classification and risk tier, the processing roles, each subprocessor with its role, regions and data categories, how requests are routed to the model provider, and the snapshot's note on what it is and is not. Download JSON saves the snapshot as generated.
• The table shows each deployment by name with its data classification and status, and a search finds deployments by name, model or ID. Sample deployments are marked and can't be exported.
• Norcaster's own subprocessors are linked from the page header.

• Filters and exports: the times you pick are converted to UTC before they are sent, for the list and for the spreadsheet (CSV) and JSONL exports, signed or not. An export downloaded with a From or To time before this change covered a window shifted by your offset from UTC; check its first and last record times if that matters for a review.
• Links to the last 24 hours or 7 days set From in your local time and leave To empty, so the window runs up to now. Before, they also set To to the moment the page opened. To sits under the advanced filters, so that limit was hidden, and decisions recorded after the page opened were left out when you changed a filter.
• A link with its own start or end time, such as start=2026-10-06T08:00:00Z, is shown in your time zone and sent back as the same moment. An end time opens the advanced filters, so its To is visible. A time the page cannot read is ignored.
• Reviewer access expiry was already sent in UTC and is unchanged.

• Drift fix: the run page read a field that is always empty, so the drift warning never showed. It now uses the drift check stored on the run when the suite has a baseline run: how far the pass rate fell, which items went from pass to fail, and what the suite allows.
• Scores: each score is shown as a percentage. The "Meets target" and "Below target" labels are gone because they used the Test console's targets rather than the suite's, so they could disagree with whether the item passed. Passed and failed are the suite's own verdict.
• Evidence on each run: the flow or deployment, the dataset version, whether that version was locked and its hash verified, whether the verdict was signed on the trace chain, and the external judge's residency and redaction.
• Items opens on the failed ones. Each item shows its input, output, expected answer, evaluator notes and a link to its trace.
• Suites show their setup and every run, marking the baseline and runs that drifted. If a run can't start, for example because of your plan or a stopped deployment, the reason is shown; when it finishes, the run opens.
• Compare two runs: pick a baseline and a candidate run on the same dataset. The comparison shows the pass-rate change and the items that went from pass to fail or back.
• Datasets: Lock and Add a version open in a window, and the lock note belongs to the version you lock.
• A run, suite, dataset or comparison that can't be found now says so instead of showing an empty page.

• When you save: creating a workflow, saving a new version or activating one returns 400 when an external model step's credential_ref is not the id of a credential stored with one of your organization's providers. The message names the step, and is the same whatever the id is.
• When a step runs: any other credential reads as not found. The step fails before calling its endpoint and is not retried.
• Provider ids: the workflow editor's stored-credential list fills in a provider's id, which external model steps have never accepted. Such a step used to save and then fail when it ran; it is now refused when you save.
• Running another organization's workflow (for example one from the workflow catalog) never uses the owning organization's credentials: a step that names one fails as above.

• Tabs: Active, Resolved, Closed and Concern reports, each with a count. The table shows severity, status, where the incident came from, the AI system and when it was opened.
• Open incident asks for what happened, the severity and the AI system by name, then takes you to the new incident.
• Each step (acknowledge, mark contained, resolve, close or reopen) is confirmed with an optional note for that step. Resolving asks for the root cause and whether it was a nonconformity with your AI management system.
• Before this incident can close lists what is missing, such as open corrective actions or ones still waiting for an effectiveness check, and Close stays unavailable until they are done.
• Corrective actions show their owner, due date and status, with overdue actions marked, and record how effectiveness was checked.
• Timeline names each event in plain words, such as "Corrective action done", and marks the ones sealed on the trace chain.

• On Norcaster Cloud: saving a policy config with contextual_policy.jev enabled returns 422 (or 400) from every route that saves or simulates policy config. A config saved earlier still runs its other policies; the Jev questions are recorded as not_configured with key_refused: "cloud", and nothing is sent. Switching the layer off (enabled: false) still saves.
• On self-hosted installs: api_key_env must start with TYPESAFE_ (the default is TYPESAFE_API_KEY). Any other name is refused when you save; a config saved earlier records key_refused: "api_key_env" and sends nothing.
• Eval suites are unchanged: the jev evaluator uses your organization's stored TypeSafe provider credential, not the host environment.

• Register export: Export register was unavailable to anyone who couldn't edit register fields, including the governance role and external reviewers, although both are allowed to export. It now follows the export permission. Each export is still recorded in the access audit.
• Loading fix: if one coverage or count request failed or returned something unexpected, the page said there were no deployments to map. Now the register loads first, and a note says when some coverage signals could not be loaded.
• Control coverage shows numbers: systems with gateway traffic, the share in enforce mode, redactions in the last 24 hours, documented high-risk deployments, audit bundle readiness and the last register export, each with a link to the records behind it.
• Register has one set of counts that match the table, a search and status filter, and removable chips when you arrive from a link filtered to high-risk deployments or systems without gateway traffic. Deployments are listed by purpose with the model underneath, and the next review shows as a date.
• Links from Evidence to filtered register views open the Register tab; links to a framework open the obligations map.
• The read-only note says what your role can do, such as recording attestations or exporting, and the export window closes with Escape.

• When you save: a URL naming a loopback, private, link-local or cluster-internal host (for example localhost, 10.0.0.5, 169.254.169.254, crm.internal or a bare service name), or one that is not http or https, is refused when you save a deployment, project or organization policy, a proposal, or a policy simulation. The message names the field. Layers that are switched off are not checked.
• When a call is made: each host is looked up and refused if it resolves to a non-public address, and Norcaster connects only to the address it checked. A refused NeMo call is recorded as not_reported. A refused tokenization call leaves [PAN_TOKEN_UNRESOLVED] in place of the card number. A refused Action Gateway call returns "action_gateway.upstream_url must be a public internet host".
• Existing configs that use a private host keep running their other policies; those calls are refused. Point them at a public endpoint.
• Norcaster's demo MCP servers (http://demo-mcp-server/sse, http://demo-mcp-commerce/sse) still work as Action Gateway upstreams.
• Self-hosted installs can still use private hosts.

• Items show a plain type and value, the reasoning and the quoted source text with the document's title. Accept, Reject and Edit sit on each item, with a running count of your decisions.
• Edit is offered only for custom rules, the only items with an edit form. Before, choosing it on a pack or budget item sent the item back with an empty rule added.
• Apply to lists deployments and projects by name instead of by ID.
• Preview and confirm shows the settings that change, asks you to acknowledge anything that weakens existing enforcement, and still asks for the target's ID before applying. The button says how many items will be applied.
• An error from loading, previewing or applying now appears once, next to the step it came from, with a title that says which one failed.
• Proposal pages now sit under Source documents in the sidebar and breadcrumb.

• Overdue entries: every save sent the stored next review date again, and a date in the past is refused. Saves now send only the fields you changed; a new review date still has to be in the future.
• Review date: the date picker could save a time several hours off, depending on your time zone. It now picks a day, and register dates show as dates.
• Risk tier: when the tier differs from the one the Annex III category implies, the page asks for an override reason before saving instead of showing an error from the server. Choosing a category fills in the tier it implies.
• Declared data categories can be entered under Scope and users. They count towards completeness and help suggest policy packs.
• Mark reviewed says the date the next review moves to and asks before recording. The review is added to the entry's history.
• History shows each change with readable field names, the old and new values, who made it and when, and marks changes that came from a review or a model change.
• The completion guide that opens after a deploy now closes with Escape, which skips it as before.

• Status reads Active, Invite sent, Invite link expired or Access ended. Access ends shows the date and how many days are left, marked when it is within 7 days, and the page header counts active reviewers, open invitations and access ending in the next 7 days.
• End access now removes a reviewer's access at once. Resend invitation sends a new link and the earlier one stops working. Invite again removes an ended reviewer's record and sends a new invitation. Each asks first and is recorded in the access audit log.
• Reviewers with the Viewer role, from before scoped reviewer access, are marked. Invite as External Reviewer replaces their organization-wide access with access limited to a scope and an end date; their Viewer access ends when you send it.
• Inviting a reviewer lists only your organization's deployments and projects. Before, the list could include deployments from other organizations or personal ones, and a reviewer limited to one of those got no access. Scope now shows the deployment or project by name, and the end time is shown with your time zone.
• The Invite reviewer button on an empty page now opens the invitation.

• View text shows the stored text with its kind, size, reference, date and SHA-256 hash.
• Upload a new version replaces a document for future proposals. The earlier version is marked superseded, and the change is recorded in the audit log.
• Add document offers Paste text, Upload a file (.txt, .md, .pdf or .docx) or From a URL. Text taken from a file or a page can be edited before you save it.
• Generate draft proposal works on the documents you select. When it finishes, the page says how many items were drafted and how many suggestions were left out for missing citations or invalid settings, with a link to review the proposal. If the drafting call is blocked on a deployment, the error links to that deployment's decision audit.
• Proposals lists each draft with its status, including drafts waiting in change approvals, the documents it came from and the model that drafted it.
• If your role can't add documents or generate proposals, those actions are hidden and a note says why, instead of failing with a permission error.

• When you save: an endpoint or server_url naming a loopback, private, link-local or cluster-internal host (for example localhost, 10.0.0.5, 169.254.169.254, crm.internal or a bare service name), or a URL that is not http or https, is refused with 400 when you create a workflow, save a new version or activate one. The message names the step and the field.
• When a step runs: each host is looked up and refused if it resolves to a non-public address, and Norcaster connects only to the address it checked. The step fails with "must be a public internet host" and is not retried. HTTP, webhook and external model steps don't follow redirects.
• Existing workflows that call a private host fail at that step on their next run. Point the step at a public endpoint.
• Self-hosted installs can still use private hosts.

• Queue: Action approvals shows "requested by agent ‹name›, owner ‹id›". GET /v1/mcp/approvals/pending adds requested_by_principal (agent id, key id, owner, name, status).
• Records: the requested, approved and rejected rows carry who wrote each one, and requested_by_principal names the agent behind the call, inside their chain entries. requested_by is unchanged: for an agent it is still the owner's user id.
• Who may approve: any other person with deploy access to the deployment. An agent's or a service-account key gets 403 on approve; the owner of the agent that asked gets 403; a call from an agent retired since gets 409 and can still be rejected.
• Not covered yet: workflow approvals and the forward-once approval of a blocked message.

• Run seal: service_account_id is added only when an agent's or service-account key made the run; user_id is then the agent's owner.
• Bundle change history: a bundle for the whole organization lists every agent's lifecycle rows; a narrower bundle lists those of the agents its decision records name. Each row has the agent's id, name and kind, who acted, and the bindings, scopes and key ids recorded at the time.

• Sessions shows each session's task, status, issues, events and errors, when it started and how long it ran. Select one to see its detected issues, such as a loop or repeated errors, and its event timeline.
• Organization view is offered to admins of the organization selected in the sidebar. A session another member ran can be seen in the list, but only that member can open its events; the panel now says so instead of loading without end. Switching organization checks admin access again.
• Set up the hook has four steps. Download norcaster_hook.py from the page; before, it said to copy the script from the Norcaster repository. Create a key, add it to your shell profile, then register the hook in ~/.claude/settings.json.
• Your API key goes in your shell profile instead of the hook command in Claude Code's settings file. Hooks you set up earlier with the key in the command keep working.

• API: GET /orgs, GET /orgs/{id} and PATCH /orgs/{id} no longer include org_settings.sso.client_secret. They return org_settings.sso.has_client_secret (true or false) instead. A PATCH that leaves out client_secret, or sends it empty, keeps the stored secret.
• Existing secrets are encrypted the next time the organization's settings are saved, and by a one-time migration after the release.
• Recommended: if your organization used Basic OIDC sign-in before this change, rotate the client secret at your identity provider and save the new one here.
• SSO & SCIM identity providers are unchanged.

• Run summary lists the question, the tool the workflow called, what was redacted, whether redaction ran before the model, what reached the model or was checked at its boundary, and how long each step took. Download it as JSON or HTML. Both files include the execution and run IDs, so you can find the signed record.
• Tool called shows the tool your workflow actually called. Before, it showed search_tickets whenever the step did not report a tool name.
• Your question goes into the workflow's own text input. A workflow whose input field has another name, such as ticket_text, now runs instead of failing.
• No model step: the page now warns when the workflow you chose has no model step, and links to its editor.
• Choose a deployment by name, or let each step use its own.

• New sets: DORA subcontracting (Delegated Regulation (EU) 2025/532), GDPR for the AI supplier as processor, AMLR Art. 76(5) automated AML decisions, Consumer Credit Directive Art. 18 automated creditworthiness assessment (Sweden: Konsumentkreditlag (2026:1011)), and EU AI Act credit scoring (Annex III, point 5(b), as amended by Regulation (EU) 2026/1744). Every reference was checked against the official text.
• Several sets per bundle: supplier_requirement_sets on POST /orgs/{org_id}/audit-bundles takes 1 to 6 set ids. Each set gets its own section entry, CSV file and PDF page, in request order. One set, through either field, gives the same bundle as before.
• Quick picks on Audit bundles: AI supplier to an EU financial entity; + AML decisions; + consumer credit decisions. The history row names every set in a bundle.

• Deployment: pick the deployment by name. Before, the page used the first of your deployments without saying so. A link with ?deployment_id= selects that deployment.
• API format: OpenAI-compatible or Anthropic-compatible, each showing whether provider credentials are configured, with a link to Providers when they are not.
• API key: if you have no active key, Create an API key makes one with the same name and permissions as before ("Gateway setup": send runs, read deployments). Copy it straight away, because it is not shown again. If you already have keys, the page says how many and links to API keys.
• Test request: the result appears under the button, with the verdict, the path it went through, a copyable run ID and Open trace. Test with POST /run instead is still there when provider credentials are missing or the gateway call fails.

• What changed: anyone can install a public GitHub App, and a repository's name can change hands. A push used to redeploy every deployment tracking that repository name, whichever installation sent it. Now the installation must be one you, or someone active in your organization, connected through Connect GitHub, and that GitHub verified. Updates to the gateway pull requests Discovery opened follow the same rule.
• What you need to do: usually nothing. If you connected GitHub only through the older OAuth connection, or a teammate who has since left connected it, a push may no longer redeploy. Click Connect GitHub once on the deploy page and pick the installation that covers the repository.
• Without the App (self-hosted, with a repository webhook and your own secret), nothing changes.

• When you save: a web source URL, an S3 endpoint, or a Qdrant or Weaviate url / host that is not http(s), or names a loopback, private, link-local or cluster-internal host (for example localhost, 10.0.0.5, 169.254.169.254 or a bare service name), is refused with 400.
• When Norcaster connects: each host is looked up and refused if it resolves to a non-public address. Web sources connect only to the address that was checked, follow at most 5 redirects, and check every redirect. S3 sources no longer follow redirects from their endpoint, so use your bucket's regional endpoint.
• Existing sources and indexes that point at a private host fail at their next sync or search, with a message naming the field. Change the URL to a public host to fix them.
• Self-hosted installs can still use private hosts.

• Upload sources: files always go to, and are read from, the source's own folder. A bucket, path or object_name in the source config that points anywhere else is refused with 400.
• S3 sources: bucket, endpoint, access_key and secret_key are required. A source saved without its own endpoint and keys can't be created, and fails at its next sync with a message saying what is missing.
• Secrets: reads return has_secret_key and has_api_key instead of the S3 secret key and the vector index API key. The webhook secret is shown to Owners and Admins only, so only they see Copy webhook URL. To change other settings, send the config back without the secret and the stored one is kept. If you change the endpoint, access key or URL, send the secret again.
• Templates saved from a workflow no longer copy these secrets or an upload source's folder.
• Pinecone: an env: key reference works on self-hosted installs only.
• Webhook sources created with sync mode Webhook now get their secret when they are created, not only when the sync mode is changed later.
• Recommended: rotate S3 keys, vector database keys and webhook secrets saved in knowledge sources and vector indexes.

• Knowledge bases lists each base with its number of sources and created date, Ask a question, and a menu with Add source, Copy ID and Copy retrieval node config. If a chunking profile, embedding profile or vector index is missing, a panel says which one and lets you add it.
• Sources show Synced, Not synced, Syncing or Sync failed, how many documents they hold and when they last synced. Sync now starts a sync. The menu has Upload files, Ingestion jobs and, for webhook sources, Copy webhook URL. Messages about a sync or an upload appear under that source.
• Use sample knowledge base names the organization it adds to: the one you joined first, which may not be the one selected in the sidebar. Afterwards it says whether the knowledge base was added, added to that other organization, or not added because sample retrieval isn't available on the server.
• Forms: a web source needs its page URL. Before, an empty one became example.com. The forms no longer submit an S3 source or a Pinecone, Weaviate or Qdrant index, because they don't collect the bucket, credentials or connection settings these need. Before, the index was refused and the S3 source could never sync. The upload picker no longer offers PDF, which is not parsed yet.
• Windows close with Escape, the close button or a click outside. A document opened from an answer closes on its own and leaves the answer open.

• Totals at the top: the exact number of runs in the range, the slowest p95 and which deployment it is, the error rate and the share blocked by policy across deployments, and the estimated cost.
• By deployment lists every deployment that handled requests in the range, with a link to it. A note says where each figure comes from.
• Estimated cost adds up the daily cost estimates from the first day of the range, in your runs' currency. Not every request path records a cost estimate yet, so the total can be lower than your provider's bill.
• Where the time goes shows the average time a request spends in the model, retrieval, policy checks and the queue.
• Time range: last hour, 24 hours or 7 days.

• When it falls back: for example on a self-hosted server without CREDENTIALS_ENCRYPTION_KEY. The page tells you that the fallback was used.
• When setup fails: for example when object storage is unavailable. You see "We could not complete onboarding setup right now. Try again, or continue with Demo Project while we finish provisioning." instead of "Internal server error".
• API: POST /onboarding/provision responses are unchanged, and these cases now return them.

• Send X-Norcaster-Case-Ref: <case id> on /run, the OpenAI- and Anthropic-compatible gateway and each MCP tool call. Use a pseudonymous case id of 1 to 64 letters, digits, ., _, : or -, never a name, email or national ID; values that look like a personal identifier are refused with a 400 that never repeats the value.
• Approvals keep the case: an approver resolving a paused tool call sends no header, and the approval still carries the case of the call it approves.
• Export with "case_ref" on POST /orgs/{org_id}/audit-bundles, or the new Customer case field on Audit bundles. Decision records, agent actions, redaction evidence and provider activity hold only that case; the manifest and the PDF cover name it. Bundles without it are unchanged.
• Not covered yet: queued worker jobs, Slack and RAG runs, hybrid data planes and portal test-console runs.

• When you save: a base_url naming a loopback, private, link-local or cluster-internal host (for example localhost, 10.0.0.5, 169.254.169.254 or a bare service name) is refused with 400 on create and update, and with 422 when set on a credential.
• When Norcaster connects: each host is looked up and refused if it resolves to a non-public address, and Norcaster connects only to the address it checked. Redirects are followed only to public hosts. This covers requests, credential checks, model sync, and the /v1/messages and /v1/responses pass-throughs.
• Existing providers with a private base URL fail at their next request. Point them at a public endpoint, or remove the custom base URL to use the vendor's default.
• Self-hosted installs can still use private hosts.

• When you save: a NIM or Hugging Face base_url naming a loopback, private, link-local or cluster-internal host (for example localhost, 10.0.0.5, 169.254.169.254 or a bare service name such as nim-llama) is refused with 400, whether or not your organization has a data plane.
• When Norcaster connects: each host is looked up and refused if it resolves to a non-public address, and Norcaster connects only to the address it checked. Redirects from a Hugging Face endpoint are followed only to public hosts.
• Existing providers that point at a private host fail at their next request, model sync or validation. Point them at a public endpoint to fix them.
• Self-hosted installs can still use private hosts.

• Row menu (⋯): Update or add credential, Rotate credential (once a credential is set) and Details and models. Click a provider's name to open its details too.
• Add provider lists the supported providers at the top of the window, so the page itself starts with your list.
• Windows close with Escape, the close button or a click outside (not while saving), and move the keyboard focus into the window. When you update a credential from a provider's details, Escape closes only the credential window.
• Details has Update credential, Test connection and Sync models. Models show Approved, Not reviewed or Revoked.

• Who is refused: Viewers, Governance, Leader and External Reviewer members, and members whose access has expired, for example after SCIM deprovisioning. They see a message that says who can set it up, and nothing is created.
• Organizations that require MFA: Owners and Admins need two-factor authentication set up, as for other organization settings.
• Which organization: unchanged. The sample workspace goes into the organization you joined first.
• API: POST /onboarding/provision returns 403 with a detail message in these cases. The response to everyone else is unchanged.

• Removed: the always-disabled Reset to Warn and Disable budgets actions in Danger zone, PagerDuty "coming soon" under Integrations, and a few notes that were never meant for customers.
• General shows the organization ID (with a copy button), created date and primary owner as details rather than form fields.
• Security: the checklist's Set up links now open SSO & SCIM and Logging and exports instead of reloading Settings. The OIDC section is labelled Basic OIDC sign-in and points to SSO & SCIM for SAML, identity providers and SCIM. A sign-in URL that did not exist is no longer shown.
• Danger zone lists emergency stop, transfer ownership, your personal data and, last, delete organization. Delete still asks you to type the organization's name.
• On a phone, the section list becomes a row you can scroll, starting at the section you are on.

• One set per page run: a set's heading, pack sentences and table start together on a new page, and Appendix A starts on its own portrait page after the last set.

• API: GET /orgs, GET /orgs/{id} and PATCH /orgs/{id} no longer include org_settings.alerts.webhook_signing_secret. They return org_settings.alerts.has_webhook_signing_secret (true or false) instead. GET /alerts/webhook-signing-secret is unchanged.
• Saving organization settings keeps the stored secret, even when the request leaves it out or sends "alerts": null. Sending a different secret there returns 400; use Rotate secret instead, which is audited.
• Recommended: rotate the secret under Alerts → Webhook security once your receivers are ready to take the new value.

• Header: the workflow's status, version and ID, and a summary such as "5 steps · retrieval · cites sources · version 3 is active". Activate appears only when the latest version is not active. The menu has Executions, showing this workflow's only, and Save as template.
• Activate asks before it switches versions and names the version it archives. When Norcaster refuses, for example because a step has no deployment, the reason is shown. Before, nothing was shown and the version stayed as it was.
• Save as template asks for the deployment the template uses by default. Before, Save stayed disabled until a deployment was chosen in another part of the page.
• Save as new version includes a step's configuration edit even if you go straight to Save without clicking outside the field first.
• Versions lists each version with its status and what changed from the previous one. Compare with opens the side-by-side view.
• Use in your app starts with the endpoint and the code samples. The FastAPI and .NET samples now send the workflow's own example input. The terms glossary is collapsed.
• Graph: steps are laid out from top to bottom, matching how they connect.

• Workflows shows each workflow's organization and steps, for example input → retrieval → model → output. Each row has Open, or Finish setup for a draft, and a menu with Executions and Duplicate. Executions opens the executions of that workflow only.
• Duplicate copies the workflow's input and output fields and its description. Before, the copy got a fixed question and answer format that its own steps might not use. It now confirms the copy with a link to open it.
• Executions shows the workflow's name and version, the step each execution is on, and its status: Waiting for approval, Running, Completed, Failed, Cancelled or Stopped with the reason. A link from a workflow's menu shows only that workflow's executions, with a chip that clears the filter.
• Approvals lists the approvals waiting, with when they were requested, the step and any note. Review opens the execution, where you approve or reject it. Before, the inbox listed them without a way to open them.
• Tools is the new name for Tools registry.

• Light theme: the heading, the AI setup to test, Try a different example and Your message labels, the sample buttons and the message box are now readable.
• Results: the result card is now green when a message is allowed, amber when it is flagged and red when it is blocked, with readable text in both themes. The same applies to the What happened next, What Norcaster noticed and How this run worked panels, and to the plan-limit and error messages.
• Dark theme: the small hints under the samples and the message box were slightly too faint for WCAG AA. They are now brighter.
• Onboarding: the Send a test message step in guided setup uses the same console, so it gets the same fix.

• Buttons: outline and secondary buttons show an accent border and a light wash on hover, and the keyboard focus ring uses the accent colour. The green Activate button in the workflow editor and the red Yes, clear draft button in Action gateway settings keep their own colour on hover.
• Access and Budget: Invited, expiry and role badges (Owner, Governance, External reviewer) on the Access page, and the Warn and Block badges on Budget, are tinted. The ring around a forecast that exceeds a cap is amber instead of blue.
• Test console and Analyze: the progress bar in "After your first test run" now fills as steps complete, and a completed step shows as a white card with a blue outline. The "No model node" note in Analyze, violation-code chips and their suggested fixes show their colours.
• Public site: Boundary "How it works" step numbers are tinted and joined by a line, status pills on EU AI Act and Integrations have coloured outlines, and pricing highlights, docs cards and table rows have their intended borders and hover shades. The sign-in and sign-up forms have a little more space above and below on wider screens.

• Send button: a deeper blue, so the white label meets AA on dark and light pages.
• Light theme: the Protected badge is readable, and BLOCKED, ALLOWED and FLAGGED results each have their own tint.
• Dark theme: the "Request stopped" note, the Type a message… placeholder and Powered by Norcaster are slightly lighter.

• Workflows: the labels on the cURL, FastAPI, .NET and Node.js examples under Developer integration on a workflow's page are readable in the light theme.
• Workflows: the line under each label and the Copy button's outline are a soft rule on the navy background instead of a bright one.
• Dark theme: unchanged.

• Overview: the Copy button in the Integration snippet panel (cURL, Python and Node examples) is readable in the light theme, including on hover.
• Workflows: the Copy buttons under Developer integration on a workflow's page are readable in the light theme.
• Dark theme: these buttons are a little softer and use the same hover highlight as the Test console's code example.

• Where you will notice it: status badges, alert banners and summary cards now have green, amber, red or blue borders and light washes. The operator View as control has an amber outline, and the selected step in Discovery setup is tinted.
• Coloured text: some warning notes and the block-rate figure now show in amber, as designed. Before, they showed in the normal text colour. These include policy rule warnings, "Upgrade plan to unlock" and email delivery notes.
• Step numbers: the current step in the onboarding plan and the sidebar's Resume setup shortcut now show a solid blue number, so they stay readable on the tinted background.
• Hover states: a few buttons, including the delete and emergency-stop buttons, now show their intended hover tint.

• Run details: the Enforcement outcome card, the Execution timeline note and Verdicts on this run have a blue outline. The note that a request was allowed while output quality fell short has an amber outline.
• Workflows: overview tiles get a blue outline on hover. On the workflow graph, rerank, agent, policy, input/output, redaction and approval steps show their own border colour.
• Policies: the note that a deployment is linked to a project has a light blue wash. The Immutable production mode note has a light amber wash, and its text is now readable in the light theme.
• Budget: a forecast that exceeds a cap now sits on an amber background, matching the green background of an on-track forecast, and its label is easier to read.
• Evidence: the Allowed badge in the enforcement log is a soft green pill. Knowledge's sample-retrieval note has a blue outline.

• Fixed: the allowed and warned segments of the 7-day enforcement chart, and the fill of the usage meter, did not render; only the blocked segment showed.
• Deployments are listed busiest first, with their mode, in a wider table that no longer cuts off its requests and block-rate columns.
• Recent activity labels a redacted request "Redacted"; it was shown as "Allowed".
• Removed: the Quick actions, What's next and Quick links panels, the Risk & enforcement block and the leadership tile grid. Their links are in the sidebar, the Help menu and the account menu. Their figures are in the tiles and posture summary, except the combined "open signals" count and the separate "% allowed" figure, which the block rate and risk signals replace.
• New workspaces see one getting-started panel: see the demo, load sample data or connect your gateway.
• Posture comes from runtime telemetry; it does not assert legal compliance.

• Evidence: Blocked is dark red on a light red pill and Warned is amber on a light amber pill, like Allowed, which is green on a light green pill.
• Redacted has a readable pill too. Its purple outline and the purple dot beside the row stay, so redacted decisions still stand out from warnings.
• Deployments: a deployment's Decision audit tab uses the same log, so it gets the same badges in both themes.

• Overview shows the test request, a Runtime controls card (applied policy packs and available updates, guarantees, budget limits, change approval) and a Details card (project, data classification, lifecycle stage, legal owner, revisions, commit). Rows you can change open the tab where you change them.
• Settings holds the registry metadata with the legal owner and sub-processors, the project, the provider binding, the advanced config JSON and a Danger zone with Delete deployment. Delete is no longer in the page header.
• Policy packs are on the Policies tab, as the documentation describes; they were on Overview. The Slack channel binding is on the Connect tab.
• AI register on Overview lists the fields that are recorded and how many are not, with a link to complete them.
• Tabs read Overview, Connect, Contract, Policies, Action gateway, Budget, Decision audit and Settings. Existing links to a tab, including ?tab=Audit, still open it.

• Contract lists the fields of the live contract, with their type, whether they are required and their constraints. Before, the table stayed empty until you chose Edit contract. The repeated version and mode tiles and an outdated note about permissions are gone.
• Budget shows one Budget controls panel: whether controls are active, and a table with each control's status, limit, what happens on a breach and what it protects against. Recent budget events shows when the last event happened.
• Policies lists the policy packs by group, with Recommended, Applied and Update available badges. The Runtime policy form uses sentence-case labels.
• Action gateway opens with a shorter header that shows whether the policy is active and the gateway is configured.
• Decision audit uses sentence-case filter labels and badges, here and on the Evidence page. When there are no decisions, it suggests sending a request from the Test console.
• Links on policy change approvals, policy proposals, source documents, regulated change control and the governing configuration panel were dark navy, which is hard to read on the dark theme. They now use the link colour.

• Status tabs show only the statuses your deployments have, with a count each. You now filter by one status at a time.
• Governance gaps shows how many deployments lack a policy, a budget or alert rules, and lists just those when switched on. A missing one shows as an amber None that opens the place to set it.
• Columns: Status shows a build only while it is running or has failed. Updated shows how long ago ("2h ago"), with the exact time on hover. Provider appears in windows 1440px wide or wider and is always available as a filter. On small screens the table scrolls inside its panel.
• Row menu (⋯): View details, Open in Test console, View traces and Copy deployment ID, usable with the keyboard. It replaces the "Playground" link on each row.
• Sorting by name follows the title shown in the row, and sorting by status puts failed deployments first.

• What it reads: Deployments, StatefulSets, DaemonSets, Jobs and CronJobs, with your own kubectl and its current context. For each env var named like an AI key, it notes the Secret or ConfigMap it reads, or that the value is written into the spec. It needs to list those workloads, not Secrets.
• What is sent: the names of the Secrets or ConfigMaps, their keys, the env vars and the workloads, plus a count of everything else. Values are dropped on the collector, and Norcaster refuses a push that contains one.
• Where it shows:

- Review ties each Secret to its app through the workloads that read it.

- The key checklist says where each old key is stored.

- A key in a ConfigMap or written into a spec is flagged, so it can be moved into a Secret.

• Try it first: norcaster-discover sync --kubernetes --dry-run writes k8s-secret-refs.json without sending anything.

• How to turn it on: tick Also read secret names when you connect an AWS account, or choose Also read secret names… on one already connected. The role gets one more statement, with secretsmanager:ListSecrets and ssm:DescribeParameters. Neither returns a value. Until the stack is updated, the read says the names are not granted, and everything else is read as before.
• What is kept: only names that look like AI keys, such as OPENAI_API_KEY or prod/payments/anthropic-key. With each name: its store, region, tags, dates and the day it was last read. Other names are only counted.
• What is never kept: values, descriptions, other names, or who changed a parameter.
• Where it shows:

- Review ties each secret to the app it probably belongs to: a word in common, or the env var it is named after.

- The key checklist under Close the bypass says where each provider's old keys are stored, so you rotate them in the right place.

- A secret name is not traffic, so it never creates a deployment and never counts as proof that a bypass was closed.

• Azure Key Vault, Google Secret Manager and Kubernetes follow.

• How to turn it on: tick Also read Key Vault secret names when you connect Azure, or choose Also read secret names… on an identity already connected. Then deploy the template again in each subscription. The role gains vaults/read and the secrets/readMetadata data action, which reads a secret's name, dates and tags, never its value.
• Vaults Norcaster can't read are listed by name, and the others are read anyway:

- a vault that uses access policies instead of Azure RBAC needs the identity added with List on secrets; the setup shows the command;

- a vault behind network rules refuses Norcaster's address.

• What is kept: only names that look like AI keys, such as openai-api-key or payments-claude-key, with the vault, subscription, tags and dates. Other names are only counted. Because Key Vault names can't contain underscores, openai-api-key is matched to an app's OPENAI_API_KEY.
• Where it shows: as for AWS. Review ties each secret to the app it probably belongs to, and the key checklist says where each old key is stored.

• How to turn it on: tick Also read Secret Manager secret names when you connect Google Cloud, or choose Also read secret names… on projects already connected. Then run the gcloud command the setup shows in each project. The role gains secretmanager.secrets.list, which lists names, dates and labels. Reading a value would need versions.access, which Norcaster never asks for.
• Projects Norcaster can't read are listed by name, and the others are read anyway: one without the permission, or one where the Secret Manager API is not enabled.
• What is kept: only names that look like AI keys, with the project, labels and creation date. Other names are only counted. Annotations and values are never kept.
• Where it shows: as for AWS and Azure. Review ties each secret to the app it probably belongs to, and the key checklist says where each old key is stored.

• Data processing agreement: View / print template and Current subprocessors now show light text on the navy page, with a subtle highlight on hover.
• Test console: the Recommended badge on the next step now shows dark text on cyan in the dark theme. In the light theme it keeps white text on blue.

• Runs: the getting-started steps appear only when you have no suites or runs yet. Example runs are labelled. Links to the old runs page open this view.
• Suites: New suite opens the form with your active organization already chosen. A suite's page shows its name in the top bar and has a Run suite now button.
• Datasets shows each dataset once, at its latest version, with its organization. New dataset opens a short form with an organization list.
• Compare runs sits under the same Evals tabs.
• Buttons and error messages on these pages are readable in both themes.

• Deployment is one choice: All deployments, or a deployment by name. It replaces the "Audit scope" select and the deployment picker under advanced filters, which listed model IDs. On a deployment's own page it appears only when there is more than one option.
• Filters read From, Decision, Event kind, Policy pack or rule and Request ID. Advanced filters add a labelled To date, trace chain status, contract version and policy version.
• Entries show the deployment and its policy version ("Customer support assistant · Policy v12") and no longer show NO_CODE when a decision has no violation code.
• Links that filter by rule now show that rule in the filter, including rules outside the built-in list.
• The Filter reference box, which listed stored field names, is gone.

• Runs and Observability: section and KPI labels such as Success rate, Lineage and Verdicts on this run, run IDs, timestamps and empty states such as No quality checks were linked to this run meet WCAG AA in the light theme.
• Grey status badges such as Pending data, Build queued and Disabled meet AA in both themes. In the dark theme they were just below it.
• Search boxes: placeholder text in the runs, workflows and dashboard search boxes and in New deployment is easier to read.
• Test console: the steps that unlock after your first run are no longer faded as a whole. Only their icon is dimmed, so the Run a prompt first hint is readable.
• Dark theme: these labels are slightly brighter, matching the other helper text.

• Light theme: the panel, its heading and description, the Try these: label and the demo prompt buttons now match the rest of guided setup. The "not ready yet" notices are amber text that meets WCAG AA.
• Dark theme: the panel looks as before.
• Chat widget: the embedded chat keeps its own dark look, the same default your customers see.
• Clean-up: the old Boundary overview page has redirected to Policies since June. Its unused code has been removed, and links to it still open Policies.

This is the older /embed/v1.js script, configured with data-deployment and data-api-key on the script tag.

• Send button: a deeper blue, so the white label meets AA.
• Type a message… placeholder and Powered by Norcaster: slightly lighter.

• Test console: the descriptions in the After your first test run panel now meet WCAG AA contrast on the page background.
• Governance and marketing pages: small grey labels, hints and captions on the light grey page background and in light grey panels now meet WCAG AA contrast.
• Everywhere in the light theme: helper text keeps its place between the main text and the faintest labels, so headings, body text and hints still read as separate levels.

• List: search and labelled filters for mode and sort order. A policy is named after its deployment unless it has a saved display name. The page status reads, for example, "8 policies · 8 active · Mixed modes".
• Tabs: Rules opens first. The Overview tab is gone because its details are now in the summary above the tabs.
• Simulate: an allowed result now has a green frame, and the limited-simulation note and highlighted detections are readable in the light theme.
• Activity lists decisions with Allowed, Blocked, Warned and Redacted badges and a link to the trace or the decision.
• Changes from template, shown on policy proposals and when creating a policy, is readable in the light theme.

• Test console: Start onboarding (shown when no deployment is connected) is now readable in the light theme. Run sample request is now readable in the dark theme.
• Quick Start: Continue to safety profile, Continue to test request, Prepare & run sample and Retry sample request are now readable in the light theme, including on hover.
• Onboarding paths: the button on the Quick Start card no longer turns almost white on hover, and matches the other primary buttons on the page.

• Overview: Redacted in Recent activity is amber.
• Evidence and Decision audit: the Redacted badge is amber. Its purple outline and the purple dot beside the row stay, so redacted decisions still stand out from warnings.
• Policy packs: in a pack's contents and under Test this pack, the Redact action is amber, like Flag.
• Runs: Allowed with redaction in a run's Verdicts and summary was already amber and is unchanged.

• Run page: the panel at the top of the Summary tab under Traces & runs now shows all four verdicts.
• Workflow executions: the same panel loads on an execution's page when the execution belongs to a run.
• Score this run: after you score a run against a reference, the panel refreshes with the new quality check.

• Getting started shows the four first-session steps (ready, test run, trace, quality) and a link to connect your application. It disappears when all four are done. The flow diagram and the "After your first test run" panel are no longer on this page.
• No active flow: the console lists your deployments (up to 20) with their status and a Test button. With no deployments, it points you to onboarding, templates or New deployment.
• Testing a deployment in the light theme no longer shows dark boxes around the deployment details and the previous runs. The request box, the decision path and the results use larger text, and the button reads Send request. The same box is the test request on a deployment's Overview tab.
• Previous runs show the request that was sent. Before, a run could show whatever was in the editor when you sent the next one.
• Labels read "Test console" instead of "Playground", and the result labels are in sentence case.

• Boundary sandbox: on the result card, the icon box and the Production rules tag now have a faint red, amber or green outline that matches the card, instead of a bright grey one.
• Action gateway: in Preview a policy decision, the latency tag (for example 4 ms) has an outline in the decision's colour, in light and dark themes.

• Blocked asks for policy-blocked runs across all pages, using the same rule as the Policy blocks count. Before, it filtered only the 50 runs already loaded and could show none.
• Latency shows a dash for a run with no recorded latency, such as one still running, instead of "0 ms". The average latency tile says it covers the runs on this page.
• Run pages show the top bar Observe › Traces & runs › Run, with the deployment's name, the model, the start time and a copyable run ID under the title, and a View deployment button.
• Tabs on a run read Overview, Timeline, Request and response, Policy, Evidence and Raw JSON. The selected tab stays in the link, and existing links with ?tab=timeline open the Timeline tab.
• Details use labels such as Request ID, Started and Organization ID instead of field names, and the timeline's connecting line is visible in the light theme.

• Collapse: use Collapse at the bottom of the sidebar; the arrow icon in the same place expands it again. On phones the menu always opens at full width.
• Descriptions: the short description under each page name now appears when you hover over it, and still appears in ⌘K search.
• Collapsed sections still show the page you are on, with a count of the pages they hide.
• Names: a few pages now use sentence case: API keys, Test console, Latency & cost, Audit bundles, Data processing and Team & roles. Addresses and permissions are unchanged.
• Search: the ⌘K search dialog now opens across the whole window; before, it was squeezed into the sidebar.
• Removed: the greyed-out Templates entry, which linked nowhere, is no longer listed.

• Help menu (question-mark icon): Documentation, Plans & pricing, the Setup guide when it applies, What's new and Contact support. These links were in the sidebar's Help & docs section, which is removed; they are still in ⌘K search.
• Account menu (your initials): Organization settings appears only if you can manage them. Sign out is in this menu now, not a separate button.
• Appearance applies to console pages. Evidence, register and integrity pages always use the light theme; the menu says so when you are on one.
• Still in the bar: "Resume onboarding" while setup is unfinished, and the "View as" preview for platform operators. While a preview is on, the account menu also shows your actual role.
• Keyboard: both menus open with Enter or the down arrow, move with the arrow keys, and close with Escape.

• How access works: the role trusts Norcaster's own identity provider, and only for your organization. For each read, Norcaster gets a short-lived token, exchanges it with AWS for fifteen-minute credentials, and then discards them. Delete the stack to end access.
• Test and connect checks the role, its account and one Bedrock read before anything is saved. A role AWS refuses, or one in another account, is not stored.
• What is kept per resource: its name, id or ARN, tags, models, region, its 30-day call count, and the names of the roles that called it recently. IAM user names, session names, IP addresses and request content are not kept.
• Linking to your apps: Review suggests which app a resource probably belongs to, from its name, tags and calling roles.
• Closing a bypass: a closed resource with no calls since reads as verified quiet, evidenced by the next read. One still called reads as still seen.
• Refreshed once a day, and when you press Refresh.
• Not yet: Azure and Google Cloud accounts, and counting Bedrock calls in coverage reconciliation (Bedrock stays attested there for now).

• How access works: the identity trusts Norcaster's own identity provider, and only for your organization. For each read, Norcaster gets a short-lived token, exchanges it with Microsoft Entra ID for an Azure Resource Manager token, and then discards it. Remove the role assignment to end access.
• Least privilege: the role can list accounts, deployments and their request metrics. It can't read keys, call a model or change anything.
• Test and connect signs in and lists the AI accounts in the first subscription before anything is saved. If Entra refuses the identity, nothing is stored and the message says what to fix.
• More subscriptions: deploy the same template in another subscription with the first identity's principal ID. Norcaster reads up to ten subscriptions per connection.
• What is kept per deployment: its name, account, region, model and version, tags, its 30-day request count, and whether its account accepts API keys. Deployment creators' names are not kept.
• Linking to your apps: Review suggests which app a deployment probably belongs to, from its name, account and tags.
• Closing a bypass: turning off key auth on the account is usually how. A closed deployment with no requests since then reads as verified quiet, evidenced by the next read. One still called reads as still seen.
• Refreshed once a day, and when you press Refresh.
• Not yet: who calls each deployment (that needs its diagnostic logs), Google Cloud, and counting Azure OpenAI requests in coverage reconciliation (it stays attested there for now).

• One command: uvx norcaster-discover connect <code> && uvx norcaster-discover sync --repo . The code works once, for 15 minutes.
• A push-only key: it can add systems and log counts to your organization and cannot read anything back, not even what it pushed. It belongs to a service account named after the collector, and stops working if the person who paired it leaves the organization.
• What leaves your machine: the same names, counts, environment variable names and AI provider hosts as an inventory upload. The files that were pushed are kept next to your code for review, and --dry-run writes them without sending anything.
• Listed with your sources: each collector shows where it runs, its scanner version and its last push. Removing it revokes its key; the systems it pushed stay.
• In CI: connect <code> --print-key gives a key for a secret, and the norcaster/discover GitHub Action runs the scan on a schedule.
• Optional pull requests: sync --open-prs opens one pull request per system with your own git and gh, on a norcaster/<system> branch. Nothing is force-pushed or merged.

• Read-only, one repository at a time: each scan uses a token limited to that repository and to reading its contents. Norcaster never writes to your repositories in this step.
• What is kept: system names, providers, models, call counts, environment variable names and AI provider hosts, plus per scan the repository, commit and counts. No code, file paths or file content, in the database or the logs.
• Rescans: on a push to the default branch, daily, and when you press Scan now. A commit already scanned is not scanned again.
• Safe by construction: only the files the scanner reads are extracted, with no links or paths outside its own temporary folder, and with size limits. Nothing in the repository is run.
• Connecting needs proof: GitHub confirms that the person connecting can access the installation, as for deployments now.
• Not yet: pull requests that make the gateway change (next), and GitLab or Azure DevOps.

• How access works: for each read, Norcaster exchanges a short-lived token from its own identity provider at Google for a federated token, then discards it. The role is bound to your organization's identity only. Remove the role bindings to end access.
• Least privilege: the role can see the project, list Vertex AI endpoints and read request counts. It can't call a model or change anything.
• Already using Vertex through Norcaster? The pool provider you created for it can be reused.
• Test and connect reads every project you name before anything is saved. If Google refuses, nothing is stored and the message says what to fix.
• What is kept per model or endpoint: its name, project, region, labels, deployed models and 30-day request count.
• Linking to your apps: Review suggests which app a model or endpoint probably belongs to, from its name and labels.
• Closing a bypass: a closed model or endpoint with no requests since then reads as verified quiet, evidenced by the next read. One still called reads as still seen.
• Refreshed once a day, and when you press Refresh.
• Not yet: who calls each model (that needs Cloud Audit Logs), and counting Vertex requests in coverage reconciliation (it stays attested there for now).

• What is kept per key: its name and id, the last four characters of the provider's own hint, its project or workspace, when it was created and last used, and how much it was used (requests for OpenAI, tokens for Anthropic). Never the key itself, and no user names or emails.
• Not asked twice: if a provider in your organization already stores an admin key as its usage key, you can use that one.
• Norcaster's own keys are left out of the list: their traffic already goes through Norcaster.
• Rotating keys: the key checklist lists each provider's direct keys as still used, unused for a number of days, or removed. Closing a key's bypass means revoking it at the provider; the next read shows whether it was still used or is gone.
• Refreshed once a day, and when you press Refresh.
• Not yet: cloud accounts (Bedrock, Azure OpenAI, Vertex) as a source, and the hosted GitHub scan. Those are later phases.

• What it does: one pull request per system on a norcaster/<system> branch, from the commit Norcaster scanned. It describes what changes, which secrets to add, how to verify and how to roll back. It names the deployment and the NORCASTER_API_KEY secret. The key itself is never in the pull request: make it with Connect, where it is shown once.
• What it never does: touch an existing branch, reopen a closed pull request, force-push, write to another branch or merge. A system without a code patch gets no pull request; step 5 says why and points to Connect.
• Write access, only for this step: the GitHub App now asks for read and write access to contents and pull requests. Existing installations see GitHub's approval prompt, and step 5 links to it until you approve. Each pull request uses a token for that one repository only; scans stay read-only.
• Tracking: step 5 and step 6 show each pull request's state and link. After you merge and deploy, the first request through the gateway marks the system Governed. Then rotate its old direct keys from the key checklist.

• Rewritten now:

- Go: openai-go, anthropic-sdk-go and go-openai.

- Java and Kotlin: openai-java and anthropic-java builders.

- .NET: OpenAI's OpenAIClient, ChatClient and EmbeddingClient, and the official Anthropic client.

Each points the client at the gateway, with your Norcaster key and deployment. The rest of the client's settings stay as they are.

• Still a manual step, with the reason in the pull request:

- Azure clients in these languages, because switching them changes the client's types;

- the .NET Responses client, whose options type differs between SDK versions;

- the community Anthropic.SDK for .NET.

• Keys bound to one deployment: go-openai and the .NET SDKs cannot add a default header. Their clients therefore rely on a key bound to the one deployment, which is the key Connect makes.
• Fixed: step 5 no longer offers a pull request it can't open. Before, any system with a patchable change type was offered one, including Go, Java and .NET clients and the AI SDK's createAzure. The job then failed with "no automatic rewrite". Rows that already failed this way stay as they are; open a pull request again from step 5.

• Log upload: the log is read in your browser with the same rules as the norcaster-discover CLI. Only each AI host, its request count and the hour are sent; client IPs, user names, URLs and other hosts stay on your machine.
• Monitor mode with a deadline: applying a pack can now start it in monitor mode for 1 to 90 days, after which it enforces by itself. Offered for Enterprise baseline, Developer tools, GDPR and Student privacy. Finance, High-risk and Healthcare have no monitor period and enforce at once, as before. A stricter organization or project policy still wins.
• Create and link: each system is created, bound to its provider model, given its pack and linked, or nothing happens for it. A failure on one system does not stop the others, and the page says which step failed.
• Existing deployments keep their policy unless you tick "also apply the pack" for that row.
• Inventory uploads now include the AI provider hosts the code calls (bare host names), so an app can be matched to the log rows for the same host. An Azure OpenAI or Bedrock host can name your resource or region. Older inventories still upload.
• Not yet: pull requests for the code change, provider admin keys and cloud accounts as sources. Those are later phases of the plan.

• If you were refused: /run and Slack accept requests again, unless your /run and job usage on its own has reached the limit.
• Usage figures: current_usage.tokens_used in GET /entitlements and GET /deployments/{id} is now the usage that counts toward the limit, without gateway usage. GET /usage still reports all usage, gateway included.
• Requests: evaluated-request counts and request overage are unchanged.

• What changed: after installing the App, GitHub sends a one-time authorization code with the installation. Norcaster exchanges it for your GitHub token and checks that your account can use that installation. It then discards the token. Nothing is connected without that check.
• What you need to do: if the deploy page shows GitHub as not connected, click Connect GitHub once. Deployments that already exist keep their source; new builds from a repository need the connection again.
• Connecting with OAuth (no App) is unchanged.

• Switching reloads the page you are on for the organization you chose, so nothing from the previous organization stays on screen. Unsaved form input on that page is dropped.
• Removed: the separate organization pickers on Settings, Discovery, policy source documents and a few other pages; the sidebar switcher replaces them. Projects and Teams keep theirs, now tied to the same selection.
• Limits: the Deployments list, the AI register table, Evidence and Overview still list deployments across all your organizations, as before. Budget follows the organization the API picks. Organizations created outside the portal appear after a reload.

• Change provider on the deployment page now works for owners and admins on deployments someone else created.
• Audit: deployment.provider_binding.created and deployment.provider_binding.removed, recorded in the provider's organization and the deployment's organization, with who made the change and whether it was the deployment's creator. If the record cannot be written, nothing changes.
• Unchanged: others still get 404; members without the owner or admin role get 403; release assurance still applies. A deployment someone else created can only be bound to a provider of its own organization.

• Which scope a route needs: calling models through the gateway (/v1/*), sending chat messages and posting agent-session hook events need runs:write. Reading runs, enforcement events, traces, job status and your own usage needs runs:read, which runs:write, deployments:read, deployments:write and observability:read also grant. Org-wide usage, budget and alert views need observability:read. Membership, integrations, billing and data planes need admin. The full list is in docs/api-key-scopes.md.
• New scopes: governance:read reads the AI register, incidents, attestations, audit bundles, management review and the trace chain; exports count as reads. governance:write records incidents, concerns, attestations and estate-discovery decisions.
• Write grants read: a key with only deployments:write (or evals:write, knowledge:write, workflows:write, policies:write) can now call that family's read routes too.
• Keys the portal creates: the default gateway, Quickstart and service-account key (runs:write + deployments:read) keeps every route the Claude Code plugin, the VS Code companion and the SDKs call with it.
• Limits: keys without the scope are not refused on these routes yet. Keys created without scopes keep full access, and portal sessions are not limited by scopes.

• API: four read-only routes under /orgs/{org_id}/estate-discovery/: bypass-controls?format=domains|pac|squid|csv, bypass-controls/summary, managed-settings?tool=claude_code|codex|vscode and key-hygiene. API keys need governance:read.
• Rule width: by default each system gets its provider's host patterns, such as .openai.azure.com, which also match other teams' use of that provider. "Only hosts seen" (match=seen) lists only the exact hosts a proxy or egress source saw; systems with no seen host, such as uploaded inventories, are named instead of widened.
• Warnings come with every file: allow a self-hosted or hybrid data plane's egress first; the list also blocks legitimate direct use by other teams and tools; consumer AI apps are browser sites that the gateway cannot govern.
• Templates never contain a key. The Claude Code template reads each developer's own key through the Norcaster Companion's apiKeyHelper.
• Docs: docs/bypass-controls.md, and the managed-settings section of docs/coding-assistants.md.
• Limits: the exports and templates have not yet been tried on a real proxy, browser PAC setup or developer machine. The lists cover only systems discovery knows about, and tools that ignore the proxy or the managed settings are not affected. Glob patterns such as bedrock*.amazonaws.com need a gateway that supports wildcards inside a label, or the Squid export.

• Response change: a response with tool calls now has tool_calls (id, type: "function", function.name, function.arguments as a string), content set to null when the model wrote no text, and finish_reason set to tool_calls when the provider gave none or its own name for it (tool_use, function_call). Any other finish reason the provider gave, such as stop on a forced tool choice, is kept. Responses without tool calls are unchanged.
• Arguments reach the client as the provider sent them, even when they are not valid JSON. Anthropic tool_use input is serialised to a string.
• Runs and cache: the run records tool_use (true or false, never names or arguments). A response with tool calls is not written to the gateway cache.
• Limits: output policy reads the assistant text only, so tool-call arguments are not scanned on any path. Streaming tool-call chunks are unchanged. Legacy functions / function_call requests are not forwarded.

• API: POST /orgs/{org_id}/estate-discovery/candidates/{id}/close-bypass with {"reason": "..."}; API keys need governance:write. Closing a system that was seen again re-issues it with a new date. Provider usage that already goes through Norcaster without a deployment answers 409.
• Evidenced means one of these reported after closing: reconciliation of the system's provider account, finding no bypass call; an ingest batch for the organization (organization-wide, so it cannot prove the pipeline covers that system's network path); or a later inventory scan of the same repo that no longer lists the system.
• Alert: coverage_drift_detected with reason bypass_seen_after_closing names the systems in still_seen_after_closing, once per system per new sighting, through your alert rules for that event. The check runs in the daily coverage job.
• Audit bundles: the coverage section and its CSV gain closed_bypass rows with each system's state, honesty tag and the sources that looked. The PDF bundle does not show them yet.
• Self-hosted operators: DISCOVERY_BYPASS_QUIET_DAYS sets the quiet period (default 7, 1 to 365).
• Limits: verified quiet covers only what the named sources report. A reconciliation window that straddles the closing time counts as seen after closing.

• Refused elsewhere: a key whose only scope is coverage:ingest gets 403 on every other route, including key rotation.
• Explicit scope: POST /coverage/ingest accepts only keys that carry coverage:ingest or admin. A key created without scopes is refused there, as before.
• Existing keys are unaffected: none could carry this scope before.
• The norcaster-discover README and CLI now point at a coverage:ingest key instead of an admin key.

• Choosing the project yourself: the New deployment modal still lets you pick the project when the organization has several.
• Unchanged: a Default Project is still created only when the organization has no project.

• Labels: gateways appear as portkey, cloudflare_ai_gateway, helicone, openrouter or vercel_ai_gateway. A private or cluster-local host is self_hosted_openai_compatible (or self_hosted_anthropic_compatible), and any other public host is openai_compatible_unknown. A base URL built at run time keeps the SDK's provider and is marked unresolved in the local inventory.
• Where the base URL comes from: a string literal, or an environment variable set in the service's own .env, YAML (including Kubernetes name/value pairs) or TOML files. That includes OPENAI_BASE_URL and ANTHROPIC_BASE_URL when the code passes none. Only the host is kept.
• Migration plan: a self-hosted OpenAI-compatible server is planned as a Hugging Face provider with its origin as the base URL. You enter the origin; the plan never copies it. A private origin needs a self-hosted install or a hybrid data plane. Systems behind a third-party gateway or an unknown host aren't planned or patched, and the reason says so. For a gateway, decide whether Norcaster replaces it or sits in front of it.
• Egress and exports: the scanner keeps log rows for the documented Cloudflare AI Gateway, Portkey and Helicone hosts, and they count as known AI hosts in bypass exports.
• **--norcaster-host** now also applies to the code scan: a client whose base URL is on your own Norcaster gateway counts as governed.

• API: candidates gain coverage_state and a coverage block (governed request count over 24 hours, the deployment's coverage state, and whether and by which source the system was seen after the link). The list gains state_counts over all of the organization's systems.
• Still seen wins over governed. It follows the discovery scan (daily, or Run discovery). Reconciliation windows are an hour long, so a system linked mid-window can show as still seen for calls made before the link.
• Connect key: for users who can manage access, Create key makes a service-account key bound to that one deployment, with runs:write and no budget limits, and shows it once. Snippets cover the OpenAI and Anthropic SDKs and curl, in Python, Node or Go. Linked Discovery rows open the same panel.
• Coverage tiles: the assurance figure, ungoverned calls and untriaged systems tiles on the coverage page now show their numbers. Until now they showed a status label in place of the value.
• Limit: the deployment's Connect tab does not look up linked systems, so inventory guidance (environment variable names, the CLI patch command) shows only from the Discovery row.

• SDKs: openai-go, go-openai and anthropic-sdk-go; openai-java and anthropic-java (also used from Kotlin); OpenAI .NET, Azure.AI.OpenAI and Anthropic .NET (the official Anthropic NuGet package, v10 and later, which the manifest check also recognises now) and the community Anthropic.SDK. Patterns follow each SDK's README as of 30 September 2026.
• No false matches: a client counts only in a file of its language that imports the SDK, so a local package or class of the same name (an internal openai package in Go, a .NET ChatClient of your own) isn't one.
• Migration: OpenAI and Anthropic clients get base_url_swap with the SDK's own option (option.WithBaseURL, config.BaseURL, the builder's .baseUrl(...), OpenAIClientOptions.Endpoint, BaseUrl). Azure clients get client_swap. SUMMARY.md lists these services under "Not patched": change the option by hand.
• Limits: in these languages only calls to the four APIs the gateway routes are recognised (chat completions, messages, embeddings, responses). Assistants, Realtime, batches or files calls aren't seen, so check such a service by hand before moving it.

• Migration plan:

- OpenAI gets one provider per OpenAI host the scanned systems use. A regional one carries base_url: https://<host>/v1.

- residency_region is prefilled (eu, us, me) where OpenAI processes data in the region, and left required where it only stores it there.

- A system whose host the scan can't tell gets a required provider choice rather than the default host.

• Scanner: a client on eu.api.openai.com is recorded with that host, not as api.openai.com. Egress logs keep rows for OpenAI's regional hosts and for aiplatform.googleapis.com.
• Ingest: a regional OpenAI host is recorded as OpenAI traffic. The global Vertex endpoint is triaged as an unknown host, because Norcaster's Vertex provider can't route the global location.
• Bypass exports: with provider-wide rules, an OpenAI system's list now covers api.openai.com and the ten regional hosts, and a Vertex system's list covers the global endpoint. Review the list before applying: it also blocks other teams' direct use of those hosts.
• Not verified: reconciliation reads OpenAI's Usage API on api.openai.com. OpenAI doesn't document whether usage of a data-residency project is reported there.

• Inventory upload: the browser reads the inventory.json from the norcaster-discover CLI and sends only system id and name, repo name, provider, models, SDKs, scanner status, migration type, confidence, tool and embedding use, call-site and hard-coded-key counts, environment variable names and the suggested pack. File paths, line numbers and code stay on your machine, and the preview shows exactly what will be sent. A system's id and name include its component directory. Uploading the same inventory again updates those rows without adding duplicates. norcaster-discover upload-payload writes the same body for POST /orgs/{org_id}/estate-discovery/inventory.
• Register and deploy: choose a provider with a stored credential (or add one with a key you type), a model and a pack. The portal then creates the deployment, applies the pack and links the system, and hands off to the AI register for purpose, data classification and owner. It does not set monitor mode with a deadline; set that on the deployment's Policies tab.
• Link to existing deployment: POST …/candidates/{id}/link and …/unlink, audited. Linking needs edit rights on the deployment. A system linked to one deployment must be unlinked before it can be linked to another.
• API: GET …/estate-discovery/candidates, POST …/scan, POST …/candidates/{id}/register and …/dismiss. Reasons are kept in the audit trail only.
• Limit: members who can edit deployment configuration see the Discovery entry but cannot list systems.

• Run record: runs resolved this way record request_metadata.deployment_id_source = "api_key_binding".
• Errors: a bound key that names another deployment still gets 403 credential_not_bound_to_deployment. /v1/messages and /v1/embeddings now return the code missing_header like the other routes, and the message mentions the bound-key option.
• Limit: some portal and docs copy still says the header is always required.

• The refusal: 409 with code: IMMUTABLE_PROJECT_MOVE_CHANGES_POLICY, the deployment, from_project_id, to_project_id and the policy keys the move would change (changed_keys).
• Same rule as organization and project policy changes: tightening is refused like loosening, and a move that leaves the effective policy unchanged is allowed. Turning immutable production mode off in the same request as the move does not let it through.
• Unchanged: release assurance and independent approval still refuse a move first, with the same messages. A project you cannot access is still a 403.
• Evidence: a permitted move now records the deployment's new policy version at once, attributed to whoever moved it. Before, the version was recorded at the next request, with no author.
• Portal: the Project picker on a deployment's page now shows the refusal's message.

• What is gated: organization and project policy updates, pack applies at either scope, and policy proposals applied at either scope. A write needs approval only when it would change the effective policy of such a deployment. Deployments without a project, and writes that leave those deployments unchanged, work as before. Turning on independent approval from the organization or a project is not itself gated.
• The refusal: 409 with code: INHERITED_CHANGE_APPROVAL_REQUIRED, every affected deployment and why (immutable_production_mode, independent_policy_approval), and nothing changed.
• Sending it for approval: POST /orgs/{org_id}/scope-policy-changes with the full policies, or submit_for_approval: true on a pack apply (202, status: "proposed"). Policy proposals applied at organization or project scope are routed automatically. GET /orgs/{org_id}/scope-policy-changes lists requests; POST .../{id}/approve with the reviewed expected_hash applies one, POST .../{id}/reject rejects it.
• Approval rules: as for a deployment config proposal. The approval is bound to the reviewed hash, and is refused if the organization's or project's policies changed after the request. The author cannot approve when an affected deployment requires independent approval. Release assurance still applies. One pending request per organization and per project.
• Evidence: each step is recorded in the platform audit log, and the policy versions an approval produces are linked to it.
• Limits: the portal has no "Send for approval" action or approval inbox rows for these requests yet. Audit bundles do not show the approval link yet.

• Revoking use of your provider: find the deployment in the list and pass its target_id to DELETE /providers/inference-targets/{target_id}.
• **runtime:** allowed; creator_not_owner_or_admin for a personal deployment whose creator is no longer an owner or admin of your organization (its requests are already refused); other_organization for a deployment in another organization (also refused).
• Filters: model_id for one provider model, limit for the number of rows (newest first).

• Release assurance: in an organization or project that requires release assurance, binding the provider is refused, as it already is in onboarding, and the new deployment is left without a provider.
• Earlier deployments: an owner or admin can move one into a project of the organization from the deployment's settings. Until then it runs only while its creator is an owner or admin of that organization.
• Unchanged: the modal's demo and GitHub options.

• Which hosts: the three hosts where OpenAI documents both storage and processing in the region. OpenAI's storage-only regional hosts (jp., gb., au. and others) and the default api.openai.com derive nothing: api.openai.com is never treated as us.
• Stricter: with a residency allowlist and region_policy_untagged_provider: block, an OpenAI provider on eu.api.openai.com tagged us is refused with GOVERNANCE_PROVIDER_RESIDENCY_MISMATCH.
• Less strict: in the same setup, an untagged OpenAI provider on eu.api.openai.com is allowed when eu is on the allowlist; before, it was refused as untagged. Off the allowlist it is refused with GOVERNANCE_REGION_NOT_ALLOWED.
• Unchanged: with the default fail-open posture the declared tag still decides. The providers list shows verified, derived_only or mismatch for these providers.
• Only the provider's base URL counts: a base URL saved only with the credential isn't read, so that provider stays not derivable.

• Who: an organization owner or admin with the manage-policies permission. API keys need admin.
• Body: {"pack_id": "...", "mode": "enforce" | "warn" | "off"}. Leaving out mode keeps the pack's own mode.
• Refusals: a pack not on your plan gets 402. A change that would move a live deployment requiring release assurance gets 409 RELEASE_ASSURANCE_REQUIRED, which now names the deployment and says nothing was changed.
• Versions: the organization's policy version and every deployment's policy version are bumped.
• Unchanged: PATCH /orgs/{org_id} still stores global_policies as sent and writes no platform audit event.
• Organization custom rules can only be edited through the API, so few organizations should have been affected.

• Selecting an organization: an organization you choose in the dashboard's selector is still used as before.
• Organization pickers: they list organizations in the order you joined them.

• API: GET /orgs/{org_id}/pack-suggestions?candidate_id=…&deployment_id=… returns ranked packs, each with the rule, input and value behind it. API keys need policies:read, plus deployments:read when a deployment is given. Pack detail and manifest gain framework_tags; pack list items gain framework_ids.
• Same rules offline: the norcaster-discover CLI and the API share the pack rules, so with no register fields the top suggestion matches the scanner's.
• enterprise-baseline is suggested when nothing else names a pack. Packs not on your plan are listed as unavailable.
• From the row: Use this pack (opens Register and deploy, or applies the pack to the linked deployment after you confirm), Choose another, or Upload policy documents.
• Limits: every framework catalogue's mapping is self-declared, not externally validated. Every pack records decisions, so every pack lists all nine frameworks; the portal shows obligations backed by blocked or redacted events first.

• Project and organization applies: an owner or admin with the manage-policies permission; API keys need admin. Each is audited, and nothing is applied if the audit record cannot be written. A change that would move a live deployment requiring release assurance gets 409, naming the deployment.
• Proposal apply API: POST /orgs/{org_id}/policy-proposals/{id}/apply and …/preview-apply take target: {scope, id} with confirm_target_id. The older deployment_id / confirm_deployment_id form still works. Budget items cannot be applied at organization or project scope and come back in refused_items. In the response, deployment_id and revision_number can now be null.
• Waiting for approval: the apply returns status: "proposed" with the config proposal id. The policy proposal stays in review until that proposal is approved or rejected. Separation of duties is unchanged.
• Limits: on Discovery, Use this pack on a deployment that requires independent approval, when it is not in immutable mode, shows the 409 instead of creating a proposal. Organization and project changes that alter an approval-gated deployment are covered by a separate entry (KNOWN_BUGS #84).

• What to do if you are refused: bind the deployment to another provider, or move it into a project of the organization that owns the provider.
• Where it applies: /run, the gateway, workflow model nodes, Slack, chat and policy extraction, which all resolve the provider the same way.
• Unchanged: a deployment in an organization still cannot use another organization's provider.

• Who is affected: a script that called POST /auth/upgrade directly now gets 404 Not Found. To change plans, use the portal's upgrade flow, which goes through Stripe checkout.
• API reference: the endpoint and its UpgradeRequest body are no longer in the OpenAPI schema.

• Where: the platform audit log (category change_management) and the audit bundle's change_history: rows with source platform_audit, action deployment.boundary.changed and a boundary object holding each value before and after and the names of those that changed.
• Policy versions: the policy hashes in boundary match the content hash of the deployment's policy versions, and the row names the version in force after the change.
• Verification: bundles verify as before; the verifier needs no update.

• Joining a project: an active membership with the deploy role in its organization, the same as creating a deployment there. A project that does not exist and a project in an organization you are not in get the same 403.
• Leaving an organization: unassigning a deployment, or moving it to another organization's project, needs an owner or admin of the organization it leaves, plus the deploy role in the one it joins.
• Weakening: a move that loosens the deployment's effective enforcement needs an owner or admin, as a config change to enforcement does. The refusal names the weakened keys. A move that only tightens it does not.
• MFA: owners and admins meet their organization's MFA requirement when they move a deployment.
• Unassign: "project_id": null unassigns. "" or any other value that is not a project id is a 422; it was a server error.
• Redeploys: POST /deploy with deployment_id and a new project_id applies the same checks, and no longer moves a deployment out of a project that requires independent approval.

• Same rule everywhere: onboarding and Discovery already use the oldest project when they have to choose one, so the first project in this list is the one they pick.
• Unchanged: the New deployment modal still lists projects by name.

• Setting: GET and PUT /orgs/{org_id}/estate-discovery/settings with {"reconciliation_enabled": true}. A change is audited; if the audit record cannot be written, nothing is saved. API keys need admin to change it.
• Usage key: POST /providers/{provider_id}/credentials takes an optional usage_api_key (OpenAI only, sk-admin- only), stored encrypted with the credential. The portal's credential form does not send it, and saving the credential again without it removes it. An OpenAI account without one is attested, with no usage call.
• Project scope: an OpenAI project id (proj_…) in the provider config, under usage_project_id, openai_project_id or project_id, limits the comparison to that project.
• What Norcaster counts: requests Norcaster refused before calling the provider, and runs that failed as provider_unavailable, are left out, because the provider never served them.
• Self-hosted operators: COVERAGE_RECONCILIATION_ENABLED now has three modes. true reconciles every organization, as before. false turns it off everywhere. Unset reconciles only organizations that turned it on. An install that left it unset moves from off to per organization with none turned on, so it still makes no provider usage calls until an admin turns it on.
• Limit: PATCH /orgs/{org_id} can still write the organization setting without the settings endpoint's audit record.

• Still open: the organization list (GET /orgs) has no fixed order yet. A dashboard page that falls back to the first organization listed can show a different organization from the one setup used.

• Unchanged: an organization with no project still gets a Default Project, and one with a single oldest project keeps using it.

• Who is affected: automation that manages keys, members or organization settings with a scoped key that lacks admin now gets 403 API key missing required scope(s): admin. This includes the Python and JavaScript SDK methods create_api_key, list_api_keys and revoke_api_key. Add admin to that key, or use a key created without scopes.
• Keys never grow: a key cannot create a key with scopes it does not hold, or one that expires after it does. A key bound to a service account or to deployments cannot create keys at all.
• Rotation keeps limits: POST /auth/api-keys/rotate now keeps the key's deployment binding, service account and expiry. Until now the rotated key came back unbound and never expired.
• Still allowed: any key can rotate itself, revoke itself and call GET /auth/me.
• Limits: routes outside this list, including the gateway /v1/* routes and the observability, usage and enforcement-event reads, still accept a key with any scope.

• Where it applies: POST /providers/inference-targets with target_type: self_hosted_deployment. The portal does not create self-hosted targets.
• Audit: deployment.provider_binding.created rows record previous_status and new_status, so a switch onto the default model shows in the audit log and in audit bundles.

• Who is affected: a script that read api_key from POST /auth/signup now gets null, and the response carries session_id instead. Create API keys in the portal under Settings → API keys, with the scopes the integration needs.
• The session: it follows the portal's idle and absolute session timeouts and ends on logout, a password change or a password reset. Until the address is verified, API calls are refused as before.
• Email verification off (self-hosted): signup already returned a session. The signup page now goes straight to the dashboard instead of showing "Check your inbox".
• SDK: the Python SDK's signup closes the session it receives, as login and verify_email already do, and returns the same message and email.

• What you see: status failed with the message "Its provider model binding was removed, so it has no model to run. Bind a provider model to run it again." Requests get 400 "Deployment not runnable (status: failed)".
• To run it again: bind a provider model on the deployment's page; it is ready again straight away.
• Audit: the unbinding's audit record and bundle row show the status before and after.

• Rules with "Min events" of 1, the default, are unchanged: they fire on every matching event.
• Changing a rule's event type, threshold, window, minimum or scope starts a fresh count. Silencing a rule does not.
• If the event counter is unavailable, a rule fires on every matching event rather than staying silent.
• Webhook, Slack and email payloads are unchanged.

• Whole-organization audit bundles show deletions in their change history.
• A workflow run whose own deployment disappears mid-run now stops its tool, MCP and retrieval nodes with a clear error instead of running them without the deployment's policies.
• The SDK (delete_deployment(..., force=True)) and CLI (delete-deployment --force) take the same option.
• Deleting still removes the deployment's enforcement events; keeping them (soft delete) is planned as a separate change.

• Settings → Governance frameworks → AI objectives: choose a metric, a target and a window. The metrics are block rate, redaction rate, eval pass rate, gateway coverage, deployment stops and overdue register reviews. A metric with nothing to measure shows "no data yet", never a miss.
• Audit bundles → Management review pack: pick a period and download the pack. It covers objective results, blocked requests and deployment stops, recorded changes, register state, the status of every ISO/IEC 42001 attestation, audit exports and the previous review. Then use Record review sign-off.
• Generating a pack is recorded in the platform audit trail with its period and digest. The pack itself is not stored.
• Audit bundles now carry two more sections: ai_objectives (each objective measured over the bundle period) and management_reviews (packs generated in the period).
• New endpoints:

- GET and PUT /orgs/{org_id}/ai-objectives (saving needs the record-attestation permission)

- GET /orgs/{org_id}/management-review/pack

- GET /orgs/{org_id}/management-review/count

• Lifecycle: open, acknowledged, contained, resolved, closed. Resolving asks for the root cause and whether this was a nonconformity with your AI management system. A resolved or closed incident can be reopened.
• Who can do what: members who deploy can open incidents and add notes. Owners, admins and the governance role move them through the lifecycle and manage corrective actions.
• Evidence: audit bundles carry an incidents section with source, status, root cause, the nonconformity decision and corrective-action tallies. The chain entries carry ids and statuses, never the text.
• API: /orgs/{org_id}/incidents (list, open, count, detail, transitions, notes, corrective actions, effectiveness checks) and POST /orgs/{org_id}/concerns. Operator guide: docs/incidents.md.
• Not yet built:

- opening an incident in one click from an alert, a blocked request, a stop or a claim — the API already accepts the source;

- a concern button in the chat app;

- emailing the owner when a concern is reported.

• Clauses that leave no stored record (context, leadership, planning actions and objectives, support, management review, continual improvement) stay out of scope and are listed as such. Only an accredited certification body certifies.
• Planned changes count policy versions, config proposals resolved with proposer and resolver, and changes to the model a deployment serves.
• Internal audit counts completed audit-bundle exports, including exports whose file has expired.
• Resources count registered providers, models with their approval state, tools, knowledge sources and data planes. Human resources are attested.
• Every audit bundle now carries two more sections: resource_inventory (names, types and states only, never configuration or credentials) and export_history (earlier exports in the period). Register rows in change_history now say why they were written (change_source).
• New read-only endpoints: GET /orgs/{org_id}/change-events/count, /resource-inventory/count and /audit-bundles/count.

• API and export change: deployment_id can be null on enforcement events, in list and export responses, audit bundles, the trace-chain payload and the enforcement webhook. Organization-scoped decisions carry org_id and org_policy_version instead. The CSV export gains org_id as its last column. Integrations that assume every decision has a deployment need to handle null.
• Who sees them: organization-wide Decision Audit, list and export show them to members with organization-wide evidence access. Audit bundles requested for the whole organization include them, with an org_policy_version_snapshots section. Reviewers scoped to a project or deployment do not see them.
• Policy versions: changing the organization's policies (PATCH /orgs/{org_id}) records a new organization policy version. The offline bundle verifier (norcaster-verify) checks each decision's pin against the bundle's snapshots. Verifiers from before this change count these decisions as unpinned instead of failing the bundle.
• Limits: the coverage statement and the fleet, budget and outcome views still count deployment traffic only. An organization with no billable deployments cannot export an audit bundle yet, though list and export include its decisions.

• MCP approvals are recorded against their deployment, like the other MCP action gateway routes.
• Knowledge-base answers, workflows, eval runs and policy extraction are recorded as organization-scoped decisions under the organization whose kill switch refused them: deployment_id is null and org_id is set. They appear in that organization's organization-wide Decision Audit and on its trace chain. For a workflow, that organization can differ from the workflow's own: it can be the organization that owns a deployment the workflow uses, or one whose member owns a personal deployment it uses.
• The record is written in the background, never delays the refusal, and is not linked to a run.
• This replaces the 24 September note that a workflow refusal naming no deployment is refused but not recorded. Refusals because a deployment is stopped were already recorded on these paths.

• When the organization that owns the operator's extraction deployment engages its kill switch, policy extraction is refused for every organization that uses that deployment until it is released.
• When the extraction deployment is chosen automatically, a candidate covered by a kill switch is skipped, as stopped ones are, and the next candidate that can run is used. The request is refused only when every candidate is covered.

• Recorded on redeploys, rollbacks, canary promotions, provider-model binding and GitHub push redeploys. A push is recorded as a system change with no user.
• Re-binding the same provider model, config-only redeploys, and canary or shadow rollouts that have not been promoted do not count.
• The review reminder email says what changed and when; the register's change history labels these rows.
• Organizations can change the window with org_settings.ai_register.reassess_window_days (0–365 days) or switch the behaviour off with reassess_on_model_change: false.

• Enforcement change: allow_cross_region_fallback no longer lets through a knowledge base's embedding provider that is outside the allowed residency regions. Knowledge-base answers and retrieval queries that use such a provider now return 403 with governance_region_not_allowed, and workflow retrieval steps that use it fail. To fix it, tag the embedding provider with an allowed region or change allowed_provider_residency_regions. Before this change the provider was used and nothing was recorded.
• Fallbacks: on Slack replies, an opted-in cross-region fallback is recorded as a warned decision and a provider failover as its own event, on the message's run.
• Retrieval queries: POST /retrieval/query has no deployment and no run, so a refusal there is recorded as an organization-scoped decision on its own.
• Limits: model, agent and retrieval steps in a workflow with no deployment are refused but not recorded. On Slack, a refused reply is recorded as a blocked decision, but the run is marked provider_unavailable and the reply is still the generic "Model inference failed" message.

• Formats: a printable page, a JSON download and a PDF download.
• Recorded, not stored: each generation is recorded in the platform audit trail with its digest. The sheet itself is generated on demand.
• ISO/IEC 42001 view: A.6.2.7 technical documentation now reads generated sheets. A new row covers A.8.2/A.8.5 information for users and interested parties, 23 rows in total. What is communicated to users stays the organisation's to attest.
• Audit bundles: a system_documentation section lists each system with a generated sheet and its latest digest.
• API: GET /deployments/{id}/system-information?format=json|html|pdf and GET /orgs/{org_id}/system-information/count.

• Stop and Resume buttons on the deployment page, with a required reason; the page shows who stopped it, when and why.
• A stop no longer waits for open streams on the deployment to finish.
• Workflow runs and MCP approvals waiting on a stopped deployment are blocked and stay blocked after resume until an owner or admin unblocks them (POST /workflow-executions/{id}/unblock, POST /v1/mcp/{deployment_id}/approvals/{approval_id}/unblock).
• A deployment can be stopped while it is building.

• Engage and release from Settings → Danger Zone (type the organization name to confirm), or with POST /orgs/{org_id}/runtime-halt and /runtime-halt/release. A banner shows on every dashboard page while the stop is on.
• Responses that are already streaming end within about two seconds, with a final error event the OpenAI and Anthropic SDKs raise. Work already running, such as a workflow step or a queued job that has started, finishes its current step.
• Workflow runs and MCP approvals waiting when the stop is engaged are blocked, not cancelled, and stay blocked after release until an owner or admin unblocks them.
• Releasing the stop does not resume deployments that were stopped one by one.

• The refusal record is written in the background and never delays the refusal. A refusal that names no deployment, such as a workflow with no deployment in its graph, is refused but not recorded this way.
• Runs ended by a stop, or by cancelling or rejecting a workflow, are closed and sealed on the trace chain.

The escalate path was not part of that verification; approvals are demonstrated through the portal queue. Works with OpenAI's Responses API — there is no partnership with, certification by, or endorsement from OpenAI.

Part of the runtime attribution work landed the same day: enforcement events, action events, and runs carry the principal that sent the request (user and key), the signed trace chain covers it, and exports carry pseudonymous ids only.

• 7 September 2026: the actual primary and fallback targets are validated against the region policy before a provider adapter is called.
• 10 September 2026: the Anthropic-native /v1/messages route runs the same residency gate as /v1/chat/completions (403 and an enforcement event before any upstream call).
• Residency is enforced from the operator's tag on the provider, not verified against the endpoint: configured residency, not physical residency evidence.

Runtime identity (engine, image digest, NIM version) is recorded when the NIM reports it or the operator annotates it; otherwise the record says not reported. Norcaster does not serve the GPU. This is compatibility with NIM only; Norcaster has no relationship with NVIDIA of any kind.

• PyPI and CLI package: quantlix → norcaster. npm scope @quantlix-ai → @norcaster; the offline verifier is @norcaster/verify.
• Newly issued API keys use the ncr_ prefix. Keys issued before the cutover stay valid; leak detectors match both prefixes.
• The chat widget is rebuilt with Norcaster branding and keeps a legacy #quantlix-chat-root mount as a fallback.

Norcaster (formerly Quantlix) is the trading name of Navego AB, a Swedish company. We renamed in September 2026 as we expanded beyond the Nordics; another, unrelated company uses the Quantlix name. The product, team, contracts and EU hosting are unchanged.

• Changing enforcement mode and managing policies now require the matching organisation permissions, so a member can no longer downgrade enforcement on their own deployment.
• The system prompt is governed by the same resolution.
• Follow-up fixes to the fail-closed path landed on 15 Aug 2026.

Configured per organisation. Deprovisioned users lose access on their next request; provisioning and configuration changes are recorded in the audit log.

Gateway coverage was first exported into bundles and leadership reports on 12 June 2026; this change aggregates the detection sources into one section with the honesty tags, and exposes the same figures through the coverage API.