Reusable private workflows: Python authoring, GUI and server walkthrough

A narrated 26:32 r34 walkthrough: why the scientific Python program is needed, what it contains, how to build it from a specification, and how to reuse it as a private workflow. The expanded film has 38 chapters. Twelve new chapters precede the retained attachment route; the closing chapter now points to the current guide.

Watch and build your program

Open the video and chapter controls. The player includes English captions, full-screen playback and an MP4 download. Start with the Private Workflow Development Guide, its 47-page PDF, and the worked mathematical specification.

The current importable guide companion contains the complete Python source in its files array. It supports the declared two-to-eight-qubit study, compact inline results and full quantum-state artifacts. Import it as a proposal, inspect the source and checks, then validate and activate explicitly. You can also provide the specification and use the workflow assistant to help build a program from scratch.

The original modular Qiskit study remains a separate download. Its V1/V2 bundles, named observables, recorded settings/results and independent numerical verifier belong to the retained walkthrough. The guide companion uses ordinary mean magnetization; the original study uses staggered magnetization and later adds connected correlations. Their reported numerical results must not be mixed.

Recording scope

The two new authoring sequences show the actual current r34 interface, starting from the Polynomial sweep template and processing a scripted proposal through the assistant tools. The template supplies a workflow contract example; the supplied specification defines the quantum calculation. No live model authored a program during recording, and this film does not establish a success rate for complex live generation.

Fix13 revises four further narration sections for connected phrasing, rechecks pronunciation, production-isolation wording and the closing guide-link instruction. The other 34 narration tracks remain byte-identical to Fix12, preserving its earlier corrections. The recorded GUI actions and scientific results are retained; chapter timing and captions are updated. Their numerical and server evidence retains its original scope. New teaching cards quote actual Python source or label explanatory summaries. The website guide-link image is the supplied website screenshot; the guide cover is from the current PDF. A new website browser capture was unavailable because the preview connection failed; no replacement website UI was fabricated.

All accounts and projects are synthetic fixtures. Numerical results are actual local Qiskit executions using the designated developer executor, not quantum-hardware measurements. Production Docker isolation and a live external provider are outside this recording’s scope. Existing B2/B3 evidence remains limited to its recorded cases. Current package identity and acceptance are documented in Delivered package and validation.

GUI recordings play once at their original speed, followed where needed by a readable final-state hold. Source cards, captions and chapters share one timeline. The source website archive includes the clean reproduction assets and hash-bound media evidence under private-workflow-demo-reproduction; disposable sessions, databases and private runtime snapshots are excluded.

Narration corrections in Fix12

Decimals are spoken digit by digit, and r34 is spoken as release thirty-four. Revised sections have explicit sentence endings and at least 0.55 seconds between aligned sentences. Instructions now identify the result table, JSON file, saved inputs and output data structures directly. The source archive includes pronunciation, waveform and targeted local speech-recognition checks.

Narration corrections in Fix13

“Enforcement checks” is spoken as one connected phrase while captions keep the normal spelling. “Rechecks” uses a clear ree prefix. The production-isolation statement and guide-link instruction use shorter sentences with clear boundaries. All four regenerated tracks retain the original voice and speed, with at least 0.55 seconds between aligned sentences. The source archive records the explicit pronunciation controls and targeted speech-recognition review.

Transcript

00:00 — A model beyond the built-in menu

Suppose your research needs a six-qubit kicked-Ising Floquet chain, a periodically driven system of interacting quantum spins. Each period couples neighboring qubits, applies a transverse rotation, and then adds phase-flip noise. You want to study the echo fidelity, purity, staggered magnetization, and information shared between two halves of the chain. This is a complete Qiskit program with several observables and several outputs. In this walkthrough, we turn that complete program into a reusable private workflow in PF Simulation, release r34.

00:35 — Check the existing catalogue

The shared application already includes quantum benchmark workflows. Open the built-in choices and inspect them. This exact driven-chain experiment is not a supplied workflow or preset. Having Qiskit installed does not automatically give every possible circuit its own graphical interface. The private workflow framework fills that gap: it can retain a new program and generate its controls without adding a special-purpose form to the shared application.

