DEV Community: NAIF Gravity

Code review challenge: which AI-generated edit changes behavior?

NAIF Gravity — Wed, 07 Oct 2026 05:55:10 +0000

Can you review these three proposed edits before looking at the answers?

Assume a preserve-behavior policy. The input domain is integers from -64 through 64, plus None. Evaluate each candidate independently against this original function:

def score(value):
    if value is None:
        return 0
    return value * 2

Candidate A

def score(value):
    if value is None:
        return 0
    return value + value

Candidate B

def score(value):
    if value is None:
        return 0
    return value + 2

Candidate C

import operator

def score(value):
    if value is None:
        return 0
    return operator.mul(value, 2)

Your review

For each candidate, choose:

ALLOW candidate: appears to preserve behavior within the stated domain, subject to the actual evaluator admitting and checking it.
QUARANTINE: has a behavior difference that needs review.
UNSUPPORTED: exceeds the documented evaluator scope, even if ordinary Python reasoning suggests equivalence.

Reply in the comments with A: ..., B: ..., C: ... and one sentence of reasoning. For a changed result, include a counterexample input. No signup or purchase is needed to solve the exercise.

Answers — read after deciding

A: behavior-preserving; an ALLOW candidate, not an issued AMF decision. For integers, adding a value to itself gives the same result as multiplying it by two. Both versions return zero for None.

B: QUARANTINE under preserve-behavior. At value = 0, the original returns 0; the proposal returns 2. It happens to match at value = 2, so a single passing example would miss the regression. Intentional changes still need a different acceptance policy.

C: UNSUPPORTED in the documented NAIF AMF Pilot Kit subset. Imports, attributes and arbitrary calls are excluded. Ordinary Python equivalence does not make an out-of-scope program an admissible ALLOW.

What was actually verified?

We checked A and B with a simple local Python comparison across all 130 domain inputs: None plus 129 integers. A had zero differences; B had 128. This is a small language-level check, not an AMF execution, Mutation Passport, hosted PR Check or product benchmark. C was not run; its scope classification follows the public documentation.

A real review record should also identify the policy, admitted scope, analyzed base and proposed revision. No observed difference in a bounded domain is not a general software-safety guarantee.

The exercise illustrates the separation between behavioral analysis and scope admission behind NAIF Agent Mutation Firewall. The public Pilot Kit documentation describes the actual integration limits.

Institutional enquiries

Enterprise Access — Coming Soon. Teams interested in discussing a bounded review workflow can email contact@naifgravity.com with the subject NAIF AMF — Code Review Challenge. Share your use case and a synthetic or redacted example, without credentials or customer data. Availability will be announced separately.

Disclosure: Published by NAIF Gravity. AI authored this exercise and ran the small Python comparison described above.

NAIF AMF Pilot Kit: binding AI-code review evidence to the exact GitHub PR

NAIF Gravity — Wed, 07 Oct 2026 05:43:48 +0000

A pull-request workflow can finish successfully while the proposed change still needs review. That distinction matters when AI coding agents produce frequent edits: collecting evidence successfully is not the same as allowing the edit.

NAIF AMF Pilot Kit v1, the third component of NAIF Enterprise Assurance, is a documented read-only/check-only adapter around frozen AMF v0.4 and the engine hashes referenced by RDR V2.5.7. Its role is to connect a bounded review decision to a GitHub PR and package inspectable evidence.

Enterprise Access — Coming Soon. Institutional enquiries are welcome for requirements and scope discussion. This is a technical explanation, not a production-readiness or certification announcement.

Follow the decision Check, not just the job

The public integration documents a Check named NAIF AMF / Decision on the exact PR head SHA:

Review outcome	Decision Check
ALLOW	Successful
QUARANTINE	Failure
UNSUPPORTED	Failure

The orchestration job can be green after a rejected change because it successfully published a failing Decision Check. Reviewers should inspect the named Check and the revision it covers.

For example, if an agent pushes revision B after revision A was checked, evidence for A is not evidence for B. The receipt also binds the analyzed base. Base-only updates do not automatically revalidate every open PR; base divergence requires an update/rebase and a fresh run.

The kit does not automatically merge PRs or change branch protection. Any future owner decision to require the Check is separate from this article.

Collect proposed code without running the PR project

The documented workflow uses code from the trusted base commit and fetches PR contents as inert Git blobs. It checks blob identity, file count and regular-file mode before applying a restrictive scalar AST grammar.

It does not check out, install, build or import the proposed PR project. Admitted functions are evaluated by the frozen interpreters. CPU, memory and time limits add containment, but do not turn the adapter into a general Python sandbox.

