AIC FOUNDRY: reusable .NET engineering for mission systems

Intelligence programmes rarely commission just one application. A collection service, an analyst tool and a reporting application may be built by separate teams, yet each needs maintainable software, controlled dependencies and a dependable release process. Rebuilding common engineering for each contract ties up budget before the mission-specific work begins.

AIC FOUNDRY supplies reusable .NET capability through versioned packages, contracts and engineering patterns. Teams select the capability their solution needs and build their own domain behaviour around it. Customer demonstrations are available now, including discussion of package delivery within the engineering environment you use.

What AIC FOUNDRY provides

FOUNDRY maintains reusable engineering as a product with its own development and release lifecycle. A change to a shared component can be tested, versioned and released independently of an individual customer application. The consuming team can then assess that release against its own delivery schedule and assurance requirements.

That separation matters when several programmes use related capability. Copying a useful implementation into five repositories creates five places to investigate when the original changes. A controlled package gives teams a stated dependency to inspect and update. The mission application still owns how that dependency is configured and used.

The product includes modular contracts and implementations, automated build validation, dependency management and package delivery. It works with Microsoft .NET, NuGet, Azure DevOps, Git and Visual Studio. The relevant question for a buyer is which packages fit the proposed system and what the maintained release arrangement includes.

Where it fits in the AIC portfolio

AIC FOUNDRY provides the reusable software engineering capability described here. For .NET applications connecting to Palantir Foundry, AIP and a customer Ontology, PAL.NET supplies AIC’s licensed access layer. The two products address different engineering requirements.

AIC FOUNDATION provides the project templates, layout and delivery scaffolding from which a solution starts. FOUNDRY provides reusable capability that solution can consume. Together, they address two recurring costs: setting up a project and maintaining implementations that several projects need.

These engineering products sit alongside the analyst-facing capabilities described in the AIC Constellation intelligence software guide. They are relevant to organisations building or extending their own mission systems, including teams that need specialist behaviour around an existing intelligence platform.

Keep ownership and deployment clear

FOUNDRY packages are consumed within the approved customer or AIC engineering environment. The product has no hosted application-data dependency. Delivery can use private package feeds, with source-enabled licensing available where the contract provides for it. Access to source and rights to modify or redistribute it should be stated in the agreement.

The consuming application owns its runtime security design. Its architect specifies identity, access controls, encryption and deployment configuration for the intended environment. FOUNDRY provides reusable engineering capability within that design, with the solution team responsible for the application’s acceptance evidence.

For an international intelligence organisation, that gives the technical discussion a concrete starting point: where packages enter the environment, who approves versions, how builds are reproduced and which rights remain with the customer. Those decisions belong in the proposed delivery model, alongside the operational requirement.

Make the demonstration answer an engineering question

Choose one small application representative of the work you actually fund. Ask AIC to show the selected packages, explain their responsibilities and identify the code your own team would maintain. Inspect the package versions and build output. A demonstration is more useful when the boundary between reusable capability and your application is visible.

Then examine change. Pick a package update and establish how the consuming team would review it, test it and retain the version previously approved for use. Include a developer who will maintain the application after the initial delivery team leaves. Their questions often expose documentation and handover costs that a feature demonstration misses.

The FOUNDRY engineering reuse evaluation follows two example applications through package selection and a controlled upgrade. Use it to agree what your engineers need to inspect before accepting shared capability into a customer solution.

Compare the whole cost of maintaining the capability

The commercial case rests on avoided repetition. A maintained component can remove work that would otherwise be implemented, tested and supported independently across several systems. The size of that benefit depends on how closely the available packages match the requirement and how often they are reused.

Compare licence and support charges with the engineering, testing, onboarding and upgrade effort in the alternative. Include migration and integration work. Ask which improvements are covered by the product release arrangement and which require a separate commission. A low initial development quote tells you little about the second application or the next major upgrade.

Arrange a FOUNDRY demonstration with AIC. Bring your .NET environment, proposed application, package restrictions and support expectations. AIC can then show the relevant capability and prepare a scoped comparison against the work your team would otherwise have to build and maintain.