01:04 — Start in My workflows

Open My workflows in the selected project. This account starts with an empty collection. Workflows belong to the authenticated user and project context, so this is your personal workspace. You can import a prepared bundle directly, or ask the research assistant to prepare one from your program. Here we will use Create with AI. A completed simulation is not required just to begin authoring.

01:29 — Why the program comes first

Before we attach a file, let us explain what that Python program actually is. It is the executable definition of your experiment: the equations, numerical method, inputs, and observable calculations. PF Simulation provides a reusable form, execution controls, version history, and results storage around that definition. It cannot infer an unspecified scientific model from a title alone. You have two authoring routes. Supply a complete program that you already understand, or give the research assistant a precise mathematical specification and ask it to help write the program. Both routes produce source code that you inspect and test. We will first examine the program, then show the second route inside My workflows.

02:16 — Turn the question into a specification

Start with decisions a model author must make. For this Floquet study, define neighboring Ising interactions, transverse rotations, and independent phase-flip noise after each complete period. State the initial preparation, whether the chain is open or a ring, and which qubit is the least-significant bit. A two-qubit ring must not apply the same edge twice. Define fidelity as overlap with the ideal state evolved under the same gates. Specify purity and the exact magnetization and correlation you want. These details matter: ordinary mean magnetization and staggered magnetization are different observables. The guide companion and the later modular walkthrough report different named output sets, so always read each program’s definitions.

03:04 — Three responsibilities in Python

Here is the modular program used in the retained walkthrough. Its small entry point calls the dynamics module and passes the computed arrays to the reporting module. That organization separates three responsibilities: accept the input dictionary, evolve the model, and return results in the workflow format. A single Python file can also do all three, as the current guide companion does. With the Python function adapter, the entry point receives inputs and a context object. The context supplies approved output paths. Include every private module that the entry point imports in the bundle. A notebook cell, a circuit diagram, or pseudocode alone is not a complete executable program.

03:47 — See where the physics is executed

Read the circuit construction before trusting the plots. The code applies an RZZ gate with twice the coupling angle on every selected edge, then an RX gate with twice the transverse angle on every qubit. The statevector follows the ideal circuit. The density matrix follows that same circuit and then a Kraus phase-flip channel on each qubit. At each cycle, the program computes its observables from those evolved states. This is where the simulation happens; the assistant’s prose is not the numerical result. Check gate order, signs, factors of two, and tensor ordering against your specification. The model uses local Qiskit simulation and does not contact quantum hardware.

04:29 — Make calculated results reusable

The reporting module turns calculated values into metrics, tables, and plotted series. It writes the trajectory to a CSV file through the supplied context, then declares that file as an artifact. Returned results must use the declared output names and types, and follow the required data structure. For example, a plotted series needs matching numbers of x and y values. Input declarations do a different job: they give each control its name, type, default, bounds, units, and explanation. Changing a control supplies a new input to the same saved program. Dependencies are declared too, but a requirement declaration does not install a library. The selected execution environment must already provide compatible versions. Package the scientific calculation and its contract together so another run can reproduce the intended request.

05:26 — Design checks before asking for code

Write the validation plan before asking the assistant for a finished bundle. Choose cases with independently justified expectations. With no noise, both fidelity against the same ideal evolution and purity should remain equal to one. At zero cycles, the guide’s product state has known initial observables. With zero transverse rotation, an all-zero state remains stationary under the specified interactions and phase flips. State numerical tolerances and test unusual boundaries as well as the default case. For a nontrivial trajectory, compare with a separately implemented reference when possible. An assistant can help propose checks, but copying expected numbers from its own unverified output is not independent validation. A successful check provides evidence only for the cases tested under those execution conditions.

06:22 — Keep full quantum states in artifacts

Complex workflows also need an output plan. The current r34 inline result has independent limits of two mebibytes of compact JSON and one hundred thousand visited value nodes. A complex eight-qubit density matrix already has one hundred thirty-one thousand and seventy-two real-valued components when real and imaginary parts are separate. Containers add more nodes. The guide companion writes the complete final density matrix and ideal statevector to a declared JSON artifact without deliberate rounding. At eight qubits it returns compact file pointers in the inline result. This changes serialization, not the quantum evolution. Use the same pattern for large arrays and trajectories: keep useful summaries visible and the full scientific data downloadable.