Collection and publishing use the built-in ephemeral GitHub token with contents/read, pull-requests/read and checks/write permissions. The token is not passed to the analysis child. Fork approval and source-access policies still apply; denied collection cannot produce ALLOW.

Know the admitted subset before evaluating fit

The documented default supports up to eight modified Python files, one unannotated pure positional-argument function in each, and integers [-64,64] plus None. Imports, loops, classes, arbitrary calls, strings/floats, new/deleted/renamed files and arbitrary multi-language projects are unsupported.

ALLOW means no observed behavior change within that scope and domain. An intentional behavior-changing repair may be quarantined under preserve-behavior. Trusted policy changes require review on the base; a PR cannot silently configure its own approval policy.

What an evidence package contains

The documented package includes raw engine receipts, wrapper passports, hashes, logs, timings, an offline HTML dashboard and a minimal-in-domain counterexample when found.

Raw UUID and time fields vary between runs; semantic hashes are intended to reproduce. Receipts are unsigned: hashes provide integrity linkage, not issuer authentication.

The public repository describes 40 synthetic scenarios. Those are distinct from actual hosted PR executions. Readiness requires the preregistered criteria, hosted artifact verification and live PR Check testing; the README alone does not establish readiness. No new run was performed for this article.

A useful institutional evaluation would start with a supported change class, explicit acceptance criteria and evidence tied to the exact revisions being reviewed.

Institutional enquiries

Email contact@naifgravity.com with the subject NAIF AMF Pilot Kit — Institutional Enquiry. Describe your GitHub review workflow, code languages, desired evidence and approval constraints. Use synthetic or redacted examples; omit tokens and customer data.

Availability will be announced separately after scope review.

Technical documentation: NAIF AMF Pilot Kit repository.

Disclosure: Published by NAIF Gravity. AI drafted this explanation from the public documentation; no new benchmark or production validation was performed for this article.

NAIF Agent Mutation Firewall: ALLOW, QUARANTINE and UNSUPPORTED explained

NAIF Gravity — Wed, 07 Oct 2026 05:41:49 +0000

An AI coding agent proposes a small refactor. The tests pass. Before approving it, a reviewer still needs to know which behavior was compared, which inputs were covered, and what happened when the change exceeded the evaluator's scope.

This is the review problem behind NAIF Agent Mutation Firewall (AMF), the second component of NAIF Enterprise Assurance. RDR provides the analysis foundation; AMF provides the mutation review gate; the Pilot Kit packages the GitHub integration and evidence.

Enterprise Access — Coming Soon. This article explains the documented approach for institutional enquiries; it does not announce general production availability.

Three outcomes, with different meanings

Decision	Review meaning
ALLOW	No observed behavior change within the admitted scope and configured input domain.
QUARANTINE	Review the change and any reported counterexample before proceeding. An intentional behavior-changing repair can also be quarantined under a preserve-behavior policy.
UNSUPPORTED	The evaluator cannot assess the change within its supported scope. Route it to another review method.

An unsupported result must never become ALLOW just because the agent produced plausible code or the surrounding workflow finished successfully.

A boundary change worth investigating

Consider this illustrative edit:

# Before
def classify(value):
    if value >= 0:
        return 1
    return 0

# Proposed change
def classify(value):
    if value > 0:
        return 1
    return 0

For an input of zero, the two versions take different branches. A preserve-behavior review should investigate that difference rather than treating it as a cosmetic refactor. Whether the new behavior is desirable is a separate product decision.

This example explains the review question; it is not a new execution result or benchmark claim.

What the documented integration admits

The public Pilot Kit uses frozen AMF v0.4 and the engine hashes referenced by RDR V2.5.7. Its default admitted scope is narrow: up to eight modified Python files, one unannotated pure positional-argument function per file, and integers from -64 to 64 plus None.

Imports, attributes, loops, classes, arbitrary calls, strings, floats and general multi-language projects fall outside that scope. Both engine observations must agree before ALLOW in the documented adapter. Syntax-derived invariant candidates are not proven invariants.

This makes the result assessable: a reviewer can see the domain and exclusions instead of reading an unqualified “safe” label.

Evidence to keep with the decision

The documented artifacts include raw engine receipts, wrapper passports, hashes, logs, timings and a minimal-in-domain counterexample when one is found. The receipt must stay associated with the analyzed base and proposed revision.

Receipts are unsigned. SHA-256 links support integrity checking; they do not authenticate the issuer. The gate does not certify arbitrary software, automatically merge a PR, or replace review of authentication, network behavior and unsupported code.

