v0.2.2

Clearer banking and marketing setup instructions for platform v0.4.0.

Changes

• Distinguish fresh-platform initialization from adding Java monthly banking to
  an existing marketing installation. The banking archive includes the complete
  second-domain procedure; the marketing guide directs operators to that route.
• Preserve existing platform and network identity, customer and partner model
  settings, marketing credentials, shared A2A budgets and saved results when
  adding banking. Reject duplicate connections or partial starter setup before
  writes, and retain a private backup of the Runtime connection file.
• Explain the initial Runtime recreation required for static connections, then
  check configured banking capabilities and a saved marketing run through the
  native Python SDK without launching a simulation.
• Refresh versioned archive names and download instructions. The scenarios,
  service images, SDKs and model profiles are unchanged from v0.2.1.

Compatibility

• Platform: v0.4.0, distributed separately.
• Java: ai.astraform:sdk-java:0.4.5 from Maven Central.
• Python: astraform-sdk==0.3.5 from PyPI.
• Provider contracts: 1.2.3.

These archives retain the existing image digests and image-source revision.
The release manifest separately identifies the packaging revision and archive
checksums. Updating the packaged guides does not upgrade platform capabilities
or change an older archive. No new SDK installation is needed for the supplied
container workflow.

Downloads and operation

Choose Python issued banking, Java issued banking, Java monthly banking or
scheduled marketing from the release assets. Verify the matching .sha256 file
before extraction and follow the bundled README. The shared
release-manifest.json records the four archives, image identities and source
revisions; each archive includes its own file manifest. A source version does
not establish that release assets are available.

For an existing marketing installation, use the Java monthly-banking guide's
second-domain procedure. Do not rerun a fresh initializer over existing
connections or delete them to bypass its refusal. Finish active runs before
changing static connections and recreating Runtime. This procedure does not
provide automatic live registration or modify accepted runs.

Preserve platform database and evidence volumes, configuration and deployment
identity. Marketing domain and agency conversation state remain in memory.
These trusted single-host examples do not establish production isolation,
high availability or population capacity. Keep credentials and evidence private.
A completed simulation does not certify advice quality or execute a real payment
or campaign launch.

Published v0.2.1 and earlier archives retain their original bytes, image pins
and instructions. Use each archive's guide and manifest rather than replacing
its images with another version's selection. The online
monthly-banking guide
also describes the additive route for unchanged v0.2.1 downloads.

Astraform-authored samples retain Apache License 2.0. Platform software and
third-party dependencies retain their separate terms.

Astraform Samples v0.2.1

Astraform Samples v0.2.1

Banking and marketing starters using the renamed Astraform SDK packages, with
the existing Java and Python imports and APIs preserved.

Compatibility

• Platform: v0.4.0, delivered separately from the samples.
• Java: ai.astraform:sdk-java:0.4.5 from Maven Central.
• Python: astraform-sdk==0.3.5 from PyPI.
• Provider contracts: 1.2.3.

For source builds, Java provider tests use
ai.astraform:conformance-java:0.4.5; Python provider checks use
astraform-conformance==0.3.5. The conformance imports and
remote-domain-conformance command are unchanged.

Replace the old Python author-kit distribution when adopting astraform-sdk;
do not install both into one environment because they provide the same imports.
The container starters include their runtime dependencies. Source builds use
the checked-in Maven dependencies and PyPI registry locks.

Starter selection

Starter	Archive
Python issued banking	astraform-banking-starter-v0.2.1.tar.gz
Java issued banking	astraform-java-banking-issued-starter-v0.2.1.tar.gz
Java monthly banking	astraform-java-banking-monthly-starter-v0.2.1.tar.gz
Scheduled marketing	astraform-marketing-scheduled-starter-v0.2.1.tar.gz

Download the selected release's archive and matching checksum, verify the
checksum, then follow its bundled README. The shared release-manifest.json
identifies the source revisions, image digests and archive hashes. The manifest
inside each archive records its compatibility and file checksums. A source
dependency update does not change previously published images or archives.

The generic Java/Spring provider starter is now available as
starter-java-spring in samples source, with a standalone Maven build. It is
separate from the four deployment archives and is no longer distributed as an
SDK Maven template artifact.

The marketing example has one customer goal: understand the actual readiness
finding and get practical agency advice. The customer can clarify material
uncertainties or propose a handoff for agency feedback within the same
conversation. Scheduled and current-boundary configurations use that same goal
with different simulation start boundaries. The models choose their messages and
when to stop; the example prescribes no minimum number of turns or successful
outcome. Advice and proposal feedback do not execute the handoff or clear the
campaign for launch.

Simulation behavior

Platform configuration, customer launch, run inspection and evidence export use
the native SDKs. Partner-bank setup uses the partner-owned banking API.
Customer and partner models remain independently configurable.