07:14 — Open the guide from the website

To build your own program from scratch, use the Read the development guide link beside this video on the website. The current Private Workflow Development Guide has forty-seven pages. Begin with the authoring routes, then the bundle, parameter, output, validation, and Python adapter chapters. Chapter eleven includes the mathematical specification, a reusable assistant prompt, the complete importable Floquet companion, and the large-state artifact pattern. The Markdown edition is useful beside your editor. The downloadable companion contains its Python source inside the JSON bundle; importing that bundle is a separate shortcut when you want to study a working example. The guide supplies the integration instructions. You still supply the scientific assumptions and review the resulting implementation.

08:04 — Ask AI to build from the specification

Now watch the alternative route in the actual current r34 interface. Start a new private workflow with the Polynomial sweep template, then use the workflow authoring assistant. The template supplies an example of the input, output, and validation structure; its polynomial calculation does not become the quantum model. Give the assistant the Floquet specification and explicitly request all executable Python source, typed controls, output declarations, dependency requirements, and analytic checks. Specify full-state artifacts for the eight-qubit case. Ask it to identify unresolved scientific choices before making assumptions. In this demonstration the provider response is a scripted replay of the tested companion bundle, so the interface sequence is reproducible; this is not a live model-generation benchmark.

08:59 — Review the generated proposal

Submit the request only after reviewing any required disclosure and consent. The actual assistant path processes the scripted proposal and saves the private workflow. Open the resulting proposal and inspect its seven controls, including the qubit count, cycles, coupling, rotation, noise probability, boundary, and preparation. These controls correspond to the specification you supplied. Inspect the full Python file as well; do not judge the implementation only from the assistant’s description. A provider may need more output budget or another authoring pass for a long program. Check for missing functions, truncated files, and unsupported dependencies. Saving a proposal does not execute or approve it. Validation and activation remain explicit user actions.

10:15 — Check the code against the mathematics

Review the proposed source against the mathematical specification. Locate the gate sequence, initial-state indexing, phase-flip channel, observable definitions, and artifact-writing code. Confirm that the checks test the intended limiting cases and that the program returns every declared output. You can ask the assistant to explain a section or revise a concrete discrepancy, then review the new version again. The current guide companion supports from two through eight qubits, and from zero through sixteen cycles. Those are this example’s chosen ranges. The source review shown here does not claim a live provider wrote correct code in one attempt. Use the normal Validate and Activate controls when you are ready to assess the proposal in your configured executor.

11:05 — Continue with an existing program

We have now seen how the program can be built from a precise specification with assistant help. Return to the other route when you already have a complete program: attach the source and all required local modules, then describe the controls, outputs, and checks you want to preserve. The rest of this walkthrough retains the modular six-qubit study introduced at the start, including its original observable names and later connected-correlation revision. It is a separate worked bundle from the current guide companion we just inspected. Both use the same private workflow framework. Next, watch the existing program become a reusable interface, then follow numerical validation, explicit activation, repeated runs, retained versions, and project and disclosure controls.

11:52 — Supply the full program once

Attach the complete Python program and describe the reusable experiment you want. Specify which parameters should become controls, which results should be displayed, and which independently justified checks should run before activation. Here the program defines the quantum model; the assistant prepares its private workflow contract. The recording uses a scripted provider reply so the authoring sequence can be reproduced. The application still processes the proposal through its actual assistant tools and workflow service.

12:33 — Review before disclosure

Before sending a message to an external provider, review the disclosure dialog. It identifies the provider and the project scope, including the messages, attachments, and source material that may be disclosed. Grant consent only if this use is permitted. Consent is tied to the current user, project, policy, provider configuration, and credential revision. In this recording, the provider transport is scripted and no research data leaves the demonstration server.

13:02 — A reusable interface appears