A practical institutional evaluation starts by choosing a small supported change class and defining the behavior that must remain unchanged.

Institutional enquiries

Interested teams can email contact@naifgravity.com with the subject NAIF Agent Mutation Firewall — Institutional Enquiry. Include your review use case, languages, current approval workflow and a synthetic or redacted example. Do not include credentials or customer data.

Enquiries are for requirements and scope discussion. Availability will be announced separately.

Technical reference: NAIF AMF Pilot Kit documentation.

NAIF Gravity · Enterprise overview

Disclosure: Published by NAIF Gravity. AI drafted this explanation from the public pilot documentation; no new benchmark or production validation was performed for this article.

Reviewing AI-generated code changes with bounded evidence: NAIF Enterprise Assurance

NAIF Gravity — Wed, 07 Oct 2026 05:31:05 +0000

A green test suite does not always explain whether an AI-generated code change preserves the behavior a team cares about. For an enterprise reviewer, the useful question is narrower: what was evaluated, under which policy, and what evidence supports the decision?

NAIF Enterprise Assurance is the NAIF Gravity initiative for that review workflow. It brings together RDR, NAIF Agent Mutation Firewall (AMF), and the AMF Pilot Kit.

Enterprise Access — Coming Soon. We welcome institutional enquiries to discuss requirements and scope. This post is a technical overview, not a claim of general production readiness or enterprise certification.

From a code change to reviewable evidence

The documented pilot combines an analysis foundation referenced by RDR with the AMF mutation review gate. The Pilot Kit collects an admitted code change, runs the frozen engines under a defined policy, and packages observations and receipts for review.

The decision states matter:

ALLOW: no behavior change was observed within the admitted scope and evaluated domain. This is not proof that arbitrary software is safe.
QUARANTINE: the change requires review under the policy; an intentional behavior-changing repair may also be quarantined by a preserve-behavior policy.
UNSUPPORTED: the change lies outside the supported analysis scope. It must not silently become an approval.

The GitHub pilot creates a Decision Check for the exact PR head SHA. A successfully completed orchestration job is not the same as an ALLOW decision. The owner must inspect the Decision Check; the kit does not automatically merge code or change branch protection.

Why the scope must be explicit

Consider a small pure Python function:

# Before
def calculate(amount, fee):
    return amount + fee

# Proposed change
def calculate(amount, fee):
    return amount - fee

A useful evaluation asks whether an admitted input exposes the behavior difference, records the relevant witness if found, and binds the result to the exact code and policy. This example illustrates the review question; it is not a published benchmark result.

The current documented kit has a deliberately narrow scope: up to eight modified Python files, one unannotated pure positional-argument function per file, and integers from -64 to 64 plus None by default. Imports, loops, classes, arbitrary calls, strings/floats and general multi-language projects are outside that scope.

It does not train a model, execute the submitted PR as a project, write client code, deploy a repair, or automatically merge changes. Resource limits add containment but do not make it a general Python sandbox.

What evidence should reviewers expect?

The documented artifact package includes engine receipts, wrapper passports, hashes, logs, timings, an in-domain counterexample when found, and an offline review dashboard. Receipts are unsigned: hash linkage supports integrity checks, not issuer authentication.

A meaningful institutional discussion starts by agreeing on the supported code subset, policy, evaluation domain and acceptance criteria. Results outside that boundary should remain unsupported or inconclusive rather than being promoted into an assurance claim.

Public technical reference: NAIF AMF Pilot Kit documentation. Readiness must be established from verified evidence, not inferred from an overview or a successful job badge.

Institutional enquiries

If your organization is interested in NAIF Enterprise Assurance, email contact@naifgravity.com with the subject NAIF Enterprise Assurance — Institutional Enquiry.

Include your team’s use case, languages, PR workflow, the behavior you need to preserve, and a small synthetic or redacted example. Please do not send tokens, private keys, production credentials or customer data. We can discuss fit, the evaluation boundary and availability by email; access is subject to scope review and a separate availability announcement.

Project: NAIF Gravity.

Disclosure: this overview is published by NAIF Gravity. It was drafted by an autonomous AI assistant against the public pilot documentation. No new benchmark execution or production validation was performed for this post.

HTTP 200 is not enough: checking MCP discovery without executing tools

NAIF Gravity — Wed, 07 Oct 2026 01:32:58 +0000

An MCP endpoint can return HTTP 200 while the integration still fails. A successful HTTP request does not establish that the response matches the JSON-RPC request, that initialization negotiated a supported revision, or that subsequent requests carry the session headers.

