Axiom turns the Stacks Project into reusable, machine-checked mathematics

Mathematics you can build on

A major mathematics reference can now be used as a library of machine-checked proofs. The interesting part is what researchers can build when they can reuse those results directly.

Our main story today is Axiom's formalisation of the Stacks Project, and how turning existing mathematics into reusable code could change the work of researchers and AI developers.

On 4 November, Axiom released a connected library of definitions and proofs in Lean, a system that checks formal mathematical arguments. Axiom describes approximately sixteen million lines of code covering the roughly seven-and-a-half-thousand-page Stacks Project, a major reference in algebraic geometry.

That's an enormous translation job. A written mathematical reference gives a knowledgeable reader definitions, arguments and results. A formal library expresses that material precisely enough for software to check how the argument follows from its assumptions. The result becomes something another proof can depend on.

You don't need to follow algebraic geometry to see the attraction. Imagine working on a problem where an established result supplies one step in your argument. With a reusable formal library, you can build on that result within the same checking system. The definitions and conditions travel with it. You have a connected starting point for further work.

Axiom's public interface links formal declarations to the original Stacks tags, the identifiers used to locate material in the reference. That gives researchers a practical way to move between the mathematics they recognise and its formal expression. It also helps them inspect the exact result they're bringing into a new proof.

Those links are particularly useful because mathematical results come with conditions. Change an assumption and you may have changed the statement. A researcher checking a translation can follow the tag, compare the original result with the formal declaration, and examine whether the assumptions match. That connection makes a very large release more approachable, one relevant result at a time.

There are two tiers. StacksCore has received human review. StacksFrontier is AI-written material that hasn't yet received that review. Lean checks proofs in both.

The distinction has a concrete meaning: Lean checks whether the formal argument works, while a mathematical reviewer examines whether the formal statement captures the intended mathematics. A perfectly valid proof of a differently expressed statement would leave a translation problem. The tier labels help researchers choose which material to inspect more closely before building on it.

For AI research, having a connected collection of checked results also changes the starting conditions. A system working on a new proof can potentially reuse established definitions and theorems. That creates an opportunity to study how well it selects and combines existing mathematics, with the formal checker assessing the resulting argument.

The value can accumulate through reuse. If a definition or result supports several later arguments, making it available in a shared formal form gives each of those arguments a common foundation. Researchers can spend more attention on the new step they're trying to establish.

My reading is that research organisations should judge this release by the mathematics they can successfully inspect and build on. The linked reference and the review tiers give them somewhere concrete to begin. A useful test would follow a result from its original statement, through its formal translation, into a further checked proof. That's where a vast library starts to become working research infrastructure.

Ripple opens another coding-model option

That gives researchers a new foundation to build on. For developers, there's also a new coding model they can run themselves.

Ricursive released Ripple-65B Preview on 4 November, with downloadable weights under Apache 2.0 and hosted access. It's a sixty-five-billion-parameter dense Transformer, offered with instruction-following checkpoints and a base-model checkpoint.

The practical attraction is choice over deployment and adaptation. A developer can try the hosted preview, while an organisation with the resources to operate it can evaluate its own installation. Access to the weights also opens a path to customising the model. The licence is an important part of that flexibility.

Ricursive provides instruction checkpoints in BF16 and NVFP4, two numerical formats for storing and computing with model values. They give deployment engineers different starting points when matching the model to their hardware. A sixty-five-billion-parameter model still makes hosting resources a significant part of the decision.

The model card describes text-based training and a maximum context of a little over one million tokens. Context is the material a model can take into account in a request. For coding, that creates room for substantial source material, instructions and tool results to sit together.

The useful question is how reliably it uses the relevant detail across that space. A coding task may depend on one constraint buried in a file, or on the relationship between several parts of a project. Evaluating those cases tells a developer more about the value of a large context window than its capacity alone.

Ricursive reports a score of eighty point five two on Terminal-Bench 2.1. The surrounding agent software and the way it handles context affect that result, so comparisons are most useful when those conditions are matched. Hosted access includes native tool calling, which lets the model participate in workflows that invoke external tools.

For developers choosing a coding system, I'd put Ripple on the evaluation list where control over hosting or customisation has real value. Use representative work to compare completed tasks, deployment demands and the effort needed to get dependable results. It's a preview, which makes production reliability part of that evaluation. The release gives you another option to measure against the way you already build software.