The assistant returns a saved proposal, and My workflows now displays the generated interface. Integer and numeric definitions become bounded inputs. Enumerated choices become selection controls. The workflow also declares its metrics, tables, plotted series, and downloadable files. These are reusable, typed definitions. The framework renders them consistently; the workflow does not inject its own browser JavaScript or arbitrary HTML. Review the source, dependencies, and checks before executing it.

13:36 — Validate, then activate

Select Validate and wait for the four declared limiting cases to execute: no transverse kick, no noise, product rotation, and complete dephasing. The service checks the returned outputs against the stated expectations, rather than trusting a passed flag produced by the program. Review the cases and tolerances. Successful checks cover these cases and this execution context; they do not prove the entire physical model. Activation is a separate user action. The assistant cannot silently activate its own proposal. This demonstration executes real calculations with the designated developer executor; production container isolation is not demonstrated here.

14:19 — Run the quantum experiment

With the validated version active, run the experiment using the displayed inputs. Qiskit evolves the ideal state and the noisy density matrix through the declared circuit and channels. The workflow computes each reported observable from those states. For six qubits and eight periods, the final echo fidelity is about 0.329 and purity is about 0.125. Inspect the plotted series and numerical table together. The curves are outputs of the executed program. They are an idealized model calculation, not measured device data or evidence that a particular quantum processor behaves this way.

15:01 — Change the experiment visibly

Now change the experiment through the generated controls. Watch the transverse kick and phase-flip probability change in the numerical controls. These visible edits become the inputs to the next run. The same saved program and interface are reused. You do not need a new assistant conversation or a new shared-core workflow for each parameter combination. Input validation still applies, so the controls cannot submit a value outside the declared contract.

15:30 — Inspect the changed result

Run the workflow again with the edited settings. A new run is created with its own captured inputs and results. With the stronger transverse kick and phase-flip probability, the final echo fidelity is about 0.045 and purity is about 0.019. Inspect how the computed evolution changes under these settings. The earlier result is retained separately. This distinction matters: the current form describes the next request. Each saved run records the input values used and the program version that was executed. A result should always be interpreted with those inputs and model assumptions.

16:12 — Keep results you can inspect

Open Run history and inspect an earlier run. Its record retains the workflow version, input values, output data, and integrity information for captured artifacts. Download the run JSON file and the scientific output files for analysis outside the application. Select “Reuse these settings” to restore the saved input values to the form. Export bundle saves the reusable program and contract. Importing that bundle elsewhere creates a new proposal; it does not transfer activation approval to another installation.

16:48 — Revise without overwriting evidence

Next, edit the saved proposal. Here we add a configurable connected Z–Z correlation to the model’s reported observables, then save the revised bundle. The service creates a new private version instead of replacing the evidence attached to an earlier run. The new version is not automatically active. Source changes, contract changes, or changes to the execution base require their own validation. This lets you develop the experiment while keeping a clear connection between each result and the program that produced it.

17:21 — Validate the revised version

Validate the revised proposal and inspect its results. Then activate that version explicitly. The new control selects the separation used for the connected correlation, and the revised result contract exposes that observable alongside the existing outputs. Validation is bound to the proposal and its recorded source and runtime context. A successful result from another version cannot silently approve this one. If the shared source or private source profile changes, create and validate a proposal against the new base.

18:07 — Inspect the retained program

Now inspect the evidence already retained by the application. This view shows the exact exported version-one bundle, including its requirements, parameter definitions, checks, and private Python files. Then inspect the current version’s retained validation evidence. Read the case inputs, expectations, and execution information. These are inspections of saved records. They let you examine what was proposed and what was checked, independently of the current input form.

18:50 — Reuse an earlier run’s settings

Select the earlier baseline run and choose Reuse these settings. Watch the kick and phase-flip probability return to their recorded values. The active version now also has a correlation-separation control, so supply that new input before a further run. Reusing settings copies ordinary inputs into the current form; it does not change which program version is active. The original run keeps its own version and evidence.

19:18 — Return to the saved workflow

Reload the interface, then return to the same account and project. The workflow, version records, and run history remain available because they are stored in application state, not in the open chat. Ordinary last-run settings are retained for reuse. File inputs are different: browsers require an explicit file selection for a new request. Protect the application state with the normal storage and backup procedures so private work remains available across sessions.

