Skip to main content

astraform-remote-domain-author-kit

This is the Python author kit for remote-domain.v1.

Brutal truth: an "SDK" alone is not enough. If teams still have to reverse engineer request envelopes, invent their own starter layout, or guess how to prove conformance, you did not ship onboarding. You shipped homework.

This author kit is broader than a thin SDK. It includes:

  • reusable protocol constants and envelope builders
  • request validation helpers
  • an optional FastAPI app factory
  • a starter template inside the package

If you only want helper functions, that is the SDK-like layer. The author kit is the whole package around it.

Install

The published PyPI baseline is 0.1.6. This source tree is the 0.1.7 release candidate and stays version-aligned with the contract 1.0.4 Policy Wind Tunnel scorecard-role conformance train.

Protocol helpers only:

pip install astraform-remote-domain-author-kit==0.1.6

FastAPI helper included:

pip install 'astraform-remote-domain-author-kit[fastapi]==0.1.6'

Workspace release target:

  • astraform-remote-domain-author-kit==0.1.7

For repository-local SDK development beyond the published 0.1.6 baseline, use an editable install or a private pre-release wheel.

Repo-local development:

pip install -e './remote-domain-author-kit-python[fastapi,test]'

Starter-template validation is part of the release gate. It still runs the template's scripts/bootstrap-local-sdk.sh path against the repo-local SDK source, then separately runs an external-consumer smoke from the exact built local author-kit and conformance wheels. That smoke creates a clean project, copies the starter through the installed astraform-remote-domain-copy-starter command, installs the copied starter with --no-deps, runs validate-population-catalog, and passes remote-domain-conformance --population-catalog. That keeps the source bootstrap and release artifact paths honest before the matching SDK version is visible on PyPI.

Core Usage

from astraform.remote_domain.author_kit.protocol import build_manifest
from astraform.remote_domain.author_kit.protocol import build_projection
from astraform.remote_domain.author_kit.protocol import opaque_state
from astraform.remote_domain.author_kit.protocol import projection_envelope
from astraform.remote_domain.author_kit.protocol import success_envelope
from astraform.remote_domain.author_kit.protocol import validate_request_envelope


def manifest() -> dict:
    return build_manifest(
        domain_id="acme-ops",
        display_name="Acme Operations Domain",
        description="Remote proof domain",
        schema_version="acme-ops.state.v1",
        supported_agent_types=["Operator"],
        supported_interaction_modes=["SIMULATION", "HYBRID"],
        tools=[
            {
                "name": "lookup_case",
                "description": "Look up a case in the remote domain.",
                "inputSchema": {"type": "object", "additionalProperties": False},
            }
        ],
    )


def prepare(request: dict) -> dict:
    validate_request_envelope(
        request,
        expected_domain_id="acme-ops",
        expected_operation="prepare",
        require_idempotency=True,
    )
    state = opaque_state(
        "acme-ops.state.v1",
        {"personaName": "Taylor", "completedWorkCount": 0},
    )
    projection = build_projection(
        runtime_metadata={"domainProfile": "acme"},
        status_view={"completedWorkCount": 0},
        inspection_view={"tasks": []},
    )
    return success_envelope(
        request,
        runtime_identity="acme-ops::Taylor",
        next_state=state,
        projection=projection,
    )


def status(request: dict) -> dict:
    validate_request_envelope(
        request,
        expected_domain_id="acme-ops",
        expected_operation="status",
        require_state=True,
    )
    return projection_envelope(
        request,
        projection=build_projection(
            runtime_metadata={"domainProfile": "acme"},
            status_view={"completedWorkCount": 0},
            inspection_view={"tasks": []},
        ),
    )

Domain providers may add optional evidence_events=[...] to success_envelope(...) or projection_envelope(...). Use that lane for provider-internal evidence that Astraform cannot observe directly, such as a private third-party call or domain-owned policy check.

FastAPI App Factory

from astraform.remote_domain.author_kit.fastapi import create_fastapi_app

app = create_fastapi_app(
    service=my_remote_domain_service,
    policy_wind_tunnel_service=my_policy_wind_tunnel_service,
)

The service object must implement:

  • manifest()
  • optional population_catalog() for GET /api/remote-domain/v1/population/catalog
  • prepare(payload)
  • execute_work(payload)
  • status(payload)
  • inspection(payload)
  • shutdown(payload)

population_catalog() must return domain_population_catalog.v1. The FastAPI factory validates the catalog before returning it, so missing archetype fields, bad recipe numbers, unknown archetype references, and malformed eligibility fail before Population Builder treats the provider as usable.

Prefer a file-backed catalog over an inline Python dict. That keeps the domain authoring surface reviewable and conformance-testable:

from importlib import resources

from astraform.remote_domain.author_kit import load_population_catalog


def population_catalog() -> dict:
    catalog_file = resources.files("my_remote_domain").joinpath("population_catalog.json")
    return load_population_catalog(catalog_file)

load_population_catalog(...) reads JSON and runs the same validate_population_catalog(...) checks used by the FastAPI route.

The bundled fastapi-minimal starter also installs a provider-local preflight:

validate-population-catalog

That command validates src/acme_remote_domain/population_catalog.json before the provider starts and prints the exact rejected field when the catalog is malformed. Treat it as the first command after editing archetypes, segment templates, validation rules, or run-path eligibility.