Issued banking and marketing retain their authored receipt conditions and
customer-FINISH requirement. Monthly banking retains native scheduled domain
work and participation through its configured horizon. The selected platform
must support these capabilities; installing an SDK does not upgrade platform
behavior. Model decisions, unsuccessful goals and stop reasons remain visible
in the recorded evidence. Goal completion does not certify factual advice or
confirm a real payment or campaign launch.

Preserve platform database and evidence volumes. Marketing domain state and
agency conversation state remain in memory. These single-host examples do not
establish production isolation, high availability or population capacity. Keep
credentials and customer evidence private.

Published v0.2.0 artifacts retain Java SDK 0.4.4, Python SDK 0.3.4 and contracts
1.2.2. Use each historical archive with its own guide and manifest rather than
substituting its image or package versions.

Astraform-authored samples retain Apache License 2.0. Platform software and
third-party dependencies retain their separate terms.

Astraform Samples v0.2.0

Astraform Samples v0.2.0

Native customer simulation samples for banking and marketing, with independently
configured customer and partner models.

Compatibility and starter selection

The source uses Java author kit 0.4.4, Python author kit 0.3.4 and
contracts 1.2.2, targeting a separately delivered platform v0.4.0.
Use the artifacts listed by the selected platform and samples releases, and
verify their manifests and checksums. Platform v0.3.0 provides strict customer FINISH support;
explicit banking domain identity and marketing
requestFactBindingMode: "RESOLVE_TRUSTED" require v0.4.0 or later. Packaging
records the selected scenario's requirements without silently removing fields.

Starter configuration	Archive	Customer and domain behavior
Python issued banking	astraform-banking-starter-v0.2.0.tar.gz	Python bank; issued statement; qualifying receipt and customer FINISH
Java issued banking	astraform-java-banking-issued-starter-v0.2.0.tar.gz	Java bank; same strict issued-statement rule
Java monthly banking	astraform-java-banking-monthly-starter-v0.2.0.tar.gz	Java bank; native monthly statement work and retained participation through the horizon
Scheduled marketing	astraform-marketing-scheduled-starter-v0.2.0.tar.gz	Marketing domain work, Creative Agency reply and customer FINISH

Download the artifacts listed by the selected release and verify each archive's
checksum before extraction. The shared release-manifest.json identifies source
revisions, image digests and archive hashes. Source dependency pins do not update
existing images or establish their installed package versions.

Customer and partner model selection are independent. Gemini partner profiles
and Gemini/Ollama customer options are documented in each starter's guide. Keep
credentials in private configuration rather than scenarios or shared evidence.

Integration and completion behavior

Customer creation, publication, launch, inspection and evidence export use the
native Java/Python SDKs. Banking preparation seeds only the partner-owned backend
and discovers the customer's scoped MCP grant; the downloaded Java client then
owns the Java customer workflow. A Java provider can also serve a separately
configured Python customer; provider and customer language are distinct choices.

Issued banking and marketing preserve their explicit
completionPolicy.requireCustomerFinish:true plus receipt conditions. Monthly
banking preserves its authored policy, native domain work and horizon; packaging
does not add a strict flag. Customer decisions and model responses remain
observable, including unsuccessful outcomes. Inspect actual advice and stop
reasons; configured achievement does not certify factual quality or payment
execution.

Marketing source offers separate advice and proposal-review cases. Proposal
review asks the customer to develop a handoff and obtain assessment of its
coverage and remaining gaps; it does not execute that handoff. Updated templates
require domain revision marketing-ops.native-events.v4 and its matching input
schema. The selected review separates completion from launch approval and
preserves known, unknown and unreported business facts. Use matching rebuilt
images when adopting these templates; source changes do not alter old archives.

Operation and limits

Public archives use digest-pinned images and include their compatibility
requirements. Local-verification archives instead require their recorded image
IDs already installed; keep them local rather than distributing them as public
downloads. Image architecture descriptors alone do not establish runtime
compatibility with a host.

These samples use a single host and private network. They do not perform real
payments or campaign launches, or establish production security, high
availability or population capacity. Marketing domain and agency conversation
state remain in memory; exported platform evidence is a separate durability
boundary. Preserve platform database/evidence volumes and keep credentials,
logs and customer evidence private.

All Astraform-authored samples retain Apache License 2.0; platform software and
third-party dependencies retain their separate terms.

Astraform Samples v0.1.0

Astraform Samples v0.1.0

The first shared release of Astraform's public examples. All domains, languages
and frameworks use this repository version; choose the example you need without
installing the others.

Included

• A downloadable Python banking starter and SHA256 checksum: prebuilt bank,
  separate PostgreSQL database, LLM Banking Advice agent, Gemini/Ollama templates,
  customer scenario and SDK launch/inspect/export helper.