19:49 — Project access is not ownership

Switch to another account that can access the same project. Its private workflow collection is separate. Project membership does not automatically reveal another researcher’s workflow source, private run records, or artifacts. The server derives ownership from the authenticated context. Supplying another owner’s identifier in a request does not transfer that ownership. The following enforcement checks test the server responses behind those interface boundaries.

20:21 — Control who can use the project

The Team interface manages project access. Restrict the project to selected members, then grant the appropriate role. A viewer can inspect permitted project information, while authoring and mutation operations require editor permission. Project grants cannot raise a member above the organization role. When access is revoked, the server rechecks the current permission. An already open page or a retained assistant session does not preserve authority that the user no longer has.

21:10 — Verify the server boundary

This on-screen table summarizes the results of tests performed against the actual r34 server. The restricted project is unavailable before an explicit grant. A viewer’s mutation is rejected. An editor can author a private workflow within their own context, but another account’s private workflow and results remain unavailable. After revocation, retained access requests fail. These checks exercise the server directly, so the restriction does not depend on whether the browser hides or disables a button.

21:46 — Set the organization policy

Open the organization’s research AI policy. First, disable external AI and save the change. A permitted account still cannot send an assistant request while this policy blocks it. Next, restore external AI for the approved provider, with source disclosure allowed and explicit consent required. Review the provider choices, approved endpoint identifier, and disclosure limits, then save. The policy summary shows what is effective. These settings govern external assistant disclosure; they do not switch off the local Qiskit calculation.

22:24 — Apply stricter project limits

Project policy can make the organization rules more restrictive. Change the project’s content classification to confidential and save. The external disclosure ceiling remains internal, so the request is blocked. This classification is an administrator-assigned label, not automatic scanning of sensitive content. Return the demonstration project to internal. Next, disable source disclosure and save. Because the assistant uses source tools, that choice blocks the model request rather than pretending the source was removed. Restore the permitted setting before continuing.

23:06 — Review, authorize and revoke

Ask the assistant a question and inspect the disclosure dialog. The acceptance box is initially unchecked. Review the destination and scope, then cancel. Cancelling sends no provider request. Open the dialog again and explicitly accept the current disclosure. The scripted provider can now process this message, and the response appears in the actual assistant interface. This acceptance is specific to the current authorized context. Finally, revoke consent and try again. The next message requires fresh acceptance. Changing policy or rotating personal credentials can also invalidate an earlier consent. Project and organization permission still apply even when the user is willing to disclose.

24:00 — Block before the provider call

During these recorded tests, workflow-authoring messages were submitted to the server under different policy conditions. Disallowed provider or endpoint, excessive classification, denied source disclosure, and missing or stale consent are rejected before provider transport. The accompanying counters show no transport call for each blocked request. With the permitted policy and current consent, the scripted provider can process the message through the normal assistant path. Policy applies to both personal-key and operator-configured provider use.

24:36 — One framework, many scientific APIs

The framework is API-agnostic because it separates the private scientific program from the parameter schema, result contract, storage service, and execution adapter. The example uses Qiskit and numerical libraries together, but the interface is not hardcoded to their function names. Another compatible Python API can use the same workflow machinery when its dependencies are installed in the configured runtime. This does not automatically enable remote hardware, network services, proprietary licenses, or every possible native dependency.

25:13 — Deploy the isolated executor

For production, configure the isolated Docker executor and the required scientific dependencies. The shipped workflow path disables networking and separates the private program from the application control process. It does not fall back to executing generated code on the host when Docker is unavailable. The real numerical runs in this demonstration used the designated developer executor. They establish the demonstrated calculation and application behavior. Container isolation and deployment compatibility still need to be verified in production.

25:52 — Build your next private workflow

For full instructions, return to the website. Select the link labelled “Read the development guide”. The current PDF and Markdown editions cover both authoring routes: starting from an existing Python program, or asking the workflow assistant to help implement a precise scientific specification. Use the complete Floquet companion to inspect source, controls, validation checks, and full-state artifacts. Define your model, review the program, and validate the exact proposal before you activate it. PF Simulation can then retain that private workflow and make the experiment reusable through the graphical interface.