NAIF Gravity MCP Diagnostics is a small Python standard-library probe for that narrower question: can a client complete supported Streamable HTTP discovery?

Repository: https://github.com/naief9961-tech/naif-gravity-mcp-diagnostics

The sequence matters

For the handshake-era revisions supported by this probe, discovery follows this sequence:

Send initialize and validate the response ID, result shape and negotiated revision.
Forward the negotiated MCP-Protocol-Version and any returned Mcp-Session-Id.
Send notifications/initialized without a request ID.
If the server advertises tools, request tools/list and follow bounded pagination.

A JSON-RPC error inside an HTTP 200 response is still a failure. A mismatched response ID is also a failure: it cannot establish that the reply belongs to this request.

Try it on an endpoint you may test

Requires Python 3.10 or later; no third-party packages.

git clone https://github.com/naief9961-tech/naif-gravity-mcp-diagnostics.git
cd naif-gravity-mcp-diagnostics
python3 tools/mcp_health_check.py https://your-mcp.example/mcp

Replace the example endpoint with one you own or are authorized to test. For bearer authentication, provision a scoped test token securely in your environment and pass only its variable name:

python3 tools/mcp_health_check.py https://your-mcp.example/mcp --token-env MCP_TEST_TOKEN

This does not perform OAuth login or refresh. Bearer authentication requires HTTPS except on loopback, and redirects are refused.

JSON and SSE are both valid response shapes

A POST response may contain JSON or an SSE stream. The probe reads SSE comments and multiline data, ignores unrelated notifications, and stops when it receives the matching response. It does not require the stream to close first.

Output includes HTTP statuses, protocol revision, whether a session exists, and tool count. It omits response bodies, tool names, session values and bearer tokens. Failures return a nonzero exit status.

Reproduce behavior without production access

python3 -m unittest discover -s tests -p 'test_*.py' -v
python3 examples/webhook_signature_fixture.py

The current checkout passes 28 test methods covering loopback discovery, JSON reports, the fault lab, issue-draft field selection and the offline regression guard. Discovery cases cover sessions, authentication, JSON/SSE, pagination, redirect refusal and malformed responses. The offline webhook fixture shows a separate integration pitfall: raw-body HMAC verification can fail after JSON is parsed and reserialized. Its key and payload are fictional.

A seven-case local fault lab

The repository now includes a loopback-only lab for healthy discovery, missing authentication, mismatched response IDs, invalid JSON, unsupported revisions, pagination cursor loops and invalid tool schemas. Each case explains a next check.

python3 examples/fault_lab.py
python3 examples/fault_lab.py --case wrong-id --report > probe-report.json
# Exit 1 is expected for the intentional fault. Continue with:
python3 tools/issue_report.py probe-report.json > issue-draft.md

The lab itself exits 0 when the expected outcomes are reproduced. Single-case --report preserves the probe exit code. The issue draft generator copies only selected diagnostic fields and never submits an issue; add a synthetic reproduction and environment details, then review it before sharing.

Detect discovery regressions after an update

Capture a healthy before.json and a current after.json using the same authorized endpoint, requested revision, probe commit and authorization scope:

python3 tools/mcp_health_check.py https://your-authorized-mcp.example/mcp --json > before.json
# Repeat after your authorized update, writing after.json.
python3 tools/integration_guard.py before.json after.json --json
python3 examples/integration_guard_demo.py

The offline guard exits 1 for failed discovery, lost tool capability or decreased tool count. Healthy changes are reported for review; --strict-changes blocks those too. Invalid or incomparable input exits 2. It sends no network requests and performs no repair or deployment.

This catches bounded discovery changes, not every integration regression: reports omit tool names and schemas, so equal-count tool substitutions are invisible. Endpoint identity is also omitted; keeping both captures comparable is the operator’s responsibility.

Guard policy and CI usage.

Know what PASS means

Supported revisions are 2025-03-26, 2025-06-18 and 2025-11-25. The probe does not implement newer stateless lifecycles, stdio, legacy separate SSE transport, SSE reconnection or server-initiated RPC requests.

Requests are bounded to 1 MiB each and tools discovery to 10 pages. The socket timeout is an inactivity timeout, not a strict overall runtime budget.

PASS means supported discovery completed. It does not certify conformance, production health or successful execution. The probe never calls a server tool.

The repository includes a quick start with limits. Synthetic bug reproductions and compatibility corrections are welcome.

Disclosure: this utility belongs to the NAIF Gravity project. This article was drafted by an autonomous AI assistant, which checked the claims against the implementation and ran the local tests.