• Source examples for Java/Spring banking, Python/FastAPI banking, Marketing Ops,
  the LLM Creative Agency, Banking Advice and Refund Policy.
• Guides for connecting partner services to the released Astraform platform
  through HTTP, A2A and customer-scoped MCP tools.
• Apache 2.0 licensing for all Astraform-authored examples and documentation.

Java and marketing are source examples in this release. Prepared starter
archives for them are not included yet. GitHub's source archives contain only
this public samples repository, not the Astraform platform implementation.

Python banking starter

Avery has an already-issued January credit-card statement and AUD 100 available.
The customer must understand the amount, due date and whether that budget covers
the minimum payment or full balance. The customer reads its assigned account
through MCP; the banking partner reads the same backend through its own API and
answers over A2A. Both agents use configured language models.

Download astraform-banking-starter-v0.1.0.tar.gz and its matching .sha256
asset. Verify the checksum before extracting, then follow the included README.
The release also includes release-manifest.json with release and starter
provenance. The archive selects refreshed, digest-pinned Python SDK 0.3.2
banking and advice images; bundle-manifest.json records their actual build
revision, compatibility and payload hashes. Its embedded notes come from the
selected packaging revision, which can differ from the repository release commit.

Compatibility

Component	Version or requirement
Astraform Platform	v0.2.0, downloaded separately from the platform release
Python SDK	0.3.2, included in the Banking Advice image
Java SDK	0.4.2, used by the Java source examples
Public contracts	1.2.0
Starter host	Docker with Compose v2 and Python 3.10+ for initialization
Models	Gemini or Ollama, configured separately for the customer and partner

Platform, SDK and samples versions are independent. Provider credentials remain
in local private configuration and are not part of the archives.

Verification and limits

Source compatibility checks against the published Java 0.4.2 and Python 0.3.2
packages passed 621 banking, marketing and advice tests with no skipped tests.
Python banking used real PostgreSQL. Advice tests used owned HTTP/model fixtures;
these package checks did not execute a real customer-model simulation.

Earlier ARM64 reference trials used the released platform bundle and the previous
Python SDK 0.3.1 banking images. Gemini achieved the configured customer goal
with an MCP lookup and a real A2A partner exchange. The Ollama customer retrieved
its statement but abandoned the goal before contacting the partner; that run did
not exercise the partner model. Both outcomes and same-run evidence inspection
were preserved. Those trials do not establish the outcomes of the refreshed
images. Check the release's current verification record for the exact image
digests and actual model outcomes; AMD64/ARM64 availability alone is not runtime
verification on both architectures.

The packaged scenario uses fixed, already-issued records. It does not exercise
monthly statement generation, multiple customers or capacity limits. The banking
partner reads current records per request, has no persistent conversation history
and cannot make or schedule payments. Source examples include additional
scenarios; their presence does not extend this starter's verification.

Customer choices and goal failures are simulation evidence. Service health or a
successful export does not establish answer quality. Inspect the goal, messages
and actual tool activity in the result before evaluating the partner's behavior.

License

Examples, configuration and documentation use Apache License 2.0. The Astraform
platform is distributed separately under its own terms. Third-party components
retain their licenses.

Refreshed artifact verification

The refreshed images were built from public samples commit 8cfcb2cf3ddaf305124005acdc846ca1895713da. All eight image/architecture combinations across AMD64 and ARM64 were checked against the actual published SDK bytes: Java 0.4.2 for Java banking and Marketing Ops, and Python 0.3.2 for the public banking and advice pair. Source labels and later filesystem layers were also verified. The exact Python starter candidate has SHA256 70afe9cf66db3fe7485aef7b40b33d862345601a9b9804765fa286ef1d593f2d; its 13 manifest-listed payload hashes pass, and the archive contains 14 files including the manifest.

The release configuration was merged at a9aa4bad7678485675691a21ea21057a7a62fcfe. Its exact main checks and publication workflow passed. All three public release assets were downloaded anonymously; the archive and checksum are byte-identical to the candidate used for the prepublication trial, and the release manifest records that release commit and the pinned packaging source.

The runtime trial covered the Python banking starter on ARM64. One prepublication customer trial with genuine qwen3.5:4b/Ollama ended FAILED after about 18.5 minutes. Two recorded customer-provider responses each ended with finish reason length and reported 8,192 completion tokens, and the customer goal timed out; no successful customer decision or native customer MCP/A2A receipts were observed. One separate manual read-only partner request returned HTTP 200 in 10.227 seconds. Its 536-character genuine-model reply was preserved and validated against the actual response schema, bank context and issued statement. The partner response also included unsupported financial interpretation; schema/transport success does not establish correct advice. That check covers the tested endpoint/model path; answer quality and a successful native customer goal remain unverified. Runtime verification was performed on ARM64 only; the AMD64 checks cover image availability and SDK bytes.