The optional policy_wind_tunnel_service object exposes the remote Wind Tunnel provider routes:

  • GET /policy-wind-tunnel/pack
  • GET /policy-wind-tunnel/presets
  • POST /policy-wind-tunnel/runs
  • GET /policy-wind-tunnel/runs/{runId}
  • POST /policy-wind-tunnel/runs/{runId}/lifecycle
  • GET /policy-wind-tunnel/runs/{runId}/bundle
  • GET /policy-wind-tunnel/runs/{runId}/artifacts/{artifactType}
  • GET /policy-wind-tunnel/runs/{runId}/artifacts/{artifactType}/readiness
  • GET /policy-wind-tunnel/runs/{runId}/evidence-pack
  • GET /policy-wind-tunnel/runs/{runId}/evidence-pack/readiness

The readiness routes are metadata-only checks for dashboard download UX. They must prove the same provider-owned artifact/evidence-pack path is readable without materializing the JSON body or ZIP archive.

Policy Expressions

When a domain exposes Policy Wind Tunnel behavior, CEL-compatible PolicyExpression definitions are the portable decision contract. They are for decision gates, eligibility checks, thresholds, and conformance-testable public rules.

They are not the execution engine. Keep state mutation, external calls, proprietary scoring, and side effects inside your service implementation or domain-owned execution target. Use the expression's executionTarget as a stable provider-owned target name.

Python providers should publish the same /policy-wind-tunnel/pack metadata as Java providers. The helper below builds the portable parts of that response:

from astraform.remote_domain.author_kit import build_policy_expression
from astraform.remote_domain.author_kit import build_policy_wind_tunnel_pack_metadata


def wind_tunnel_pack() -> dict:
    return build_policy_wind_tunnel_pack_metadata(
        capabilities={"remoteProviderReady": True, "evidenceExport": True},
        control_schema={
            "type": "object",
            "properties": {
                "blockerCount": {"type": "integer", "minimum": 0},
            },
        },
        ui_schema={
            "fields": [
                {"name": "blockerCount", "widget": "number", "label": "Blockers"},
            ],
        },
        outcome_schema={
            "schemaVersion": "domain_outcome_schema.v1",
            "metricDefinitions": [
                {
                    "metricId": "blockerCount",
                    "label": "Blockers",
                    "unit": "count",
                    "evidence": "domain-state",
                },
            ],
        },
        domain_labels={
            "actorSingular": "campaign",
            "actorPlural": "campaigns",
            "simulatedActorsLabel": "Simulated campaigns",
        },
        policy_expressions=[
            build_policy_expression(
                expression_id="acme.blockers.acceptable",
                expression="metrics.blockerCount <= 10",
                execution_target="acme-policy-service",
                description="Blockers must stay under launch threshold.",
            ),
        ],
    )

Keep policy expression contract shape in the public contract bundle and SDK tests so Java and Python providers evaluate the same portable subset.

Starter Template

Copy the bundled FastAPI starter from the installed author kit:

astraform-remote-domain-copy-starter acme-remote-domain
cd acme-remote-domain
pip install --no-deps -e .
validate-population-catalog
remote-domain-conformance --app acme_remote_domain.main:app --domain-id acme-remote --population-catalog

The underlying template resource lives under:

  • astraform/remote_domain/author_kit/templates/fastapi-minimal

It is intentionally boring. That is a feature. Teams need a truthful starting point, not a framework demo that hides the protocol.

Publishing Status

Release validation starts with the standalone package tests:

pytest remote-domain-author-kit-python/tests remote-domain-conformance-python/tests

PyPI artifacts are immutable. Do not rerun a publish for an already published version; run smoke-only verification or bump the SDK version.

Public package note: PyPI distributions expose this SDK implementation. Keep host runtime internals and domain-private logic out of this package.

Metadata

Release files for astraform-remote-domain-author-kit 0.1.7

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for astraform-remote-domain-author-kit 0.1.7
File Size Uploaded
astraform_remote_domain_author_kit-0.1.7.tar.gz 30.9 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for astraform-remote-domain-author-kit 0.1.7
File Interpreter ABI Platform
astraform_remote_domain_author_kit-0.1.7-py3-none-any.whl Python 3 none any Details

Total release size: 58.2 kB

Release files / astraform_remote_domain_author_kit-0.1.7.tar.gz

Download URL astraform_remote_domain_author_kit-0.1.7.tar.gz
Size 30.9 kB
Tags Source
SHA-256 checksum
How to use checksums
026581accbf8f0b02d709d9206b33a1ec9a6a1cfeb2dbe4437aa49339847d1c6
BLAKE2b-256 checksum
How to use checksums
102fde8445150a2f89a18bcc392e1ffcd597a36b3550c99bd6f00bd50b426eba
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jul 24, 2026.

Transparency log

Release files / astraform_remote_domain_author_kit-0.1.7-py3-none-any.whl

Download URL astraform_remote_domain_author_kit-0.1.7-py3-none-any.whl
Size 27.3 kB
Tags Python 3
SHA-256 checksum
How to use checksums
67366bb1f8fdf58a342b9e0e6cea545ba2c03c04e2f4d13607a72a4b78c0fba6
BLAKE2b-256 checksum
How to use checksums
d83c996ae74615ded5ad38de047fc6ce2dc57031b422b54d54e655c053ba3b5f
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jul 24, 2026.

Transparency log

Release history Release notifications | RSS feed

0.3.0

2 release files

0.2.1

2 release files

0.2.0

2 release files

This release

0.1.7 This release

2 release files

0.1.6

2 release files

0.1.5

2 release files

0.1.4

2 release files

0.1.3

2 release files

0.1.2

2 release files

0.1.0

1 release file

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page