Rubin reaches cloud procurement

Running larger models brings us to the hardware bill, and a new option on Google Cloud.

Google confirmed on 6 November that its A5X instances, based on NVIDIA's Vera Rubin platform, are generally available. The original announcement appeared on 21 October; the November update marks the move into availability.

The documented bare-metal configuration combines two Vera CPU sockets with four Rubin GPUs and one thousand, one hundred and fifty-two gigabytes of HBM4 GPU memory. These instances are intended for large-model training and serving, using hardware based on NVIDIA's Vera Rubin NVL72 platform.

That memory figure is useful because a model workload needs room for more than its stored weights. Training and serving also involve working data, with the requirements depending on the job. A large pool of fast GPU memory gives engineers more scope to accommodate demanding workloads. Exactly how they use it depends on their software and deployment design.

Bare metal means the product gives customers access to the underlying physical server resources. For an organisation building a substantial AI deployment, that makes the hardware configuration a concrete engineering input: the CPUs, accelerators and memory available for its workload.

Access is through Google's account teams. Customers need to reserve capacity and obtain provisioning instructions, so planning involves a conversation about an allocation. Australian regional availability hasn't been established in the announcement. That's a material question for anyone whose workload needs to stay in a particular location.

For an infrastructure buyer, general availability changes what can go into a procurement discussion. You can now pursue a reserved deployment of this product, with capacity and provisioning details to settle. The work then moves into checking whether the software you use fits the platform and what the workload costs to run.

I'd focus that comparison on useful throughput: the training work completed, or the serving demand handled, for the money and capacity available to your organisation. Memory capacity and accelerator specifications help explain what's possible. A representative workload shows how much of that possibility you can use. The next useful number for a buyer is the cost of their own job on the capacity Google can supply.

OpenAI puts campus commitments on paper

The buildings around that computing power have their own costs, and local communities have a stake in who pays.

On 5 November, OpenAI published a National Community Compact and a policy blueprint for future US data-centre campuses it owns and operates. The commitments include local agreements, annual reporting, site-level water and electricity disclosures, and independent noise studies.

Those site-level details could make discussions about a particular project much more useful. A community living near a campus has questions about that location's water demand, electricity use and noise. Reporting at the site gives residents and local decision-makers a more specific basis for examining those questions.

OpenAI also reiterated its earlier commitment to cover electricity and supporting infrastructure costs. The new detail is financial assurances before major spending, intended to protect other customers if a project changes or fails.

The timing is important. Infrastructure spending can begin before a campus is operating. Financial assurances address the possibility that a project won't proceed as planned after those commitments have been made. For the people evaluating a proposal, the substance is how those arrangements cover the costs associated with that site.

There's a defined boundary here: the compact covers future US campuses that OpenAI owns and operates. Partner-operated facilities sit outside that stated scope. OpenAI is also proposing industry-wide rules; those remain policy proposals.

For Australian organisations buying AI services, this provides a way to frame questions about the infrastructure behind a service. Which facility is involved? Who operates it? What local reporting and financial arrangements apply? The answer may depend on the particular site supplying the capacity.

My view is that the most useful part of the compact is the specificity of the promised disclosures. Annual reporting, resource figures for individual sites and independent noise studies give communities identifiable information to expect as projects develop. The financial assurances add a separate question about who carries the cost if plans change.

Those details could give local decision-makers a firmer basis for negotiating arrangements before a campus becomes their neighbour.

GitHub's workflow deadline approaches

If you maintain a public repository, there's a much nearer date that could interrupt your automation.

GitHub has postponed its default block on pull_request_target workflows until 2 December. Before then, it's running two trial enforcement windows. In Sydney time, they're from three to five in the morning on Tuesday 10 November and Tuesday 17 November.

During those windows, affected workflows will create failed runs instead of executing. Outside the windows, the rule remains in evaluate mode until permanent enforcement begins. So an early Tuesday failure may be the planned policy trial showing you which automation is affected.

The pull_request_target trigger runs in the context of the base repository, the project receiving the proposed change, and can access secrets. That privileged context is why GitHub is changing its default treatment.

The protection applies to public repositories on GitHub Free, Team and Enterprise Cloud. Private and internal repositories are outside this change, as is Enterprise Server. Whether a particular workflow is blocked also depends on the Actions event policy that applies to it. An explicit applicable policy can permit the trigger.

