feat: node docs restructure to add different sections

docs/docs-network/concepts/architecture/block-production.md

@@ -0,0 +1,50 @@
+---
+title: Block Production
+description: Learn about how blocks are produced on the Aztec network through sequencers and provers.
+displayed_sidebar: conceptsSidebar
+---
+
+# Block Production
+
+Both sequencing and proving in the Aztec Network are intended to be fully decentralized.
+
+## Overview
+
+Block production in Aztec involves two key roles:
+
+- **Sequencers**: Order transactions and produce blocks
+- **Provers**: Generate cryptographic proofs for blocks
+
+Sequencers are chosen via a random election using a verifiable random function (VRF), while provers are selected by sequencers via an out-of-protocol coordination mechanism.
+
+## How It Works
+
+### Block Proposal
+
+1. A sequencer is selected for each slot using a VRF-based random selection
+2. The selected sequencer collects transactions from the mempool
+3. The sequencer orders transactions and proposes a block
+
+### Attestation
+
+1. Committee members receive the proposed block
+2. Each committee member re-executes the transactions
+3. If valid, committee members sign attestations
+4. The proposer collects attestations (needs 2/3 + 1)
+
+### Proof Generation
+
+The proposers in the first `C=13` slots in epoch `N+1` will accept quotes to prove epoch N from provers. The winning prover will have until the end of epoch `N+1` to produce and submit the proof to L1.
+
+See [Proving Coordination](./proving-coordination) for details on how provers coordinate.
+
+## Related Topics
+
+- [Proving Coordination](./proving-coordination) - How provers are selected and coordinated
+
+---
+
+:::tip Ready to operate?
+- [Run a sequencer](../../operators/setup/sequencer_management)
+- [Run a prover](../../operators/setup/running_a_prover)
+:::

docs/docs-network/concepts/architecture/index.md

@@ -0,0 +1,29 @@
+---
+title: Network Architecture
+description: Understand how the Aztec network architecture works - block production, sequencer selection, and proving.
+displayed_sidebar: conceptsSidebar
+---
+
+# Network Architecture
+
+The Aztec network operates through coordinated interaction between different node types. Together, they process transactions, produce blocks, and generate proofs.
+
+## How Nodes Work Together
+
+1. **Transaction Flow**: Users submit transactions to full nodes, which validate and propagate them through the P2P network
+2. **Block Production**: Sequencer nodes collect transactions from the mempool, order them, and propose new blocks
+3. **Consensus**: The sequencer committee validates proposed blocks and provides attestations
+4. **Proof Generation**: Prover nodes generate cryptographic proofs for epochs of blocks
+5. **L1 Submission**: Sequencers submit attested blocks and provers submit epoch proofs to Ethereum
+
+## Topics
+
+- [Block Production](architecture/block-production) - How sequencers and provers work together to produce and finalize blocks
+- [Proving Coordination](architecture/proving-coordination) - How provers coordinate to generate epoch proofs
+
+---
+
+:::tip Ready to operate?
+- [Run a sequencer](../operators/setup/sequencer_management)
+- [Run a prover](../operators/setup/running_a_prover)
+:::

docs/docs-network/concepts/provers-and-sequencers/proving_coordination_workflow.md → docs/docs-network/concepts/architecture/proving-coordination.md

@@ -1,10 +1,15 @@
 ---
-sidebar_position: 1
-title: Prover Coordination Workflow
+title: Proving Coordination
 description: Learn about the proving coordination workflow on the Aztec network.
-draft: true
+displayed_sidebar: conceptsSidebar
 ---
 
+# Proving Coordination
+
+Provers in the Aztec network coordinate with proposers through a request-for-quote (RFQ) process. This page explains how provers submit quotes and get selected to prove epochs.
+
+## Overview
+
 Proposers run RFQs to obtain quotes from provers. Quotes are binding promises from provers to prove an entire epoch. The exact channel over which provers send quotes to proposers is **NOT** enshrined by the protocol.
 
 However, Aztec Nodes will support two optional mechanisms that provers can use to submit quotes to proposers:
@@ -102,6 +107,6 @@ interface L1Publisher {
 
 The Prover Node will call this method at least once per L2 slot to check for unclaimed accepted quotes if its quotes have been accepted. You can update the polling interval using the environment variable `PROVER_NODE_POLLING_INTERVAL_MS`.
 
-## Run a prover
+## Run a Prover
 
-Go to the [Prover Guide](../../setup/running_a_prover.md) to run a prover.
+Go to the [Prover Guide](../../operators/setup/running_a_prover) to run a prover.

docs/docs-network/concepts/contracts/deployment-architecture.md

@@ -0,0 +1,68 @@
+---
+title: L1 Contracts
+description: Overview of the L1 smart contracts that power Aztec network governance.
+displayed_sidebar: conceptsSidebar
+---
+
+# L1 Contracts
+
+:::warning Work in Progress
+This page provides a high-level overview of Aztec's governance contracts. The contract interfaces and implementations are still evolving. For the authoritative source, see the [l1-contracts repository](https://github.com/AztecProtocol/aztec-packages/tree/master/l1-contracts/src/governance).
+:::
+
+## Contract Overview
+
+The Aztec governance system consists of several L1 smart contracts:
+
+| Contract | Purpose |
+|----------|---------|
+| **Registry** | Tracks all rollup instances; determines which is canonical |
+| **Governance** | Handles proposal voting and execution |
+| **GovernanceProposer** | Manages sequencer signaling and proposal submission |
+| **GSE** | Governance Staking Escrow - manages validator stakes and voting power |
+| **Rollup** | The rollup contract itself; validators stake here |
+
+## Registry
+
+The [Registry](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/governance/Registry.sol) maintains an append-only list of rollup instances. Only the Governance contract (as owner) can add new rollups.
+
+Key properties:
+- **Backwards compatible**: All historical rollups remain accessible
+- **Canonical selection**: Only the latest rollup receives block rewards
+- **Immutable entries**: Once added, rollup addresses cannot be removed
+
+## Governance
+
+The [Governance](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/governance/Governance.sol) contract is the decision-making body that executes approved proposals.
+
+Key functions:
+- `deposit()` / `initiateWithdraw()` - Manage voting power
+- `vote()` - Cast votes on proposals
+- `execute()` - Execute approved proposals
+
+See [Proposal Lifecycle](../governance/proposal-lifecycle) for how proposals move through the system.
+
+## GovernanceProposer
+
+The [GovernanceProposer](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/governance/proposer/GovernanceProposer.sol) handles the signaling phase where sequencers vote to promote payloads to proposals.
+
+Key functions:
+- `signal()` - Sequencers signal support for a payload during their slot
+- `submitRoundWinner()` - Submit a payload that reached quorum as a proposal
+
+## GSE (Governance Staking Escrow)
+
+The [GSE](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/governance/GSE.sol) holds validator stakes and manages voting power delegation.
+
+Key features:
+- **Stake mobility**: Stakes can automatically follow rollup upgrades
+- **Voting delegation**: Validators can delegate voting power
+- **Escape hatch**: `proposeWithLock()` for emergency proposals
+
+See [GSE and Stake Mobility](../governance/gse) for details.
+
+## Related Topics
+
+- [Governance Overview](../governance/) - How the governance system works
+- [Proposal Lifecycle](../governance/proposal-lifecycle) - Stages from signaling to execution
+- [Network Upgrades](../governance/upgrades) - How upgrades use these contracts