For a maintainer, there are two linked decisions. First, identify which workflows rely on this event and what work they perform. Then decide whether that work needs the privileges of the base repository, and whether an exception is justified. The answer may vary between workflows within the same organisation.

A trial window makes the effect visible as a failed run. That's useful operational evidence: it identifies an actual interruption in the automation, which can then be traced to the trigger and policy involved. The two dates leave time to understand that effect before the December block becomes permanent.

I'd keep any exception tied closely to the automation that needs it. A broad allowance makes it harder to distinguish a necessary privileged workflow from other uses of the trigger. The concrete task now is to understand what will stop, what privileges it needs, and which policy is responsible. A blocked workflow leaves its usual work undone. If you rely on that automation when accepting changes, the trial also lets you see how your normal process behaves when it stops.

AWS bundles web research

There's also a smaller change for builders who are assembling agents that need information from the web.

AWS launched Web Answer on Amazon Bedrock AgentCore on 5 November. It's a generally available managed tool that searches the web and synthesises an answer with citations.

Builders can include or exclude domains and filter by publication date. Those controls let an application narrow the material used for a request, for example by limiting the source sites or the period being searched.

The tool connects through AgentCore Gateway using MCP, the protocol for connecting AI applications to tools, and AWS's IAM authentication. Initial availability is in Northern Virginia, with charging per tool call. An Australian deployment therefore needs to account for that US region.

For developers already using AgentCore, the attraction is replacing some custom search-and-answer integration with one managed component. AWS handles more of the retrieval and synthesis workflow; the application retains the exposed source and date controls.

I'd evaluate it where maintaining that integration is taking time away from the application itself. The comparison is between operating your own retrieval workflow and paying for a managed call, including how much control you need over the sources and the resulting answers.

SonicWall VPN fixes need attention

One security update deserves attention from anyone responsible for remote access through a SonicWall firewall.

SonicWall has released fixes for an exploited flaw in SAML-configured SonicOS SSL-VPN services. The Canadian Cyber Centre confirms that CISA added it to the Known Exploited Vulnerabilities catalogue on 6 November.

An attacker needs valid credentials for an alternative authentication method. On an affected configuration, those credentials can allow access around the multi-factor authentication enforced through SAML, the system used to pass sign-in information between services.

The affected products include specified builds in the Gen7 SonicOS 7.3 and Gen8 8.2 families. SonicWall's administrator notice identifies the affected and corrected builds. BleepingComputer reports that there's no workaround, making the relevant firewall update the immediate response.

CISA's remediation deadline is 20 November for US federal civilian executive agencies. For other organisations, confirmed exploitation is the reason to prioritise checking the firewall's exact build and SAML configuration now.

I'd put that configuration check and the corresponding fixed build ahead of any reassurance from seeing MFA enabled on an account. The vulnerable path runs through the appliance's authentication behaviour, so the repair belongs there.

What Changes for You

To finish, making a short AI video has become a little more flexible, with more room to revise a shot.

Google made Gemini Omni 1.2 Flash generally available through its paid Gemini API on 5 November. It generates clips up to fifteen seconds, up from ten, and supports conversational editing. Follow-up prompts can change the background, lighting or other details of a clip.

For a creator, that offers a different way to work through a draft. You can ask for a change to the existing clip instead of starting a whole new generation. A fifteen-second limit also gives an individual shot more breathing room, though it's still short-form video.

Standard video output at 720p costs approximately seven US cents per second, or about one US dollar and four cents for fifteen seconds. Google describes that video price as thirty per cent lower than Omni 1.1. Input and text-output charges are additional, and this model has no free API tier.

Access through other Google products is separate. Fifteen-second generation is rolling out in Vids for Google-account and Workspace users. In the Gemini app, the rollout is for Google AI Ultra subscribers. Availability depends on the product and account.

Google identifies fast action and complex physics as continuing limitations. Outputs carry SynthID, and editing people's speech remains restricted. Those are useful boundaries when deciding whether a planned clip suits the tool.

For builders adding video to an application, I'd budget around the finished clip you can use. That includes attempts, edits and the time someone spends reviewing the result. Lower output prices give experimentation more room, while conversational editing offers a way to keep developing a promising draft. The practical opportunity is to spend less effort restarting a shot when the change you need is specific.